NIOS AdminGuide 4.3r1

Infoblox Administrator Guide
NIOS 4.3
for Infoblox Core Network Services Appliances
Copyright Statements
2008, Infoblox Inc. All rights reserved.
The contents of this document may not be copied or duplicated in any form, in whole or in part, without the prior
written permission of Infoblox, Inc.
The information in this document is subject to change without notice. Infoblox, Inc. shall not be liable for any
damages resulting from technical errors or omissions which may be present in this document, or from use of this
document.
This document is an unpublished work protected by the United States copyright laws and is proprietary to Infoblox,
Inc. Disclosure, copying, reproduction, merger, translation, modification, enhancement, or use of this document by
anyone other than authorized employees, authorized users, or licensees of Infoblox, Inc. without the prior written
consent of Infoblox, Inc. is prohibited.
For Open Source Copyright information, see Appendix C, "Open Source Copyright and License Statements", on page
695.
Trademark Statements
Infoblox, the Infoblox logo, DNSone, NIOS, Keystone, IDeal IP, bloxSDB, bloxHA and bloxSYNC are trademarks or
registered trademarks of Infoblox Inc.
All other trademarked names used herein are the properties of their respective owners and are used for identification
purposes only.
Company Information
Infoblox is located at:
4750 Patrick Henry Drive
Santa Clara, CA 95054-1851, USA
Web: www.infoblox.com
support.infoblox.com
Phone: 408.625.4200
Toll Free: 888.463.6259
Outside North America: +1.408.716.4300
Fax: 408.625.4201
Product Information
Hardware Models: Infoblox-250, -500, -550, -1000, -1200, -1050, -1550, and -1552, -2000
Document Number: 400-0172-000 Rev. A
Document Updated: July 27, 2008
Warranty Information
Your purchase includes a 90-day software warranty and a one year limited warranty on the Infoblox appliance, plus
an Infoblox Warranty Support Plan and Technical Support. For more information about Infoblox Warranty information,
refer to Infoblox Web site, or contact Infoblox Technical Support.
NIOS 4.3r1 Infoblox Administrator Guide (Rev. A) 3
Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Document Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Documentation Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Documentation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Whats New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Related Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Customer Care . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Software Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Part 1 Appliance Administration
Chapter 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
NIOS Appliance Software Packages and Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Product Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Scenario 1 Independent NIOS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Scenario 2 Basic Grid with Independent NIOS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Scenario 3 Infoblox Grid with a NIOS Virtual Appliance as a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Scenario 4 Multiple Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Scenario 5 Primary and Secondary NIOS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Chapter 2 Infoblox GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Management System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Accessing the Infoblox GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Connecting to a NIOS Appliance with JWS (Java Web Start) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
About The Grid Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Installing the Grid Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Connecting to a NIOS Appliance Using the Grid Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Setting Login Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
SSL (Secure Sockets Layer) Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Understanding the GUI Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Main Interface Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Customizing a Perspective Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating a Login Banner on a NIOS Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Customizing Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Using Global Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Printing from the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Multilingual Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
UTF-8 Supported Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
UTF-8 Support Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
International Characters Support for RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4 Infoblox Administrator Guide NIOS 4.3r1
Exporting Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Exporting Data from Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Exporting Data to a CSV File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Chapter 3 Managing Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
About Admin Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
About Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Creating a Superuser Admin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
About Limited-Access Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
About Admin Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Creating Limited-Access Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Deleting Admin Roles and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Viewing Admin Group Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
About Administrative Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Applying Permissions and Managing Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Defining Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Viewing and Managing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Modifying Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Removing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Administrative Permissions for Grid Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Managing DNS Resource Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Administrative Permissions for Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Administrative Permissions for Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Administrative Permissions for Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Administrative Permissions for Shared Record Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Managing Administrative Permissions for DHCP Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Administrative Permissions for Networks and Shared Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Administrative Permissions for Fixed Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Administrative Permissions for DHCP Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Administrative Permissions for DHCP Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Administrative Permissions for MAC Address Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Administrative Permissions for Network Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Administrative Permissions for the DHCP Lease History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Administrative Permissions for the RADIUS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Administrative Permissions for File Distribution Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Authenticating Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Creating Local Admins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Modifying and Removing an Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
About Remote Admins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Authenticating Using RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Remote RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Configuring RADIUS Authentication on the NIOS Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Adding RADIUS Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Testing the RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Maintaining the RADIUS Admins Server List on the NIOS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Disabling a RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Configuring a RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring Admin Groups on the Remote RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring Remote Admin Accounts on the Remote RADIUS Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Authorization Groups Using RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Accounting Activities Using RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Authenticating Admin Accounts Using Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Admin Authentication Using Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Configuring Active Directory Authentication for Admins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Defining the Admin Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Specifying a List of Remote Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Configuring the Default Admin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Configuring a List of Authentication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Changing Password Length Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Notifying Administrators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Chapter 4 Managing Appliance Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Managing Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Changing Time and Date Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Changing Time Zone Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Monitoring Time Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Using NTP for Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Authenticating NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
NIOS Appliance as NTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
NIOS Appliance as NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Configuring a NIOS Appliance as an NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Managing Security Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Enabling Support Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Enabling Remote Console Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Permanently Disabling Remote Console and Support Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Restricting HTTP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Enabling HTTP Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Modifying GUI Session Timeout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Disabling the LCD Input Buttons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Modifying Security for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Ethernet Port Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Modifying Ethernet Port Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Using the MGMT Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Appliance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Grid Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Setting Static Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Enabling DNS Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Managing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Viewing the Installed Licenses on a NIOS Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Obtaining a 60-Day Temporary License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Obtaining and Adding a License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Removing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Shutting Down, Rebooting, and Resetting a NIOS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Rebooting a NIOS Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Shutting Down a NIOS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Resetting a NIOS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Managing the Disk Subsystem on the Infoblox-2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
About RAID 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Evaluating the Status of the Disk Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Replacing a Failed Disk Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Disk Array Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Restarting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Canceling a Scheduled Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Chapter 5 Monitoring the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Viewing Detailed Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Appliance Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Service Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
DB Capacity Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Disk Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
FAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
HA, LAN, or MGMT Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Memory Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Power Supply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
RAID Battery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Temperatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Using a Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Specifying Syslog Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Configuring Syslog for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Setting DNS Logging Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Viewing the Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Searching for Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Downloading the Syslog File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Using the Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Using the Replication Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Using the Traffic Capture Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Using the Capacity Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 6 Monitoring with SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Understanding SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
SNMP MIB Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
MIB Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Infoblox MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Loading the Infoblox MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
RADIUS MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
ibTrap MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
ibPlatformOne MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
ibDHCPOne MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
ibDNSOne MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
ibIPWC MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Accepting SNMP Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Setting System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Adding SNMP Trap Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Configuring SNMP for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Chapter 7 Changing Software and Merging Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Upgrading NIOS Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Downgrading Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Reverting to the Previously Running Software Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Backing Up and Restoring a Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Back Up and Restore Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Automatically Backing Up a Data File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Downloading a Backup File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Restoring a Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Loading a Configuration File on a Different Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Downloading a Support Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Part 2 Appliance Deployment
Chapter 8 Deploying Independent Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Independent Deployment Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Deploying a Single Independent Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Method 1 Using the LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Method 2 Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Method 3 Using the Infoblox NIOS Startup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Method 4 Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Configuration Example: Deploying a NIOS Appliance for External DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Cable the Appliance to the Network and Turn On Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Specify Initial Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Specify Appliance Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Define a NAT Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Enable Zone Transfers on the Legacy Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Import Zone Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Designate the New Primary on the Secondary Name Server (at the ISP Site) . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configure NAT and Policies on the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Deploying an Independent HA Pair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Method 1 Using the Infoblox NIOS Startup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Method 2 Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Cable Appliances to the Network and Turn On Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Specify Initial Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Specify Appliance Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Enable Zone Transfers on the Legacy Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Import Zone Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Define Networks, Reverse-Mapping Zones, DHCP Ranges, and Infoblox Hosts. . . . . . . . . . . . . . . . . . . . . . . . 257
Define Multiple Forwarders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Enable Recursion on External DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Modify the Firewall and Router Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Enable DHCP and Switch Service to the NIOS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Manage and Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Verifying the Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Single Independent Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Independent HA Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Forcing an HA Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Infoblox Tools for Migrating Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Upgrading Software on an Independent Appliance or HA Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Acquiring Software Upgrade Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Distributing Software Upgrade Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Running the Software Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Chapter 9 Deploying a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Introduction to Grids. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Grid Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
NAT Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Automatic Software Version Coordination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Grid Bandwidth Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Creating a Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
VRRP Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Port Numbers for Grid Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Creating an HA Grid Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Creating a Single Grid Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Adding Grid Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Adding a Single Member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Adding an HA Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Configuration Example: Configuring a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Cable All Appliances to the Network and Turn On Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Create the Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Define Members on the Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Join Appliances to the Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Import DHCP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Import DNS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using the Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
After Using the Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Enabling IPv6 On a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
About IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Configuring IPv6 on a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Configuration Example: Configuring IPv6 on a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Managing a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Changing Grid Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Setting the MTU for VPN Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Removing a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Promoting a Master Candidate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Replacing a Failed Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Using the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Disabling the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Enabling the Recycle Bin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Viewing the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Restoring Items in the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Emptying the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Upgrading NIOS Software on a Grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Lite Upgrades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Uploading NIOS Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
About Upgrade Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Distributing Software Upgrade Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Testing a Software Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Performing a Software Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Monitoring Distribution and Upgrade Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Part 3 Service Configuration
Chapter 10 Managing DNS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Configuring DNS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
DNS Configuration Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Restarting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Using Infoblox DNS Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Default View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Creating Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Specifying Match Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Adding Zones to a View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Adding Records to a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Managing Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Configuration Example: Configuring a View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Understanding DNS for IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Configuring DNS for IPv6 Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Delegating Zone Authority to Name Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Specifying a Primary Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Specifying a Secondary Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Configuring Authoritative Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Creating an Authoritative Forward-Mapping Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Creating an Authoritative Reverse-Mapping Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Adding an Authoritative Subzone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Creating a Root Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Importing Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Allowing Zone Transfers to an Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Importing Data into Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
How Specific Zones and Records Are Imported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Restoring Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Restoring Zone Data After a Zone Import Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Restoring Zone Data After a Zone Reimport Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Configuring Delegated, Forward, and Stub Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Configuring a Delegated Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Configuring a Forward Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Configuring Stub Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Using Name Server Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Creating Name Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Applying Name Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Managing Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Locking and Unlocking Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Modifying Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Removing Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Enabling and Disabling Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Specifying Host Name Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Grid Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Member Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Zone Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Obtaining a List of Invalid Record Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Adding Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Adding Bulk Hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Specifying Bulk Host Name Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Before Defining Bulk Host Name Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Configuring Bulk Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Associating Shared Record Groups With Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Adding Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Adding A Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Adding NS Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Adding AAAA Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Adding PTR Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Adding MX Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Adding SRV Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Adding TXT Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Adding CNAME Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Adding DNAME Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Specifying Time To Live Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Managing Hosts and Resource Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Modifying, Disabling, or Removing a Host or Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Viewing DNS Record Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Chapter 11 Shared Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Understanding Shared Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Shared Records Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Shared Records Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Shared Records Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Using Shared Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Configuring Shared Record Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Viewing Records in Shared Record Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Associating Shared Record Groups With Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Viewing Zones Associated With Shared Record Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Removing Shared Record Group Zone Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Deleting and Recovering Shared Record Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Using the Shared Record Group API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Adding Shared Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Adding Shared A Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Adding Shared AAAA Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Adding Shared MX Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Adding Shared SRV Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Adding Shared TXT Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Chapter 12 Configuring DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Configuring DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Changing General DNS Properties for a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Enabling Zone Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Specifying DNS Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Specifying Root Name Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Specifying Sort Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Using Forwarders with a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Using Forwarders with a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Specifying Minimal Response Returns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Disabling and Enabling DNS Service for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Configuring Additional IP Addresses for a Grid Member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Configuring DNS Zone Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Disabling Forwarding for a Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Specifying TTL Settings for a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Changing the SOA Name for a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Setting the Serial Number in the SOA Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Adding an E-mail Address to the SOA Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Allowing Zone Transfers for a Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Allowing Query Access for a Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Supporting Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Active Directory and Unauthenticated DDNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Active Directory and GSS-TSIG-Authenticated DDNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Importing the Keytab File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Viewing DNS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Viewing DNS Cache Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Viewing a DNS Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Viewing DNS Zone Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Chapter 13 Configuring IP Routing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Multiple IP Addresses on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
IP Addressing on an Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Configuring IP Addresses on the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Advertising Loopback IP Addresses to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Configuration Example: Configuring IP Addresses on the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . 451
Anycast Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Network Communication Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Configure OSPF on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Configure an Anycast Address on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Configuration Example: Configuring Anycast Addressing on the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Chapter 14 Managing DHCP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Configuring a DHCP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Adding a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Splitting a Network into Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Expanding/Joining a Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Adding a Shared Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Modifying a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Removing a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Enabling and Disabling a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Configuring IP Addresses and DHCP Address Ranges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Creating and Managing Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
About Network Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Creating and Managing Network Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Creating and Managing DHCP Range Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Creating and Managing Fixed Address Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Configuration Example: Creating a Network Using a Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Chapter 15 Configuring DHCP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Configuring DHCP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
DHCP Configuration Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Configuring DHCP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Enabling DHCP and Setting Member Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Specifying Ping Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Specifying DHCP Lease Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Specifying BOOTP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Specifying Custom DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Defining Option 60 (Vendor-Class-Identifier) Match Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Defining Custom Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Configuring Advanced DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Configuring the DHCP Option Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Adding Vendor Option Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Configuring DNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Enabling DHCP Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Defining Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Configuring a MAC Address Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Configuring Option Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Example DHCP Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Configuring User Class Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Configuring a Relay Agent Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Managing DHCP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Configuring DHCP Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
DHCP Failover Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Creating a Failover Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Monitoring the Failover Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Failover Association Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Viewing DHCP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Viewing a DHCP Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Viewing DHCP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Chapter 16 Using Network Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
About Network Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Administrative Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Discovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Supported Discovery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Configuring Network Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Updating the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Starting a Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Monitoring Discovery Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Viewing Discovered Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Attributes of Discovered Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Types of Discovered Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Display of Discovered Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Filtering Discovered Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Searching Discovered Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Managing Discovered Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Managing Unmanaged Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Resolving Conflicting Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Configuring DNS and DHCP for a Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Clearing the Discovered Timestamp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Chapter 17 Configuring DDNS Updates
from DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Understanding DDNS Updates from DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Configuring DHCP for DDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Specifying a Domain Name for DHCP Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Configuring DDNS on the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Sending Updates to DNS Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Client FQDN Option (Option 81) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Generating Host Names for DNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Updating DNS for Clients with Fixed Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Resending DNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Configuring DNS Update Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Configuring DNS for DDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Enabling the DNS Server to Receive Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Forwarding Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Authenticating Updates with TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Chapter 18 Managing IP Data IPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Viewing and Modifying IP Address Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Classifying an IPAM Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Configuring IPAM Device Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Configuration Example: Configuring a Device Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Adding, Modifying, and Removing Host Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Adding, Modifying, and Removing DNS Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Modifying DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Converting DHCP Leases, Fixed Addresses, and Reserved Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Monitoring Overall DHCP Address Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Setting Watermark Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Viewing IPAM Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Downloading IPAM Status Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Viewing IPAM Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Viewing DHCP and DNS Usage and Device Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Searching and Sorting IPAM Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Viewing DHCP Lease Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Viewing Historical DHCP Lease Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Logging Member and Selective Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Searching DHCP Lease Event Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Viewing Lease Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Exporting and Importing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Chapter 19 NAC Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
About the NAC Foundation Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
DHCP Authentication Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Configuring the NAC Foundation Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Configuring DHCP Ranges for Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Quarantined DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Guest DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Authorized DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
User Class Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Binding DHCP Ranges to the Quarantined and Authorized Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Uploading Files for Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Uploading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Creating Subdirectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Managing the Image Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Configuring the Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
About Client Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Configuring the McAfee Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Enabling Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
About Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Managing the Local User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Configuring the Self Service Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Importing Accounts from an Active Directory Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Configuring Active Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Configuring LDAP/LDAPS Authentication Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Configuring the Authentication Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Specifying an External Authentication Home RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
About Guest Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Configuring Guest Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Viewing Guest and Authenticated Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Configure a Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Configure a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Create DHCP Address Ranges in the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Configure AD Servers for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Bind DHCP Ranges to the Quarantined and Authorized Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Configure the Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Configure Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Enable DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Verifying Your Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Chapter 20 File Distribution Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
File Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Enabling and Configuring TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Enabling and Configuring HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Enabling and Configuring FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Managing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Uploading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Creating a Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Modifying File Distribution Storage Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Viewing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Chapter 21 RADIUS Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Understanding RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Infoblox RADIUS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
RADIUS Servers in a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Authentication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Configuring RADIUS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Managing User Accounts in the Local Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Importing Users From a Microsoft Active Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Viewing Imported Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Configuration Example: Importing Users from AD Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Troubleshooting AD Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Configuring LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Generating a Self-Signed EAP Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Generating a Certificate Signing Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Uploading Certificates to the Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Downloading Certificates from the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
About RADIUS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Defining Policies for User Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Using RADIUS Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Configuring RADIUS Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Managing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Configuring RADIUS Policy Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Managing Policy Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Assigning a Policy Group to a Grid Member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Network Access Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Enabling RADIUS Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
RADIUS Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Understanding RADIUS Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
RADIUS Home Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Configuring a RADIUS Authentication Home Server Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Configuring a RADIUS Accounting Home Server Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Managing RADIUS Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Proxying RADIUS Access-Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Viewing the RADIUS Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Proxying RADIUS Accounting-Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Removing Home Servers and Shared Secret Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Chapter 22 IPAM WinConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Configuring IPAM WinConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Uploading a WinConnect Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Viewing Bundle Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Managing the WinConnect Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Configuring the WinConnect Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Backing Up and Restoring Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Monitoring WinConnect Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Chapter 23 VitalQIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
About VitalQIP on a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
HA Pair Grid Members. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Deploying Grid Members as VitalQIP Remote Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Uploading and Enabling VitalQIP Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Launching VitalQIP on the Grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Configuring Grid Members on the VitalQIP Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Using LDRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
DHCP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Monitoring VitalQIP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Troubleshooting Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Part 4 API Interface
Chapter 24 Infoblox DMAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Introduction to Infoblox DMAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Required Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Installing Perl and Infoblox DMAPI Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Infoblox DMAPI Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Infoblox Scripting Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Running a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Testing the Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Backing Up the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Writing a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Perl Information Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Infoblox-Specific Perl Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Perl Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Part 5 Reference Material
Appendix A Product Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Power Safety Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
DC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Agency Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
FCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Canadian Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
VCCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
RFC Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
DNS RFC Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
DHCP RFC Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Appendix B Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Supported Expressions for Search Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Appendix C Open Source Copyright and License Statements . . . . . . . . . . . . . . . . . . . . 695
GNU General Public License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
GNU Lesser General Public License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Apache Software License version 1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
perl Artistic License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
ISC BIND Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
ISC DHCP Copyright. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Julian Seward Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Carnegie Mellon University Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Thai Open Source Software Center Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Ian F. Darwin Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Lawrence Berkeley Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
MIT Kerberos Copyright. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
BSD License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
David L. Mills Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
OpenLDAP License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
OpenSSL License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
VIM License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
ZLIB License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Wietse Venema Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
ECLIPSE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Appendix D Hardware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
About the Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Identifying the Front Panel Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Using the LCD Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Using the Serial Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
About Back Panel Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Connecting the Ethernet Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Independent Appliance Cabling Using the LAN or Serial Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
HA Pair Appliance Cabling Using the LAN and HA Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Cabling for the MGMT Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Rack Mounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Chassis Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Rack Mounting and Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Hardware Platform Specifications and Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
System Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Environmental Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
AC Electrical Power Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
DC Electrical Power Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733

Preface
This guide explains how to install, configure, and manage a NIOS appliance. This preface describes the content and
organization of this guide, and provides information about how to find additional product information, including
accessing Technical Support:
Document Overview on page 20
Documentation Organization on page 20
Documentation Conventions on page 22
Whats New on page 24
Related Documentation on page 24
Customer Care on page 25
User Accounts on page 25
Software Upgrades on page 25
Technical Support on page 25
Preface
20 Infoblox Administrator Guide (Rev. A) NIOS 4.3r1
Document Overview
This guide describes how to install, configure, and manage NIOS appliances using NIOS 4.3r1. This manual was last
updated on July 27, 2008. For updated documentation, visit our Support site at: http://support.infoblox.com.
Documentation Organization
This guide consists of five parts, as described in the following table.
Section Content
Part 1 Appliance Administration Chapters 1 7
Chapter 1, Overview, on page 29 Provides general information about the NIOS software, plus
provides definitions of the terms used to explain how NIOS
appliances operate. It provides examples of how the appliances
can be used in your network.
Chapter 2, Infoblox GUI, on page 37 Explains how to use the GUI of the NIOS appliance by defining
what the GUI components are and how to use them.
Chapter 3, Managing Administrators, on
page 65
Explains how to configure and manage administrator groups and
accounts in the local database and on external RADIUS servers.
Chapter 4, Managing Appliance
Operations, on page 115
Explains how to configure NTP, secure administrative access, set
routes, enable DNS resolution, activate licenses, and reset the
NIOS appliance. It also provides information about ethernet and
service port usage.
Chapter 5, Monitoring the Appliance, on
page 159
Explains the purpose of the various logs and provides
information on using syslog to monitor the NIOS appliance.
Chapter 6, Monitoring with SNMP, on page
175
Explains how to configure SNMP to monitor the NIOS appliance.
It also describes the SNMP traps that the NIOS appliance can
send and the Infoblox MIBs.
Chapter 7, Changing Software and
Merging Files, on page 219
Explains how to upgrade and downgrade software, and how to
backup, merge, revert, and restore configuration files.
Part 2 Appliance Deployment Chapters 8 9
Chapter 8, Deploying Independent
Appliances, on page 231
Explains how to deploy single independent appliances and
independent HA (high availability) pairs.
Chapter 9, Deploying a Grid, on page 267 Addresses grid deployment considerations and explains how to
deploy single NIOS appliances and HA pairs as grid masters and
members.
Part 3 Service Configuration Chapters 10 18
Chapter 10, Managing DNS Data, on page
331
Explains how to manage grid data configurations that are
inherited by DNS members and zones, such as zone type and
mapping information. This chapter also describes how to
configure Infoblox views and how to modify, remove and disable
authoritative, delegated, and forward zones. It concludes with
how to add, modify, remove, and disable hosts and records.
Document Overview
Chapter 11, Shared Records, on page 411 Explains how to configure and use shared records. Shared
records are groups of DNS resource records that you can assign
to one or more zones. Use shared records to create and update
multiple resource records shared by different zones.
Chapter 12, Configuring DNS Services, on
page 423
Explains how to configure the DNS services provided by the grid,
which includes time-to-live (TTL) settings, zone transfers,
queries, root name servers, dynamic updates, sort lists, and
Transaction Signatures (TSIG) for DNS. This chapter also
describes how to specify broadcast addresses, routers, and DNS
servers. It describes how to specify and update zones on
external servers and for fixed addresses. This chapter concludes
with how to use the view DNS configuration files and statistical
reports.
Chapter 13, Configuring IP Routing Options,
on page 449
Explains how to enable and configure anycast addressing as well
as configure multiple IP address on loopback interfaces on the
NIOS appliance.
Chapter 14, Managing DHCP Data, on page
459
Explains how to configure networks, and features such as
creating split and shared networks. This chapter also describes
how to modify, remove and disable networks. This chapter
concludes with how to add, modify, remove, and disable fixed
addresses and DHCP address ranges. Templates are provided for
creating networks, ranges, and fixed addresses.
Chapter 15, Configuring DHCP Services, on
page 483
Explains how to manage grid data configurations that are
inherited by DHCP members and networks, DHCP address
ranges, and fixed addresses. This chapter explains how to
configure the DHCP services provided by each member, which
includes lease times, BOOT servers, and custom options. This
chapter concludes with how to use the view DHCP configuration
files and statistical reports.
Chapter 16, Using Network Discovery, on
page 519
Explains how to configure and manage the network discovery
feature.
Chapter 17, Configuring DDNS Updates
from DHCP, on page 537
Explains how to set up DHCP and DNS services to work together
to support DDNS (dynamic DNS) updates.
Chapter 18, Managing IP Data IPAM, on
page 557
Explains how to monitor IP address usage using the IPAM (IP
address management) software module.
Chapter 19, NAC Foundation, on page 581 Provides an overview of the NAC Foundation module and its
components, and describes how to set parameters and
configure various security functions.
Chapter 20, File Distribution Services, on
page 605
Explains the TFTP, HTTP and FTP services that the NIOS appliance
provides for uploading and downloading data to and from a NIOS
appliance.
Chapter 21, RADIUS Services, on page 613 Explains how to configure RADIUS services on a NIOS appliance.
Chapter 22, IPAM WinConnect, on page
643
Explains how to configure a NIOS appliance to run the IPAM
WinConnect service. This chapter describes how to upload an
IPAM WinConnect bundle, set operational parameters, and
monitor the WinConnect service.
Section Content
Preface
Documentation Conventions
The text in this guide follows these style conventions.

Variables
Infoblox uses the following variables to represent values that you type, such as file names and IP addresses:
Chapter 23, VitalQIP, on page 647 Explains how to configure NIOS appliances as VitalQIP DNS
and DHCP remote servers. This chapter describes how to
configure NIOS appliances to upload and manage VitalQIP
binary bundles and policy files in a grid.
Part 4 API Interface Chapter 22
Chapter 24, Infoblox DMAPI, on page 665 Provides an overview of the DMAPI interface and describes how
to set up and use the Infoblox API.
Part 5 Reference Material Appendices A D
Appendix A, "Product Compliance", on
page 687
Provides product information, such as hardware and software
specification and requirements. This appendix also supplies
agency compliance and safety information and concludes with
RFC compliance information for the product.
Appendix B, "Regular Expressions", on
page 693
Lists regular expressions that the NIOS appliance supports for
searches.
Appendix C, "Open Source Copyright and
License Statements", on page 695
Provides the Open Source copyright and license information for
the product.
Appendix D, "Hardware Information", on
page 721
Describes the hardware components and explains how to
rackmount and cable an Infoblox appliance. It also lists the
hardware requirements and specifications.
Style Usage
bold Indicates anything that you input by clicking, choosing, selecting, or typing in the GUI, or by
pressing on the keyboard.
input Signifies command line entries that you type.
variable Signifies variables typed into the GUI that you need to modify specifically for your
configuration, such as command line variables, file names, and keyboard characters.
+ (for tabname)
> (for tabname)
Indicates that you will select the named tab.
Variable Value
admin_group Name of a group of administrators
admin_name Name of the appliance administrator
addr_range IP address range
DHCP_template DHCP template
Section Content
Document Overview
Navigation
Infoblox technical documentation uses an arrow -> to represent navigation through the GUI. For example, to access
Grid Properties, the description is as follows:
From the Grid perspective, click grid -> Edit -> Grid Properties.
domain_name Domain name
directory Directory name
filter_name Filter name
fixed_address_template Fixed address template
grid_master Grid Master
grid_member Grid Member
hostname Host name of an independent appliance
grid Grid name
ip_addr IPv4 address
member Grid member name
netmask Subnet mask
network IP address of a network
network_access_server Name of a NAS
network_template Network template
policy Name of a policy on RADIUSone
policy_group Name of a Policy Group
port Number of a port; predefined for certain protocols
RADIUS_server Name of a RADIUS server
service One of the services available from the Grid Manager
template_type DHCP template
view Infoblox view
zone DNS zone
Variable Value
Preface
Whats New
The following sections are new or have been updated in this version of this guide:
NIOS Virtual Appliance for Riverbed You can now install the Infoblox NIOS software on Riverbed Steelhead
appliances running the Riverbed RiOS Services Platform (RSP), and configure them as single virtual grid
members.
The joint Infoblox-Riverbed solution supports hybrid environments that include a mix of physical Infoblox
appliances and NIOS virtual appliances depending on branch office requirements. Each NIOS virtual appliance
appears to the grid as any other grid member, with all of the benefits of distributed services and centralized
management. This includes centralized backup and restoration of user data, DHCP failover capabilities,
one-touch software upgrades, local RADIUS authentication, DNS without latency, and many other benefits of
the Infoblox solution. For information, see Scenario 3 Infoblox Grid with a NIOS Virtual Appliance as a Grid
Member on page 34 and Adding Grid Members on page 288.
For information on supported features and how to install the NIOS software on the RSP, refer to the Quick Start
Guide for Installing NIOS Software on Riverbed Services Platforms.
Network Discovery You can use network discovery to obtain and manage information about your networks.
When you use network discovery, the NIOS appliance detects all active hosts on the networks you select for
discovery. After a discovery, the appliance returns information such as the MAC address, OS, and NetBIOS name
of the detected hosts, depending on which discovery method you use. You can then convert unmanaged IP
addresses to host records or other object types. You can also resolve network conflicts, troubleshoot network
problems, reclaim unused IP addresses, and view unauthorized devices in your network. For information, see
Chapter 16, Using Network Discovery, on page 519.
Role Based Administration You can now group global and object-level permissions into roles and assign up to
20 roles to an admin group. The NIOS appliance provides five pre-defined roles and you can create additional
roles to emulate the job functions in your organization, e.g., DHCP administrators for the Boston data center.
You can also view any conflicting permissions and easily resolve conflicts by reordering roles or adjusting
permissions. For information, see Chapter 3, Managing Administrators, on page 65.
Upgrade Test After you successfully distribute the software upgrade to the grid master, you can test the
upgrade on the grid master before actually implementing it. Therefore you can resolve potential data migration
issues before the actual upgrade. For information, see Testing a Software Upgrade on page 319.
Multilingual Support NIOS appliances now support UTF-8 encoding in certain fields, such as all comment
fields, IPAM fields that you use to classify devices, and file name fields for FTP and TFTP backup and restore
operations. Administrators can now use characters other than English to input information in those fields thus
simplifying administration in non-English speaking geographies. For information, see Multilingual Support on
page 58.
Related Documentation
Other NIOS appliance documentation:
Infoblox CLI Guide
Infoblox-500, Infoblox-1000 and Infoblox-1200 Quick Start
Infoblox User Guide for the Infoblox-1050, 1550, and 1552 Appliances
Infoblox User Guide for the Infoblox-500, 550 Appliance
Infoblox Installation Guide for the Infoblox--550, -1050, 1550, and 1552 Appliances
Infoblox Installation Guide for the Infoblox-250 Appliance
Infoblox Installation Guide for the Infoblox-2000 Appliance
Quick Start Guide for Installing NIOS Software on Riverbed Services Platforms
Infoblox Safety Guide
To provide feedback on any of the Infoblox technical documents, please e-mail techpubs@infoblox.com.
Customer Care
Customer Care
This section addresses user accounts, software upgrades, licenses and warranties, and technical support.
User Accounts
The Infoblox appliance ships with a default user name and password. Change the default admi n account password
immediately after the system is installed to safeguard its use. Make sure that the NIOS appliance has at least one
administrator account with superuser privileges at all times, and keep a record of your account information in a safe
place. If you lose the admi n account password, and did not already create another superuser account, the system will
need to be reset to factory defaults, causing you to lose all existing data on the NIOS appliance. You can create new
administrator accounts, with or without superuser privileges. For more information, refer to Managing Administrators
on page 41.
Software Upgrades
Software upgrades are available according to the Terms of Sale for your system. Infoblox notifies you when an
upgrade is available. Register immediately with Infoblox Technical Support at
http://www.infoblox.com/support/product_registration.cfm to maximize your Technical Support.
Technical Support
Infoblox Technical Support provides assistance via the Web, e-mail, and telephone. The Infoblox Support web site at
http://support.infoblox.com provides access to product documentation and release notes, but requires the user ID
and password you receive when you register your product online at:
http://www.infoblox.com/support/product_registration.cfm.
Preface

Part 1 Appliance Administration
This section provides basic information about the NIOS appliance, including a description of the various modules
and a list of product terminology, a description of the user interface and information about basic configuration tasks.
It includes the following chapters:
Chapter 1, "Overview", on page 29
Chapter 2, "Infoblox GUI", on page 37
Chapter 3, "Managing Administrators", on page 65
Chapter 4, "Managing Appliance Operations", on page 115
Chapter 5, "Monitoring the Appliance", on page 159
Chapter 6, "Monitoring with SNMP", on page 175
Chapter 7, "Changing Software and Merging Files", on page 219

Chapter 1 Overview
This chapter provides general information about the NIOS appliance operating system and software modules. It
defines terms used in this manual and describes various deployment scenarios. The topics in this chapter include:
NIOS Appliance Software Packages and Upgrades on page 30
Product Terminology on page 30
Deployment Scenarios on page 32
Scenario 1 Independent NIOS Appliances on page 32
Scenario 2 Basic Grid with Independent NIOS Appliances on page 33
Scenario 3 Infoblox Grid with a NIOS Virtual Appliance as a Grid Member on page 34
Scenario 4 Multiple Grids on page 35
Scenario 5 Primary and Secondary NIOS Appliances on page 36
Overview
NIOS Appliance Software Packages and Upgrades
All NIOS appliances run the NIOS operating system. NIOS appliances provide core services and a framework for
integrating all the components of the modular Infoblox solution. The appliances support local HA (high availability)
both at the appliance and database levels via bloxHA failover and bloxSYNC database synchronization. For
information about HA pairs, see Deploying an Independent HA Pair on page 245 and Adding an HA Member on page
289.
NIOS appliances support the following software packages:
The DNSone software package is fully-BIND compliant. It provides integrated DNS and DHCP services with
built-in IPAM services. DNSone stores all DNS and DHCP data in the integrated bloxSDB semantic database,
which is built into NIOS. It includes a TFTP server for downloading firmware and configuration files to VoIP
phones.
The NSQ (Network Services for Alcatel-Lucent VitalQIP)software package provides support for Lucents
VitalQIP IP address management software.
The Keystone upgrade provides a real-time, integrated services and data management framework that
integrates a collection of distributed appliances into a unified grid.
The Network Services for VoIP package provides integrated DNS, DHCP, TFPT, and RADIUS proxy services.
The NSA (Network Services for Authentication) software package provides support for the RADIUS (Remote
Authentication Dial-In User Service) protocol and the underlying authentication methods required for 802.1X
authentication, as well as the Infoblox grid module.
The Network Services Suite (NSS) provides integrated DNS, DHCP, TFPT, RADIUS, and the grid services.
The IPAM WinConnect package provides powerful tools and capabilities for managing your IP environment and
IP address data at an enterprise level.
Product Terminology
Before you begin, review Table 1.1 for a description of some key terminology. Some terms, such as grids and high
availability, are used in different ways by other networking-product vendors. The alphabetically arranged table can
help you understand the terms and concepts as Infoblox uses them and as they are used in this guide.
Table 1.1 Product Terminology
Term Description
DNSone The software package that enables the NIOS appliance to provide DNS, DHCP and TFTP
services. You can add the Keystone upgrade to NIOS appliances running DNSone.
Gateway The default router for the immediate network segment of an interface.
HA address The IP address of the HA port. The active node of the grid master uses this address for
grid communications, network data and services, andif the MGMT port is disabledGUI
access. See Ethernet Port Usage on page 132.
HA pair Two physical Infoblox appliances that are linked to perform as a single virtual appliance
in an HA (high availability) configuration. In this configuration, one appliance is the active
node and the other is the passive node.
Host name The fully qualified domain name(s) of the NIOS appliance that you are configuring.
Grid A group of NIOS appliances that are connected together to provide a single point of
appliance administration and service configuration in a secure, highly available
environment.
Product Terminology
Grid Master The grid member that maintains the semantic database that is distributed among all
members of the grid. You connect to the GUI of the grid master to configure and monitor
the entire grid.
Grid Member Any single NIOS appliance or HA pair of Infoblox appliances that belong to a grid. Each
member can use the data and the services of the grid. You can also modify settings so
that a member can use unique data and member-specific services.
Keystone The Keystone upgrade provides grid capabilities.
LAN address The IP address of the LAN port. The active node of the grid master uses this address for
management protocols if the MGMT port is disabled. The passive node uses its LAN port
for grid communications and management protocols if the MGMT port is disabled. See
Ethernet Port Usage on page 132.
Master Candidate Enables a grid member to assume the role of grid master as a disaster recovery measure.
MGMT Address The IP address that both nodes comprising the grid master use for management
protocols. Also, when you enable the MGMT port, the active node of the grid master uses
the MGMT address for GUI access. See Ethernet Port Usage on page 132.
NIOS appliance Infoblox appliances and Infoblox Virtual Appliances that run NIOS software.
NIOS virtual appliance A Riverbed Steelhead appliance with the Riverbed Services Platform module that runs the
NIOS software.
Node A single component of an HA (high availability) pair. An HA pair consists of an active node
and a passive node.
Service configuration Specifying the services provided by your NIOS appliances, such as enabling DNS and
DHCP, configuring dynamic updates, creating sort lists, using custom options and filters
at the grid, member, zone, and network level.
Virtual IP The shared IP address of an HA pair. A VIP address links to the HA port on the active node.
Virtual Router ID The VRID (virtual router ID) identifies the VRRP (Virtual Router Redundancy Protocol) HA
pair to which the NIOS appliance belongs. Through this ID, two HA nodes identify each
other as belonging to the same HA pair and they obtain a virtual MAC address to share
together with a VIP (virtual IP address). The VRID can be any number between 1 and 255,
and it must be unique on the local LAN so that it does not conflict with any other NIOS
appliances using VRRP on the same subnet.
Zone A portion of the domain name space for which a NIOS appliance or another name server
is authoritative (for example, has the SOA [start of authority] record). A zone can also be
delegated or forwarded. Zones are the primary objects used to manage DNS data and
DNS services.
Term Description
Overview
Deployment Scenarios
The NIOS appliances can fit into network topologies in a variety of ways, and can provide DNS and DHCP services in
a variety of ways. This section introduces some typical ways that you can deploy your NIOS appliances:
Scenario 1 Independent NIOS Appliances on page 32
Scenario 2 Basic Grid with Independent NIOS Appliances on page 33
Scenario 4 Multiple Grids on page 35
Scenario 5 Primary and Secondary NIOS Appliances on page 36
Scenario 1 Independent NIOS Appliances
The simplest type of deployment is one that uses independent appliances, as shown in Figure 1.1.
Figure 1.1 Independent NIOS Appliances
In the sample deployment that is shown above, three appliances are deployed as independent appliances as follows:
An independent HA pair of Infoblox appliances that provides DNS services
An independent standalone Infoblox appliance that provides DHCP services
An Infoblox appliance can provide network services as an HA pair or as an independent appliance without being part
of a grid. Independent appliances can provide DNS and DHCP services at the same time.
Note: When an Infoblox appliance is used as an independent appliance, that appliance assumes the identity of the
grid master in the GUI, even though it is not part of an actual grid.
GUI Client
Independent HA Pair
Providing DNS
Services
Internet
Network
Clients
Independent Appliance
Providing DHCP
Services
Scenario 2 Basic Grid with Independent NIOS Appliances
Multiple NIOS appliances can be deployed within a grid (see Figure 1.2). A grid consists of a master and at least one
member. A member can be a single NIOS appliance or an HA pair that provides DNS and DHCP services seamlessly
across an entire network. The NIOS appliance also provides connectivity for external primary name servers that
operate independently from a grid.
Figure 1.2 Grid and Independent Appliances

A grid is controlled through a single GUI. The Infoblox GUI allows you to centrally configure and monitor any or all grid
members. This approach reduces the time normally required to configure multiple network appliances and services
because you can enter all of the settings, appliance data, and network services for each member using one interface,
not all the individual interfaces of each member on a recurring basis.
The Infoblox distributed database architecture enables all grid members to instantaneously receive changes to the
grid configuration settings because there is automatic synchronization between all of the NIOS appliances via a
secure link.
Grid Master
Grid Member
Internet
Network
Clients
HA Grid Member
Independent Primary
Server
Independent DNS
Secondary Server
GUI
Client
Grid
Overview
Scenario 3 Infoblox Grid with a NIOS Virtual Appliance as a Grid Member
You can install Infoblox NIOS software on a Riverbed Steelhead appliance running RSP (Riverbed Services Platform)
and configure it as a NIOS virtual appliance. You can configure the NIOS virtual appliance as a grid member, but not
as an HA pair, a grid master, or a grid master candidate.
Figure 1.3 illustrates the NIOS virtual appliance in a grid. In the illustration, the grid master and the grid master
candidate are Infoblox HA pairs in the data center. The NIOS virtual appliance is a grid member in a branch office, and
the other grid members are Infoblox appliances.
Figure 1.3 Infoblox Grid with a NIOS Virtual Appliance
Data Center
Branch Office - East
Branch Office - South
Grid Master
Branch Office - West
Grid Master Candidate
Branch Office - North
NIOS Virtual Appliance
Scenario 4 Multiple Grids
The NIOS appliance is designed to manage independently-controlled grids, each from a unique location (see
Figure 1.4). For example, a global network could be managed by four independent grids. The NIOS appliance is
designed for scalable implementations to ease your network management needs. Each grid is centrally managed,
which significantly reduces costs associated with DNS and DHCP management tasks.
Figure 1.4 Multiple Grids

Asia/PAC
Grid
Australian
Grid
Americas
Grid
European
Grid
GUI Clients
Overview
Scenario 5 Primary and Secondary NIOS Appliances
NIOS appliances can also be deployed with other network servers. For example, Figure 1.5 shows how a NIOS
appliance can operate as the primary DNS server along with two secondary name servers (a local secondary name
server and a NIOS appliance external secondary server) without the NIOS appliances being part of a grid.
The primary DNS server is deployed inside the corporate internal firewall. In this case, the primary DNS server is an
HA pair of Infoblox appliances, which provides redundancy in the event of hardware failure. The NIOS appliance
external secondary name server is deployed outside of the companys internal firewall. In this case, the NIOS
appliance external secondary name server is a single NIOS appliance, but it could have been an HA pair.
Figure 1.5 Primary and Secondary Servers

Because the external secondary name server is outside of the corporate network, it provides an offsite source of name
resolution for the corporate customers and partners should the corporate connection to the Internet fail. Moreover,
even when the corporate link to the Internet is up, the external secondary server receives most of the queries for data
in the corporate external zones. This type of deployment results in the following benefits:
The use of the corporate Internet connection for name resolution traffic is minimized.
Name resolution by Internet name servers is faster.
NIOS appliances can also operate as forwarders or caching-only servers, either as a single node or as part of an HA
pair. A forwarder is responsible for handling queries from the internal name servers for Internet domain names
(queries that they cannot process themselves because they lack Internet connectivity).
Just as the primary DNS server is located inside the corporate internal firewall, the forwarder is also located inside
the firewall. Consequently, you must configure firewall rules that allow the forwarder to perform the following tasks:
Send queries to the Internet name servers
Receive responses from those Internet name servers
Block unsolicited DNS messages from the Internet name servers
GUI Client
Independent HA Pair
(Primary Server)
Internet
Network Clients
Independent Appliance
(External Secondary Server)
DNS Server
(Secondary Server)

Chapter 2 Infoblox GUI
This chapter introduces the two versions of the Infoblox GUI (Graphical User Interface):
Infoblox Grid Manager GUI for NIOS appliances running a software package, such as DNSone or the NSQ
(Network Services for Lucent VitalQIP) package, with the Keystone upgrade
Infoblox Device Manager GUI for NIOS appliances running a software package without the Keystone upgrade
The chapter lists the requirements for the management system you use to access a NIOS appliance, explains how to
access the NIOS appliance, and describes the components of the Infoblox Grid Manager GUI. Topics in this chapter
include:
Management System Requirements on page 38
Accessing the Infoblox GUI on page 38
Connecting to a NIOS Appliance with JWS (Java Web Start) on page 39
Installing the Grid Manager on page 43
Connecting to a NIOS Appliance Using the Grid Manager on page 44
SSL (Secure Sockets Layer) Protocol on page 47
Managing Certificates on page 48
Understanding the GUI Components on page 50
Main Interface Components on page 50
Customizing a Perspective Layout on page 53
Creating a Login Banner on a NIOS Appliance on page 54
Customizing Columns on page 54
Using Global Search on page 55
Printing from the GUI on page 56
Multilingual Support on page 58
UTF-8 Supported Fields on page 58
UTF-8 Support Limitations on page 58
International Characters Support for RADIUS Authentication on page 59
Exporting Data on page 60
Exporting Data from Panels on page 60
Exporting Data to a CSV File on page 62
Infoblox GUI
Management System Requirements
The management system is the computer from which you configure and manage the NIOS appliance. The
management system must meet the following requirements to operate a NIOS appliance.
Figure 2.1 Software and Hardware Requirements for the Management System
Note: If the browser used to manage the NIOS appliance has a pop-up blocker enabled, you must turn off the pop-up
blocker for the IP address used to manage the NIOS appliance.
Accessing the Infoblox GUI
Before you access the Infoblox GUI, connect your NIOS appliance to the network as described in the installation
guide, user guide or quick start guide that shipped with your product. Refer to Hardware Information on page 721 for
more information on cabling and powering up the NIOS appliance.
Note: Before proceeding, make sure that your computer meets the current requirements for the GUI client as
described in Management System Requirements.
You can access and log in to a NIOS appliance using JWS (Java Web Start). You can use any computer on your network
that runs the following applications:
JRE (Java Runtime Environment) version 1.5.0_14 or version 1.6
JWS application, which is automatically installed with the corresponding version of the JRE
Standard browser that associates JNLP (Java Network Launching Protocol) file types with the JWS application
Alternatively, you can install the Grid Manager on management systems running one of the supported Microsoft
Windows operating systems, as described in About The Grid Manager on page 43.
Management System Software Requirements Management System Hardware Requirements
GUI ACCESS
Microsoft
Internet Explorer
6.0 or higher
on Microsoft Windows XP
and Internet
Explorer 7.0 on Windows Vista
or
Mozilla 1.7 or higher on Linux
Fedora Core 5 or higher, Red Hat
and
Sun Java Runtime Environment (JRE)
version 1.5.0_14 or version 1.6
JWS application, which is automatically
installed with JRE 1.5.0_14 or higher
CLI ACCESS
Secure Socket Shell (SSH) client that
supports SSHv2
Terminal emulation program, such as
minicom or Hilgraeve Hyperterminal
.
Minimum System:
500 MHz CPU with 256 MB RAM available to
the product GUI, and 56 Kbps connectivity to
NIOS appliance
Recommended System:
1 GHz (or higher) CPU with 512 MB RAM
available for the product GUI, and network
connectivity to NIOS appliance
Monitor Resolution:
1024 x 768 (minimum) to 1600 x 1200
(maximum)
Connecting to a NIOS Appliance with JWS (Java Web Start)
To make an initial management connection to the NIOS appliance using JWS:
1. Start your browser, and enter https://ip_addr, where ip_addr is the IP address of the NIOS appliance that you
entered through the LCD or serial port, or the default IP address 192.168.1.2. See Using the LCD Panel on page
723 and Using the Serial Console on page 723.
The NIOS appliance sends its server certificate to the browser to authenticate itself during the SSL (Secure
Socket Layer) handshake. Because the default certificate is self-signed, your browser does not have a trusted
CA (certificate authority) certificate or a cached NIOS appliance server certificate (saved from an earlier
connection) to authenticate the NIOS appliance certificate. Also, the host name in the default certificate is
www.infoblox.com, which is unlikely to match the host name of your NIOS appliance. Consequently, messages
appear warning that the certificate is not from a trusted certifying authority and that the host name on the
certificate is either invalid or does not match the name of the site that sent the certificate.
Note: To eliminate certificate warnings, you can replace the default self-signed certificate with a different
certificate that has the host name of your NIOS appliance. You can either generate another self-signed
certificate with the right host name and save it to the CA certificate store of your browser (and, later in the
procedure, to the certificate stores for JWS and the downloaded GUI application), or request a CA-signed
certificate with the right host name and load it on the NIOS appliance. For information, see Managing
Certificates on page 48.
2. Either accept the certificate just for this session or save it to the certificate store of your browser.
3. On the NIOS appliance home page, click Launch Grid Manager or Launch Device Manager.
The browser and JWS perform the following operations:
a. The browser requests the JNLP (Java Network Launching Protocol) file from the NIOS appliance and
sends the file it receives to JWS (Java Web Start).
b. JWS checks for the JNLP file in its cache and, if it finds it, compares it with the recently received JNLP file.
Because this is the initial connection attempt, JWS does not yet have this file cached. In subsequent
connection attempts, comparing the newly downloaded JNLP file with the cached file can indicate
whether JWS needs to update any items that the file specifies.
c. If JWS discovers there is no cached JNLP file or that the new JNLP file differs from the earlier file, JWS
builds an SSL tunnel to the sources specified in the JNLP file. For this initial connection, JWS must make
an SSL connection to the NIOS appliance to download the GUI application.
JWS displays a security warning prompting you to accept or reject the NIOS appliance certificate the NIOS
appliance sends to authenticate itself. If the default certificate is in use, warning messages appear
stating the certificate is not from a trusted certifying authority, and that the host name on the certificate
is either invalid or does not match the name of the site. This is the same certificate that the NIOS
appliance uses to authenticate itself during all SSL handshakes.
4. Either accept the NIOS appliance server certificate just for this SSL session, or save it permanently to the JWS
server certificate store.
After the SSL tunnel is established, the NIOS appliance begins to download the GUI application, which is signed
with a different certificate than the server certificate the NIOS appliance uses to authenticate itself during SSL
handshakes. The certificate authenticating the GUI application is signed by Verisign. When received by JWS, it
displays a security warning prompting you to accept or reject the signed application.
5. Do one of the following:
Click Yes to accept the authenticity of the Infoblox GUI application for this download.
Click Always to accept the authenticity of the Infoblox GUI application for this and future downloads by
saving the certificate to the JWS application certificate store.
Note: To manage server certificates in JWS, open the Java Application Cache Viewer, and then click Edit ->
Preferences -> Security -> Certificates.
Infoblox GUI
JWS downloads the Infoblox GUI application and any other items it needsor, for subsequent connections, just
the items it needs to update. For this initial connection, JWS downloads the GUI application. It might also
download a different version of JRE. The NIOS appliance supports JRE 1.5.0_14 or JRE 1.6.
6. After the Infoblox GUI application download is complete, begin the login process by choosing the host name of
the NIOS appliance from the Hostname drop-down list.
7. Enter the user name and password. The default user name is admin, and the default password is infoblox.
Note: The user name and password are case-sensitive. Infoblox recommends changing them after you log in. For
more details, refer to Authenticating Administrators on page 101.
To reuse the same user name, select Options -> Save User Name. The NIOS appliance saves the user name and it
appears automatically the next time you invoke the GUI.
The GUI application initiates an SSL connection to the NIOS appliance. The NIOS appliance sends its server
certificate to authenticate itself to the application. If the default certificate is in use, warning messages appear
stating the certificate is not from a trusted certifying authority and that the host name on the certificate is either
invalid or does not match the name of the site.
8. Accept the certificate for this session, or save it permanently to the server certificate store of the GUI application.
Note: To manage CA (Certificate Authority) and server certificates in the Infoblox GUI application, open the GUI
application login prompt, and select Options -> Manage Certificates.
The SSL tunnel completes, and the login process continues. If the login is successful, the connection between
the Infoblox GUI application and the NIOS appliance is complete. If the login is not successful, an error message
appears and the login prompt returns.
When the session ends, the Infoblox GUI application remains in the Java sandbox. You can launch it from this
location the next time you want to connect to the NIOS appliance.
Figure 2.2 Java Web Start Initial Access
After you make the initial connection, you can start the Infoblox GUI application with one of these methods:
Browser This is identical to the initial connection. Start your browser, and enter https://domain_name or
https://ip_addr to reach the NIOS appliance.
Infoblox GUI Application Shortcut If you created a shortcut (when prompted by JWS), double-click the shortcut
icon on your desktop. JWS checks the JNLP file and the NIOS appliance resource files (.jar files containing
components of the Infoblox GUI application) for updates. JWS downloads any updated items it might find, and
then the GUI application login prompt appears.
Java Application Cache Viewer Open the Java Application Cache Viewer, and click the Infoblox GUI application
that you want to use. Then click either Launch Online or Launch Offline. When you select Launch Online, JWS
checks the JNLP file and the NIOS appliance resource files for updates before the GUI application connects to
the NIOS appliance. When you select Launch Offline, JWS does not check for updates before the Infoblox GUI
application connects to the NIOS appliance.
2
3
1
+
J ava
Sandbox
Browser
Certificates
GUI
Application
Management Client
J ava
Certificates
Browser
SSL Tunnel
NIOS appliance
GUI
Certificates
Infoblox GUI
Application
= CA (Certificate Authority) Certificates
= Server Certificates
= J ava Application Certificates
= Application Certificate
(authenticates GUI application
during download)
= Infoblox Server Certificate
(authenticates the appliance when
establishing an SSL tunnel)
Commands
J NLP File Download
GUI Application Download
Certificate
authenticating
the appliance to
management
system browser
The browser and appliance form an SSL
tunnel. The browser either accepts the
appliance certificate automatically or the
administrator accepts it manually. Then
the browser downloads the J NLP (J ava
Network Launching Protocol) file and
passes it to the J ava application.
The J NLP files instructs J ava to check if it
has the latest GUI application and
downloads it if necessary. J ava and the
appliance form a new SSL tunnel between
themselves. If J ava automatically accepts
the two certificatesone authenticating
the appliance and the other authenticating
the GUI applicationor if the administrator
accepts them manually, the GUI
application download proceeds.
The Infoblox GUI application and the
appliance form a third SSL tunnel. If the GUI
application accepts the appliance certificate
automatically or the administrator accepts it
manually, the administrator can complete the
login and begin sending commands to the
appliance.
Certificates
authenticating
appliance and
downloaded GUI
application to
J ava application
Certificates
authenticating
an appliance to
GUI application
Infoblox GUI
Running a Single GUI Application
JWS can use the same Infoblox GUI application for different NIOS appliances as long as each NIOS appliance is
running the same version of software. However, each time you use the browser to initiate a connection to a different
NIOS appliance, JWS downloads the GUI application to the Java sandboxeven if you have already downloaded the
same version of the application when connecting to another NIOS appliance. If you manage a number of independent
NIOS appliances, this can result in many unnecessary downloads. To use the same GUI application for multiple NIOS
appliances running the same software version, do not begin the connection process from the browser. Instead, do
the following:
1. Use the GUI application shortcut or open the Java Application Cache Viewer.
2. Click the GUI application that you want to use, and then click Launch Online (to check for updates) or Launch
Offline (to bypass update checks).
Figure 2.3 Java Application Cache Viewer
3. When the login prompt appears, either select an existing host name from the Hostname drop-down list, or type
a new host name in the Hostname field. Then enter the correct user name and password, and click Login.
Clearing Cache on a Linux Computer
The following error message usually indicates that you must clear your Linux computer cache:
Ser ver sof t war e ver si on xx- xx- xx i s not compat i bl e wi t h t hi s GUI appl i cat i on. Obt ai n a
compat i bl e GUI ver si on by poi nt i ng a br owser at ht t ps: / / xx. xx. xx. "
Enter the following commands on a Linux terminal window to clear your computer's cache:
cd / . j ava/ depl oyment / cache/ j avaws
r m- r f ht t ps
This clears the cache.
1. Open a web browser and go to the same web address (https://xx.xx.xx).
2. Click Launch ID Grid.
GUI Application for
the NIOS appliance
About The Grid Manager
You can install the Infoblox Grid Manager on a computer running any of the following Microsoft Windows operating
systems:
Microsoft Windows XP with Service Pack 2
Microsoft Windows Vista with Service Pack 1
The Grid Manager installs the NIOS appliance JRE files and GUI application files in a container within a Java sandbox
on your computer. After the installation, the files remain in the sandbox and the Grid Manager always launches from
this location. The files in the sandbox are used only by the Grid Manager and do not affect any other Java application
on your system. Thus, your system can have a different version of the JRE for other applications.
The Grid Manager installs a complete, self-contained application package that can handle multiple versions of NIOS.
It automatically caches the GUI version it uses to connect to a NIOS appliance. When you attempt to connect to a NIOS
appliance that is running a different GUI version, the Grid Manager automatically detects the difference and
downloads the other GUI version, after your confirmation. This allows you to easily connect to NIOS appliances
running different versions of the NIOS software. You can configure the number of cached versions on your local
computer as explained in Managing Cache Settings on page 46.
Installing the Grid Manager
Note the following guidelines when installing the Grid Manager:
On a computer running Microsoft Windows XP:
If the computer is in a domain, all users except restricted users can install the Grid Manager.
If the computer is not in a domain, only Administrators can install the Grid Manager.
Users with administrator rights can install the Grid Manager on a computer running Microsoft Windows Vista.
Other users are prompted for the administrator password when they try to install Grid Manager.
These restrictions pertain to the Grid Manager installation only. After it is installed, any user can access the Grid
Manager.
To install the Grid Manager:
1. Download the Grid Manager setup.exe file from the Infoblox Support web site.
2. Double-click the .exe file to launch the Grid Manager Wizard.
3. In the Welcome splash screen, click Next.
4. Accept the License Agreement, and click Next.
5. Verify and/or change information in the Customer Information screen, and click Next.
6. Verify and/or change the local installation folder (C:\Program Files\Infoblox) on your computer, and click Next.
7. Verify the installation settings, and click Install.
The Wizard installs the new files in the destination folder.
8. At the end of the installation procedure, click Finish.
A Launch Infoblox Grid Manager icon appears on the desktop and Infoblox Grid Manager appears in the Start
menu of your computer.
Infoblox GUI
Changing the File Location
Note that in some cases, because of limited permissions or other restrictions, you cannot write to a system file. In
this case, before you launch the Grid Manager, you can change the environment variable to point to a directory for
which you have write permission.
1. Right click My Computer on the desktop.
2. Select Properties -> Advanced tab -> Environment Variables.
3. In the User Environment Variables dialog box, click New.
4. In the New User Variables dialog box, do the following and then click OK:
Type INFOBLOX_UI_CACHE_DIR in the Variable Name field.
Type the name of a directory for which you have write permission in the Variable Value field.
5. Click OK to close the User Environment Variables dialog box.
Connecting to a NIOS Appliance Using the Grid Manager
1. To launch the Infoblox Grid Manager, double-click the Launch Infoblox Grid Manager icon on your desktop or click
Start > All Programs > Infoblox, Inc. > Infoblox Grid Manager > Launch Infoblox Grid Manager.
I f you are launching the Grid Manager for the first time, it detects that there are no installed versions in the
cache and does the following:
Copies the JAR files from the local installation folder to the following location on your management system:
C: \ Document s and Set t i ngs\ user\ Appl i cat i on Dat a\ I nf obl ox\ I nst al l \ NIOS_version
Unpacks the JAR files to the following directory:
C: \ Document s and Set t i ngs\ user\ Appl i cat i on Dat a\ I nf obl ox\ depl oy\ NIOS version
Note that you can change the directory as described in Changing the File Location.
Creates a log file for the GUI deployment called ibdeploy.log.
Launches the login dialog box.
2. Enter the IP address of the NIOS appliance or grid master to which you are connecting.
Infoblox Grid Manager looks for the correct software version in the cache on the computer:
If this is the first time you are connecting to that NIOS appliance, it does not find the files in the cache and
displays a message indicating that the appropriate version of the software is not found in the cache, and
offers to download the new version.
If you click OK, Grid Manager downloads the files to a folder in C: \ Document s and
Set t i ngs\ user\ Appl i cat i on Dat a\ I nf obl ox\ I nst al l \ NIOS version. After the download is
complete, the Infoblox Grid Manager login screen displays.
When you launch Grid Manager to connect to the same NIOS appliance, it detects the server software
information in the current cache and launches using this cache file; if there is a more recent version, it picks
up the more recent version and stores this in the cache.
3. Enter your user name and password. The default user name is admin, and the default password is infoblox.
Note: The user name and password are case-sensitive.
To reuse the same user name, select Options -> Save User Name. The NIOS appliance saves the user name and it
appears automatically the next time you invoke the GUI.
The GUI application initiates an SSL connection to the NIOS appliance. The NIOS appliance sends its server
certificate to authenticate itself to the application. If the default certificate is in use, warning messages appear
stating that the certificate is not from a trusted certifying authority and that the host name on the certificate is
either invalid or does not match the name of the site.
4. Accept the certificate for this session, or save it permanently to the server certificate store of the GUI application.
Note: To manage CA (Certificate Authority) and server certificates in the Infoblox GUI application, open the GUI
application login prompt, and select Options -> Manage Certificates.
The SSL tunnel completes, and the login process continues. If the login is successful, the connection between
the Infoblox GUI application and the NIOS appliance is complete. If the login is not successful, an error message
appears and the login prompt returns.
When the session ends, the Infoblox GUI application remains in the Java sandbox. It launches from this location
the next time you want to connect to the NIOS appliance.
Setting Login Options
The NIOS Login dialog box provides several options that you can set to facilitate the login process.
Specify the Host Name
You can define the default host name that appears when the login prompt displays:
Select Options -> Hostname, and then select one of the following:
Initial: Retains the host name that you enter when you first install the NIOS appliance.
Last used: Enters a host name when you log in and retains it for subsequent logins.
Blank: Leaves the host name blank whenever you log in.
Save User Name
You can save your user name so that you do not have to type it each time you log in.
Select Options -> Save User Name
Manage Certificates
You can manage CA (Certificate Authority) and server certificates in the NIOS appliance. You can import certificates,
select and view their details, or remove them.
1. Select Options -> Manage Certificate.
The NIOS GUI Certificates dialog appears.
2. Select the Server Certificates or the CA Certificates tab and click Import.
3. Navigate to where the certificate is located and click Open.
You can manually import a certificate into the clients data store. You can also delete a certificate (select it and click
Remove) and view detailed information on it (select it and click Details).
Infoblox GUI
Managing Cache Settings
By default, Grid Manager caches 10 NIOS versions on your computer. You can change this default at any time in the
Login dialog box. Each cache file uses approximately 15 MB of disk space. Consider this when setting the number of
cache files for retention. When the system meets the predefined maximum number of cache files, it deletes the first
(oldest) and then adds the new version to the cache file.
To edit the cache settings:
1. Select the Options menu -> Cache Settings.
2. In the Cache Settings dialog box, enter the number of GUI versions to cache. You can enter a number between 2
and 32.
Note that when you use a Linux computer to first connect to a NIOS appliance, JWS automatically downloads the GUI
application to your computer. Though this initial version is retained in the cache, the Grid Manager does not include
it in the total number of cached versions. It includes only the versions that it downloads. Therefore, when your
computer connects to a NIOS appliance that is running a different version and the Grid Manager downloads it to your
computer, it includes this version in the total number of cached versions.
SSL (Secure Sockets Layer) Protocol
When you log in to the NIOS appliance, your computer makes an HTTPS (Hypertext Transfer Protocol over Secure
Sockets Layer protocol) connection to the NIOS appliance. HTTPS is the secure version of HTTP, the client-server
protocol used to send and receive communications throughout the Web. HTTPS uses SSL (Secure Sockets Layer) to
secure the connection between a client and server. SSL provides server authentication and encryption. The NIOS
appliance supports SSL versions 2 and 3.
When a client first connects to a server, it starts a series of message exchanges, called the SSL handshake. During
this exchange, the server authenticates itself to the client by sending its server certificate. A certificate is an electronic
form that verifies the identity and public key of the subject of the certificate. (In SSL, the subject of the certificate is
the server.) Certificates are typically issued and digitally signed by a trusted third party, the Certificate Authority (CA).
A certificate contains the following information: the dates it is valid, the issuing CA, the server name, and the public
key of the server.
A server generates two distinct but related keys: a public key and a private key. During the SSL handshake, the server
sends its public key to the client. Once the client validates the certificate, it encrypts a random value with the public
key and sends it to the server. The server decrypts the random value with its private key.
The server and the client use the random value to generate the master secret, which they in turn use to generate
symmetric keys. The client and server end the handshake when they exchange messages indicating that they are
using the symmetric keys to encrypt further communications.
Figure 2.4 SSL Handshake
Client contacts the NIOS appliance and recommends
certain parameters, such as SSL version, cipher
settings, and session-specific data.
The appliance either agrees or recommends
other parameters. It also sends its certificate
which contains its public key.
Plain
Text
Cipher
Text
Cipher
Text
Cipher
Text
The client and the appliance agree to encrypt
all messages with symmetric keys.
Client encrypts random number with the public
key and sends it to the appliance. The appliance
uses its private key to decrypt the message.
The client and the appliance generate the
master secret, and then the symmetric keys.
The client and the appliance send all their messages through the SSL tunnel
which uses the cipher settings and encryption to secure their connection.
Public Key
Private Key
Infoblox GUI
Managing Certificates
The NIOS appliance generates a self-signed certificate when it first starts. A self-signed certificate is signed by the
subject of the certificate, and not by a CA (Certificate Authority). This is the default certificate. When your computer
first connects to the NIOS appliance, it sends this certificate to authenticate itself to your browser.
Because the default certificate is self-signed, your browser does not have a trusted CA certificate or a cached NIOS
appliance server certificate (saved from an earlier connection) to authenticate the NIOS appliance certificate. Also,
the host name in the default certificate is www.infoblox.com, which is unlikely to match the host name of your NIOS
appliance. Consequently, messages appear warning that the certificate is not from a trusted certifying authority and
that the host name on the certificate is either invalid or does not match the name of the site that sent the certificate.
Either accept the certificate just for this session or save it to the certificate store of your browser.
To eliminate certificate warnings, you can replace the default self-signed certificate with a different certificate that has
the host name of your NIOS appliance. The NIOS appliance supports X.509 certificates in .PEM format. After initial
login, you can do one of the following:
Generate another self-signed certificate with the correct host name and save it to the certificate store of your
browser.
Generate a self-signed certificate, see Generating a Self-Signed Certificate on page 48.
Request a CA-signed certificate with the correct host name and load it on the NIOS appliance.
Use a certificate from a CA by generating a certificate signing request as described in Generating a Certificate
Signing Request on page 49. When you receive the certificate from the CA, import it as described in Importing a
Certificate on page 49.
Additionally, before you log in to the NIOS appliance, you can manage the certificates on the client machine. For
information, see Manage Certificates on page 45
Generating a Self-Signed Certificate
You can replace the default certificate with a self-signed certificate that you generate. When you generate a
self-signed certificate, you can specify the correct host name and change the public/private key size, enter valid
dates and specify additional information specific to the NIOS appliance. If you have multiple appliances, you can
generate a certificate for each appliance with the appropriate host names.
To generate a self-signed certificate:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Members ) -> grid_member -> Tools -> HTTPS
Certificate -> Generate Self-Signed Certificate.
For an independent appliance or HA pair: From the Device perspective, click hostname) -> Tools -> HTTPS
Certificate -> Generate Self-Signed Certificate.
2. In the Create Self-Signed Certificate dialog box, enter the following:
Key Size: Select either 2048 or 1024 for the length of the public key.
*Days Valid: Specify the validity period of the certificate.
*Common Name: Specify the domain name of the NIOS appliance. You can enter a fully qualified domain
name (FQDN).
Organization: Type the name of your company.
Organizational Unit: Type the name of your department.
Locality: Type a location, such as the city or town of your company.
State or Province: Type the state or province.
Country Code: Enter the 2-letter code that identifies the country, such as US.
Administrators E-mail Address: Enter the e-mail address of the appliance administrator.
Comment: Enter additional notes.
An asterisk (*) indicates the field is required.
3. Click OK to close the Create a Self-Signed Certificate dialog box.
4. Click the Save icon.
The NIOS appliance logs you out, or you can log out yourself. When you log in to the appliance again, it uses the
certificate you generated.
Generating a Certificate Signing Request
You can generate a certificate signing request (CSR) that you can use to obtain a signed certificate from your own
trusted CA. Once you receive the signed certificate, you can import it into the NIOS appliance, as described in
Importing a Certificate on page 49.
To generate a CSR:
Certificate -> Generate Signing Request.
or
For an independent appliance or HA pair: From the Device perspective, click hostname) -> Tools -> HTTPS
Certificate -> Generate Signing Request.
2. In the Create Certificate Signing Request dialog box, enter the following:
Key Size: Select either 2048 or 1024 for the length of the public/private key pair.
name (FQDN).
3. Click OK to close the Create Certificate Signing Request dialog box.
4. In the Download filename dialog box, navigate to where you want to download the CSR, enter the file name and
click Save.
Importing a Certificate
You can replace the default server certificate with a signed certificate from your own trusted CA. First, generate a
certificate signing request as described inGenerating a Certificate Signing Request on page 49.
When you import a certificate, the NIOS appliance finds the matching CSR and takes the private key associated with
the CSR and associates it with the newly imported certificate. The appliance then automatically deletes the CSR.
To import a certificate:
Certificate -> Upload Certificate.
or
For an independent appliance or HA pair: From the Device perspective, click hostname -> Tools -> HTTPS
Certificate -> Upload Certificate.
2. Navigate to where the certificate is located and click Open.
The appliance imports the certificate and logs you out. When you log in to the appliance again, it uses the
certificate you imported.
Infoblox GUI
Understanding the GUI Components
You can view data and configuration settings and make configuration changes through the Infoblox GUI using the
following two methods:
Device Manager: When a NIOS appliance functions as an independent appliance, you launch the Device
Manager to access the GUI. The name appears in the title bar of the browser window.
Grid Manager: When the NIOS appliance is in a grid, you log in to the grid master and launch the Grid Manager.
The name appears in the title bar of the browser window.
Main Interface Components
The following figure illustrates the typical layout of the Infoblox GUI. You can detach and move the GUI components
and customize the GUI as necessary.
Figure 2.5 Infoblox GUI Overview
Menu
Each item in the menu is a drop-down list of available options. The menu items change dynamically according to the
perspective you are in.
Tip: Select an item and right-click to quickly access menu options.
Tool Bar
The tool bar contains a Save icon which you click to save your configuration changes, and a Restart Services icon,
which you click to restart services on a appliance or a grid.
Editor
Enter and edit information.
Properties Viewer
View object properties.
Panels
View and select items
to edit.
Perspective
Menu
Detach and move panels,
viewers and editors to
customize the GUI layout.
Tool Bar
Save Restart Services
Perspectives
A perspective is a container for tools used to manage the grid or appliance and its services. The Infoblox GUI
application provides a set of perspectives, each focusing on a specific functional area. You display a perspective by
clicking the appropriate icon on the tool bar:
Device: In this perspective, you configure an independent appliance and set its operational parameters.
Grid: In this perspective, you configure a grid and set operational parameters. A Keystone license is required for
this feature.
DNS: In this perspective, you enable and configure DNS services on the appliance or the grid.
DHCP and IPAM: In this perspective, you enable and configure DHCP service and IP Address Management
features.
Administrators: In this perspective, you configure administrators.
File Distribution: In this perspective, you enable and configure HTTP and TFTP (Trivial File Transfer Protocol)
services.
AAA: In this perspective, you configure RADIUS services to authenticate and authorize users, as well as manage
user accounts, policies, and policy groups.
Global Search: In this perspective, you search the entire database for a specific text string. All database objects
matching the text string are displayed in this perspective.
VitalQIP: This is not a standard part of the Infoblox GUI. In this perspective, you can configure the appliance to
function as a VitalQIP remote server. A VitalQIP license is required for this feature.
Note: The VitalQIP icon only displays when the NSQ software module and required licensing are installed.
Grid or Device
Perspective Icon
DHCP and IPAM
Perspective Icon
File Distribution
Perspective Icon
DNS
Perspective Icon
Authentication, Authorization, and
Accounting Perspective Icon
Administrators
Perspective Icon
Global Search
Perspective Icon
Infoblox GUI
Panel
Panels list objects that you can select and edit. You can expand or collapse lists by selecting the + or - sign beside
an object. Panels can be opened and closed from the View menu on the top menu bar.
Shortcuts
Double-click the tab of a panel to fully expand; double-click the tab again to reset the panel.
Select an object and right-click to display options.
Double-click an item to edit it (open its editor).
Ctrl+click to select multiple items.
Editor
You can enter information and configure objects in an editor. You can open multiple editors at one time. After you
enter information in an editor, you must click the Save icon to save your changes.
Properties Viewer
Viewers display information about a selected object. You cannot edit or select objects in a viewer. However, you can
expand, collapse, detach and move viewers to different locations.
Online Help
The Infoblox appliance ships with online help that you can access from anywhere in the GUI. The Help menu provides
access to the following:
About Infoblox Grid Manager: View information about the NIOS software version running on the appliance.
Download Admin Guide: Download the Infoblox Administrator Guide.
API Documentation: Display the API documentation.
Training: Display information about Infoblox training workshops.
Help Contents: Display the main Help system.
Dynamic Help: Access Help for the active panel, editor, or viewer. A window is active when its title bar is
highlighted.
In addition, to access Help for a dialog box, click the question mark (?) icon in the bottom left corner of the dialog box.
Customizing a Perspective Layout
You can customize the layout of a perspective by detaching and rearranging panels and views. In this way, you can
structure your workspace for optimum efficiency.
To customize a perspective layout:
1. Right-click the tab of the panel or view, and select
Detached from the context menu.
2. Left-click and drag to the desired location.
3. Resize and tile multiple detached panels or views to
create a custom layout.
Infoblox GUI
Creating a Login Banner on a NIOS Appliance
To create a statement that appears on the top of the Login screen (a banner message), follow the procedures in this
section. This function is useful for posting security warnings or user-friendly information well above the user name
and password fields on the Login screen. A login banner message can be up to 3000 characters long. In a grid,
perform this task on the grid master.
To create a login banner:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security.
3. Select Enable Login Banner and enter the text you want displayed in the Banner Text field.
Customizing Columns
The NIOS appliance supports the ability to customize columns displayed in any perspective or panel within the GUI.
(An exception to this is the Properties view panel; the NIOS appliance does not support customizing columns within
the Properties view panel.)
You can move columns around and hide certain columns from view. For example, you might want to view only
columns related to IP addresses without displaying location or appliance information in the DHCP Lease History
panel. Resetting a perspective does not override column settings. The appliance retains changes to the columns even
after you reset a perspective.
Column settings are applied to all administrators and users accessing the appliance. If you customize the columns,
your column settings appear to all other users when they log in to the appliance.
You can customize columns in any of the following ways:
Hide columns so that they are not shown in the display
Show columns so that they are displayed and not hidden
Select the order in which the columns are displayed within a panel
Change the size of the columns. Each column can have maximum pixel size of 999
Customizing Columns within the GUI
To customize columns:
1. From any perspective or panel, click Edit -> Edit Columns.
2. When the Edit Column dialog box appears, you can set the following options:
SIze: Specify the column width, in pixels. You can specify any number from 1 through 999.
Auto Fit: Resize the column width to accommodate the largest string in the column. Select the Auto Fit
check box to enable this option. Keep in mind that enabling this option resizes for the current values within
the column. This option does not resize for future values.
Restore Default: Click Restore Default to restore back to the default column display.
To hide and display columns, and change their order:
Display column: Select the check box of each attribute or column you want to display. Click the Select
All button to automatically select all columns available within the list.
Hide column: Deselect the check box of each attribute or column you want to hide. Click the Deselect
All button to automatically deselect all columns within the list, hiding all items.
Ordering columns: Select a column from the list and click Up to move that column to the left in the
display. Click Down to move that column to the right in the display.
3. Click OK.
You can also change the order of the columns in a panel by dragging-and-dropping a column.
The leftmost column within the tree panel has some special restrictions. You cannot move the leftmost column.
However, you can move the column next to the leftmost column over as the first column. Take note that when you do
this, the icons you use to expand and collapse items remains in the same location in the panel (the left side of the
panel).
To edit columns using the drag-and-drop method:
1. From any perspective or panel, select any column heading title.
2. Drag and then drop the column to move the column around.
Using Global Search
This function allows you to search through the entire NIOS appliance database for any instances matching a specific
text string. The global search option allows you to search across different perspectives and views, instead of
searching under each perspective or view individually. For example, you can search for a specific host name across
both the DNS perspective and DHCP perspective with a single global search, or you can search for all occurrences of
a specific MAC address within the database.
The Global Search perspective is located next to the other perspectives in the GUI toolbar. The Global Search
perspective opens up a panel called Search Results and displays all matches within the panel. All match results are
displayed with the following information:
Name: Name of the matching object.
Type: Object type matching the global search. For example, the Type field identifies the type of record or type of
address of the matching object.
Matched Attribute: Attribute of the matching object. For example, if the global search matched the address
corresponding to a hostname, then field displays the address of the hostname.
Matched Value: The value of the matching object. For example, if the global search matched the address of a
hostname, then the field displays the hostname.
Note: NIOS displays search results based upon the page size setting from the administrator settings. For
information about page size configuration, see Authenticating Administrators on page 101.
To search globally:
1. From the Global Search perspective, type the text string to search on the appliance database.
2. Click Search.
NIOS supports regular expressions for global search. Regular expressions, commonly known as regex, are a set of key
combinations that are meant to allow the user to have a variety of control over what they are searching for.
Note: You cannot search zones based on the zone type. You can filter search results based on the zone type.
From the Search Results panel, you can do the following:
Open a panel to view the properties of a matching object.
Open a panel to edit the properties of a matching object.
Remove a matching object from the database.
Define the administrative permissions of an object, as described in Defining Permissions for an Object on page
56.
You can perform these operations by clicking matching object -> Edit.
Infoblox GUI
Defining Permissions for an Object
You can select an object in the Search Results panel and define its administrative permissions as follows:
1. Select an object from the list and click Edit -> Manage Permissions.
2. In the Manage Resource Permissions dialog box, complete the following:
Admin Group: Click Add, and select an admin group in the Select Admin Group dialog box. After you click OK to
close the dialog box, the appliance lists the admin group you selected.
Permissions: The appliance displays the name of the object in the Resource column. Select the permission for
the object by clicking Read/Write, Read Only or Deny.
3. Click OK to close the Manage Resource Permissions dialog box.
For information on setting administrative permissions, see Defining Permissions on page 77.
Printing from the GUI
NIOS appliance supports the ability to print the contents of the GUI from any perspective. Printing from the GUI allows
you to print the contents of a view within any perspective shown on the display. All page modifications that are
applied to the display contents, such as filters and sorting, affect the print output as well.
You can print to the following outputs:
Hard copy to the printer, or conversion to a PDF (Portable Document Format) file (see Print Hard Copy or PDF File
on page 56
Text file (see Print Output to a Text File on page 57)
CSV file (MS WIndows only with this feature installed) (see Exporting Data on page 60)
The amount of content printed depends on the page size configuration set by the administrator. For information on
configuring the page size, see Authenticating Administrators on page 101.
Note: GUI printing is supported on the Microsoft Windows operating system only.
Print Hard Copy or PDF File
To print a hard copy or PDF file from the GUI:
1. From any perspective, click File -> Print. The Print dialog box appears.
2. Set the print options you want for the print job. You can set the following print options:
Selected printer
Print preferences: portrait or landscape page orientation, legal or letter page size, and page margins.
Print to file (for PDF generation)
Page range
Number of copies
3. Click Print.
Printing from the GUI
Print Output to a Text File
To print to a text file in the Windows operating system:
1. Install a new generic printer to Windows called GenericText.
2. From any perspective, click File -> Print. The print dialog box appears.
3. Set the print options you want for the print job. You can set the following print options:
Select the new GenericText printer.
Print preferences: portrait or landscape page orientation, legal or letter page size, and page margins.
Page range.
Number of copies.
4. Click Print.
Infoblox GUI
Multilingual Support
NIOS appliances support languages other than English in certain input fields. When you enter information in these
fields using non-English languages, the NIOS appliance uses UTF-8 (Unicode Transformation Format-8) encoding to
interpret the data. For information about which fields support UTF-8 encoding, see UTF-8 Supported Fields on page
58.
UTF-8 is a variable-length character encoding for Unicode characters. Unicode is a code table that lists the numerous
scripts used by all possible characters in all possible languages. It also has a large number of technical symbols and
special characters used in publishing. UTF-8 encodes each Unicode character as a variable number of one to four
octets (8-bit bytes), where the number of octets depends on the integer value assigned to the Unicode character. For
information about UTF-8 encoding, refer to RFC 3629 and the ISO/IEC 10646-1:2000 Annex D. For information about
Unicode, refer to The Unicode Standard.
Depending on the OS (operating system) that your management system uses, you must install the appropriate
language files in order to enter information in a specific language. For information about how to install language files,
refer to the documentation that comes with your management system.
UTF-8 Supported Fields
The NIOS appliance supports UTF-8 encoding in all of the comment fields and most input fields. You can enter
non-English characters in these data fields through the Infoblox GUI and the Infoblox API. When you use the Infoblox
API, all the non-ASCII strings must be UTF-8 encoded so that you can use Unicode characters. The NIOS appliance
does not support UTF-8 encoding for data that is configurable through the Infoblox CLI commands.
In general, the following items support UTF-8 encoding:
In the NAC Foundation module, the following fields that you use to customize the captive portal, self service
portal, and DHCP guest registration page:
Company Name
Welcome Message
Help Desk Message
All comment and custom fields
Acceptable Use Policy files
The following IPAM fields that you use to classify devices:
Location
Owner
Manufacturer
Model
All custom fields
All the comment fields in all of the Infoblox GUI perspectives.
File name fields for FTP and TFTP backup and restore operations.
The login banner text field. When you use the serial console or SSH, the appliance cannot correctly display the
UTF-8 encoded information that you enter for the login banner.
Note: For data fields that do not support UTF-8 encoding, the appliance displays an error message when you use
non-English languages.
UTF-8 Support Limitations
The NIOS appliance has the following UTF-8 support limitations:
Object names that have data restrictions due to their usage outside of the Infoblox database do not support
UTF-8 encoding. For example, IP addresses, DNS names, or Active Directory domain names.
Multilingual Support
When importing a database, most of the ASCII control characters cannot be encoded. This might cause failures
in upgrades or database restore operations.
Search is based on Unicode standard. Depending on the language, you might not be able to perform a
case-sensitive search.
Binary data is encoded as text.
Hard-coded data in the DHCP authentication configuration remains in English. For example, the text on buttons
such as Accept, Continue, or Register, as well as HTML pages such as the complete.html file that tells you your
password has been successfully changed.
UTF-8 encoding does not fully support regular expressions. It matches constant strings. However, It does not
encode characters that are inside square brackets or followed by regular expressions such as *, ?, or +.
You can use UTF-8 characters to authenticate both the User Name and Password through the Infoblox GUI, but
not through the Infoblox CLI.
Infoblox CLI does not not support UTF-8 encoding.
International Characters Support for RADIUS Authentication
For RADIUS authentication, the NIOS appliance supports single-byte international character sets in the following:
Windows XP and Vista OS.
RADIUS and LDAP user names, passwords, and comments.
Replicated AD user names, passwords, and groups in all of the NIOS interfaces, except the Data Import Wizard.
Proxy requests if the RADIUS server that is proxied supports them.
You can configure the NIOS appliance to be a RADIUS server for RADIUS authentication. If you want the RADIUS
server to support wireless supplicants on a Windows client that does not use a Latin 1 (1252) codepage, you must
change the default codepage on the NIOS appliance to match the clients set up. The NIOS appliance uses the code-
page to translate single-byte characters into UTF-8 encoded characters. For information about how to configure the
codepage for RADIUS authentication, see RADIUS Authentication on page 633.
The NIOS appliance supports the following codepages:
UTF-8
Arabic (1256)
Baltic (1257)
Central/Eastern European (1250)
Cyrillic (1251)
Greek (1253)
Hebrew (1255)
Latin-1 (1252)
Turkish (1254)
Note: The default is Latin-1 (1252). This codepage is usually correct for most English based Windows environments.
Infoblox GUI
Exporting Data
You can export certain types of data from the NIOS appliance to a CSV (Comma Separated Values) file and store it in
a directory on your management station. You can then use a text editor or an application, such as Microsoft Excel, to
view the data in the CSV file.
The default name of the CSV file reflects the type of data being exported. For example, an export of grid members data
has the file name Grid.csv. You can change the file name, for example, by appending a date as in Grid022908, to
maintain multiple copies of the exported files.
Exporting Data from Panels
You can export data from most panels in the Infoblox Grid or Device Manager. When you export data from panels with
multiple columns, such as the Detailed Status panel in the Grid perspective and the Records panel in the DNS
perspective, the exported data reflects what is displayed in the GUI. You can move, hide, and sort columns as
described in Customizing Columns on page 54, to organize the data before you export it to a CSV file. Note that you
cannot export data from a panel when all its columns are hidden.
The following is a list of panels from which you can export data. The exported CSV files contain exactly what is
displayed in the panels, except for the files exported from the Grid, Infoblox Views, Networks, and Directories panel.
Grid Perspective
You can export a list of grid members from the Grid panel. You can export the data that is displayed in the following
panels:
Detailed Status
Recycle Bin
DNS Perspective
You can export a list of views and their zones from the Infoblox Views panel. You can export the data that is displayed
in the following panels:
Records
Shared Record Group Associations
Zone Statistics
Exporting Data
DHCP and IPAM Perspective
You can export a list of networks from the Networks panel. You can export the data that is displayed in the following
panels:
Ranges, Fixed Addresses and Filters
Ranges and Fixed Address Templates
IP Address Management
DHCP Leases
DHCP Lease History
Network Statistic
DHCP Statistics
DHCP Failover Status
AAA Perspective
You can export data from the User Accounts panel.
File Distribution Perspective
You can export a list of directories from the Directories panel and the data that is displayed in the Files panel.
Global Search Perspective
You can export data from any search panel that is associated with any of the perspectives and windows that you can
export.
Exporting Hierarchical Data
By default, the Records panel lists DNS records individually by record name, in alphabetical order, as shown in the
following figure:
Figure 2.6 Resource Records List
When you export records from the Records panel and the records are individually listed, then the exported CSV file
lists all records displayed in the panel, as shown in the following figure:
Figure 2.7
Infoblox GUI
Alternatively, you can click the icon to display records hierarchically, as shown in the following figure:
Figure 2.8 Hierarchical View
When you export data from the Records panel and the records are listed hierarchically, then the CSV file lists only the
parent records that are displayed in the Records panel, as shown in the following figure:
Figure 2.9 Hierarchical Export
Exporting Data to a CSV File
To export data to a CSV file:
1. From a panel that supports CSV file export, do one of the following:
Right-click anywhere on the panel and select Export from the context menu.
Select File -> Export.
2. In the save as dialog box, do the following:
Select the destination directory for the file.
Either use the default name or type a new name for the file. The .csv file extension is automatically applied
to the filename.
A CSV Export Status dialog box displays the status of the export.
Exporting Large Files
If you are exporting a file with more than 500 objects, the NIOS appliance displays a dialog box with a progress bar
indicating the status of the export process. You can click one of the following:
Run in Background to run the export in background mode, allowing you to complete other tasks in NIOS while
the export is running
Cancel to cancel the export
Details to view details about the export
If you select Run In Background, the appliance displays the status of the export at the bottom of the window, as
shown in the following figure:
Figure 2.10 CSV Export Status
Click to view background
tasks in the Progress panel.
Exporting Data
You can view background tasks by clicking the icon shown in Figure 2.10. The Progress panel displays the
status of all the current long-running tasks. You can cancel a task by clicking the icon beside the progress bar,
as shown in Figure 2.11.
Figure 2.11 CSV Export Progress Panel
Note: If you anticipate exporting large amounts of data, consider increasing the size of your java heap.
Click to cancel
the task.
Infoblox GUI

Chapter 3 Managing Administrators
This chapter describes the various tasks associated with setting up admin groups and accounts. It contains the
following sections:
About Admin Accounts on page 67
About Admin Groups on page 69
Creating a Superuser Admin Group on page 69
About Limited-Access Admin Groups on page 70
About Admin Roles on page 71
Creating Limited-Access Admin Groups on page 72
Deleting Admin Roles and Groups on page 73
Viewing Admin Group Assignments on page 73
About Administrative Permissions on page 74
Applying Permissions and Managing Conflicts on page 75
Defining Permissions on page 77
Viewing and Managing Permissions on page 80
Modifying Permissions on page 81
Removing Permissions on page 81
Administrative Permissions for Grid Members on page 82
Managing DNS Resource Permissions on page 83
Administrative Permissions for Views on page 84
Administrative Permissions for Zones on page 85
Administrative Permissions for Resource Records on page 87
Administrative Permissions for Shared Record Groups on page 88
Managing Administrative Permissions for DHCP Resources on page 90
Administrative Permissions for Networks and Shared Networks on page 91
Administrative Permissions for Fixed Addresses on page 93
Administrative Permissions for DHCP Ranges on page 94
Administrative Permissions for DHCP Templates on page 95
Administrative Permissions for MAC Address Filters on page 96
Administrative Permissions for Network Discovery on page 96
Administrative Permissions for the DHCP Lease History on page 97
Administrative Permissions for the RADIUS Service on page 98
Managing Administrators
Administrative Permissions for File Distribution Services on page 100
Authenticating Administrators on page 101
Creating Local Admins on page 101
Modifying and Removing an Admin Account on page 102
About Remote Admins on page 102
Authenticating Using RADIUS on page 104
Remote RADIUS Authentication on page 105
Configuring RADIUS Authentication on the NIOS Appliance on page 105
Adding RADIUS Servers on page 106
Testing the RADIUS Server on page 107
Maintaining the RADIUS Admins Server List on the NIOS Appliance on page 107
Disabling a RADIUS Server on page 107
Configuring a RADIUS Server on page 108
Configuring Admin Groups on the Remote RADIUS Server on page 108
Configuring Remote Admin Accounts on the Remote RADIUS Server on page 108
Authorization Groups Using RADIUS on page 109
Accounting Activities Using RADIUS on page 109
Authenticating Admin Accounts Using Active Directory on page 110
Admin Authentication Using Active Directory on page 111
Configuring Active Directory Authentication for Admins on page 111
Defining the Admin Policy on page 112
Specifying a List of Remote Admin Groups on page 112
Configuring the Default Admin Group on page 112
Configuring a List of Authentication Methods on page 113
Changing Password Length Requirements on page 113
Notifying Administrators on page 113
About Admin Accounts
About Admin Accounts
When an admin connects to the NIOS appliance and logs in with a user name and password, the appliance starts a
2-step process that includes both authentication and authorization. First, the appliance tries to authenticate the
admin using the user name and password that were entered. Second, it determines the authorized privileges of the
admin by identifying the group to which the admin belongs. It grants access to the admin only when it successfully
completes this process.
Infoblox uses the concept of administrator groups to which you add one or more individual administrators. The
administrators inherit the permissions and properties of the group to which they belong.
The NIOS appliance can authenticate users that are stored on its local database as well as users stored remotely on
an Active Directory domain controller and a RADIUS server. Regardless of the location of an admin account, all
administrators must belong to an admin group. In addition, the group from which the admin receives privileges and
properties is stored locally.
The tasks involved in storing administrator accounts locally and remotely are listed in Table 3.1.
Table 3.1 Storing Admin Accounts Locally and Remotely
The admin policy defines how the appliance authenticates the admin: with the local database, RADIUS, or
Active Directory. You must add RADIUS or Active Directory as one of the authentication methods in the
admin policy to enable that authentication method for admins. See Configuring a List of Authentication
Methods on page 113for more information about configuring the admin policy.
NIOS appliance RADIUS server or AD Domain Controller
To store admin
accounts locally
Use the default admin group
(admin-group) or define a new group
Set the privileges and properties for
the group
Add admin accounts to the group
To store admin
accounts remotely
Configure communication settings with
a RADIUS server or an Active Directory
domain controller
If you use admin groups on the RADIUS
server or Active Directory domain controller:
Use an existing admin group or define
a new one
Set the privileges and properties for
the group
If you do not use admin groups on the
RADIUS server:
Assign an admin group as the default
Configure communication settings with
the NIOS appliance
If you use admin groups:
Import Infoblox VSAs (vendor-specific
attributes) (if RADIUS)
Define an admin group with the same
name as that on the NIOS appliance
Define admin accounts and link them
to an admin group
If you do not use admin groups:
Define admin accounts
Figure 3.1 illustrates the relationship of local and remote admin accounts, admin policy, admin groups, and
permissions and properties.
Figure 3.1 Privileges and Properties Applied to Local and Remote Admin Accounts
Complete the following tasks to create admin accounts:
1. Use the default admin groups or create admin groups. See About Admin Groups on page 69.
2. Define the administrative permissions of each admin group. See About Administrative Permissions on page 74.
3. Create admin accounts and assign them to the appropriate admin group.
To add accounts to the local database, see Creating Local Admins on page 101.
To configure the appliance to authenticate admin accounts stored remotely, see About Remote Admins on
page 102.
Admin
Users
NIOS appliance RADIUS or Active Directory
When remote admin
accounts are not in
an admin group (or in a
group whose name does
not match that of a local
group), the NIOS
appliance applies the
default admin group
permissions and
properties (if configured).
The NIOS appliance first
checks the remote admin
policy to determine which
of the following
authentication methods to
use and where to get
membership information
from: local-admin
database, RADIUS, or
Active Directory.
Local
Admin
Groups
Remote
Admin
Groups
Adam
Balu
Eve Dan
Christine
Access permissions and properties come
from local admin group definitions.
When admin
accounts are in
an admin group
that matches a
group configured
locally, the
appliance selects
the first group
(based on remote
admin policy) and
applies the
permissions and
properties to the
admin belonging
to that group.
Login
Login
Login
Login
Login
Admin-Group1
Admin-Group2
Admin-Group3
Default
Admin-Group
Admin-Group2
Admin-Group3
=Admin Account
Note:
There can be admin
accounts in a local and
remote admin group with
the same group name.
Group
names
must
match.
Assigned from local admin group definitions:
Admin Permissions
(for resources, such as zones, networks,
members and DHCP lease history)
Properties
(for page and tree sizes)
About Admin Groups
About Admin Groups
All administrators must belong to an admin group. The permissions and properties that you set for a group apply to
the administrators that you assign to that group.
There are three types of admin groups:
Superuser Superuser admin groups provide their members with unlimited access and control of all the
operations that a NIOS appliance performs. There is a default superuser admin group, called admin-group, with
one superuser administrator, admin. You can add users to this default admin group and create additional admin
groups with superuser privileges. Superusers can access the appliance through its console, GUI, and API. In
addition, only superusers can create admin groups.
Limited-Access Limited-access admin groups provide their members with read-only or read/write access to
specific resources. These admin groups can access the appliance through the GUI, API, or both. They cannot
access the appliance through the console.
ALL USERS The ALL USERS group is a default group in which you define global permissions for all
limited-access users. This group implicitly includes all limited-access users configured on the appliance.
Creating a Superuser Admin Group
Superusers have unlimited access to the NIOS appliance. They can perform all the operations that the appliance
provides. There are some operations, such as creating admin groups and accounts, that only superusers can perform.
Note that there must always be one superuser admin account stored in the local database to ensure that at least one
administrator can log in to the appliance in case the NIOS appliance loses connectivity to the remote admin
databases such as RADIUS servers or AD domain controllers.
There is a default superuser admin group (admin-group). You can create additional superuser admin groups, as
follows:
1. Log in as a superuser.
2. From the Administrators perspective, click Groups -> Edit -> Add Group.
3. In the Add Administrator Group editor, enter the following:
Group Name: Enter the name for the admin group.
Comment: Enter pertinent information about the group, such as location or department. The data entered
here displays in the Comment column when you select the admin group name in the tree view.
Superuser: Select this check box to grant the admin accounts that you assign to this group full authority to
view and configure all types of data.
Page Size: Enter a value for the number of lines of data that you want a single GUI list view to contain for
administrators that belong to this group. When there is a lot of data, you can improve the display
performance by setting a smaller page size, such as 100 instead of 1000. You can set the page size from 10
to 2000. The default page size is 100.
Disable this admin group: Select this check box to retain an inactivated profile for this admin group in the
configuration. For example, you might want to define a profile for recently hired administrators who have
not yet started work. Then when they do start, you simply need to clear this check box to activate the
profile.
You can do one of the following:
Add local admins to the superuser group; see Creating Local Admins on page 101.
Assign the superuser group to remote admins; see About Remote Admins on page 102.
About Limited-Access Admin Groups
All admin groups, except superuser admin groups, require either read-only or read-write permission to access certain
resources, such as grid members, and DNS and DHCP resources. Therefore, when you create an admin group, you
must specify which resources the group is authorized to access and their level of access.
There are two ways to define the permissions of an admin group. You can create the group and assign permissions
directly to the group. In addition, you can create roles that contain permissions and assign the roles to the admin
group.
Only superusers can create admin groups and define their administrative permissions. Complete these tasks to
configure an admin group:
1. If you want to use admin roles to assign permissions to admin groups, create the admin roles as described in
About Admin Roles on page 71.
2. Define the permissions of the newly created admin roles, as described in Defining Permissions on page 77.
3. Create the admin group, as described in Creating Limited-Access Admin Groups on page 72.
4. Define the administrative permissions of the admin group.
Assign roles to the admin group, as described in Creating Admin Roles on page 71.
Assign specific permissions as described in Defining Permissions on page 77.
5. Assign admins to the group.
For local admin groups, see Creating Local Admins on page 101.
For remote admins, see About Remote Admins on page 102.
About Admin Roles
A role is a group of permissions that you can apply to one or more admin groups. Roles allow you to quickly and easily
apply a suite of permissions to an admin group. You can define roles once and apply them to multiple admin groups.
The appliance contains the following system-defined admin roles:
AAA Admin: Provides read-write access to all grid AAA properties.
DHCP Admin: Provides read-write access to all DHCP MAC filters, members, networks, and shared networks, and
read-only access to the DHCP templates and DHCP lease history.
DNS Admin: Provides read-write access to all members, all shared record groups, and all Infoblox views.
File Distribution Admin: Provides read-write access to all grid file distribution properties.
Grid Admin: Provides read-write access to all DHCP MAC filters, DHCP templates, members, networks, shared
networks, DHCP lease history, all shared record groups, all Infoblox views, Grid AAA properties, Grid File
distribution properties.
You can assign these system-defined roles to admin groups and create additional roles based on the job functions in
your organization. If you are creating a role that has similar permissions to an existing role, you can copy the role and
then make the necessary modifications to the new role. Thus you do not have to create each new role from scratch.
You can assign up to 20 roles to an admin group, and you can assign a role to more than one admin group. When you
make a change to a role, the appliance automatically applies the change to that role in all admin groups to which the
role is assigned.
Creating Admin Roles
There are two ways to create an admin role. You can create a new role and define its permissions, and you can copy
an existing role. To create a new role from scratch:
1. From the Administrators perspective, click Roles -> Edit -> Add Role to display the Add Role editor.
2. Complete the following:
Role Name: Enter a name for the role.
Comment: Optionally, enter information about the role.
To copy an existing role:
1. From the Administrators perspective, click Roles -> admin_role -> Edit -> Copy Role As.
2. In the Copy Role As dialog box, enter the name of the new role you are creating. You can also enter information
about the new role in the Comment field. Click OK to close the dialog box.
The appliance displays the new role and its permissions.
After you create roles, you can do the following:
Define their permissions. For information and guidelines on defining permissions, see About Administrative
Permissions on page 74.
Assign roles to admin groups, as described in Creating Limited-Access Admin Groups on page 72.
Creating Limited-Access Admin Groups
When you create a limited-access admin group, you can assign roles to it. The group then inherits the permissions of
its assigned roles. In addition, you can assign permissions directly to the group, as described in Defining Permissions
on page 77. Only superusers can create admin groups.
To create an admin group:
1. From the Administrators perspective, click Groups -> Edit -> Add Group to display the Add Administrator Group
editor.
2. Expand the Group Properties section and enter the following:
Group Name: Enter the name for the admin group.
Comment: Enter pertinent information about the group, such as location or department. The data entered
here displays in the Comment column when you select the admin group name in the tree view.
Superuser: Clear this check box to create a limited-access admin group.
administrators that belong to this group. When there is a lot of data, you can improve the display
performance by setting a smaller page size, such as 100 instead of 1000. You can set the page size from 10
to 2000. The default page size is 100.
Access Method: Specify whether the admin group can use the GUI and the API (application programming
interface) to configure the appliance.
Access through GUI: Select this check box to allow the admin group to use the GUI.
Access through API: Select this check box to allow the admin group to use the API. For information
about the API, see Chapter 24, Infoblox DMAPI, on page 665.
Disable this admin group: Select this check box to retain an inactivated profile for this admin group in the
configuration. For example, you might want to define a profile for recently hired administrators who have
not yet started work. Then when they do start, you simply clear this check box to activate the profile.
3. Optionally, expand the Roles section and complete the following:
Click Add.
In the Select Role dialog box, select the roles you want to assign to the admin group, and then click OK.
You can assign up to 20 roles to an admin group. The appliance displays the selected roles in the list
box.
When an admin group is assigned multiple roles, the appliance applies the permissions to the group in
the order the roles are listed. Therefore if there are conflicts in the permissions among the roles, the
appliance uses the permission from the role that is listed first and ignores all the others. You can reorder
the list by selecting a role and clicking Move Up or Move Down. To delete a role, select it and click Delete.
After you select roles, you can click Check for conflicts to check for any conflicting permissions. For
information about checking conflicts, see Applying Permissions and Managing Conflicts on page 75.
Click Cancel to close the dialog box.
Deleting Admin Roles and Groups
You can remove both system-defined and user-defined admin roles and admin groups. To delete an admin group or
role:
1. Do one of the following from the Administrator perspective:
To remove an admin role, click + (for Roles) -> admin_role.
To remove an admin group, click + (for Groups) -> admin_group.
2. Click Edit -> Remove.
Viewing Admin Group Assignments
You can view to which admin groups a role is assigned by selecting the role and clicking View -> Admin Role
Assignments.
About Administrative Permissions
You can assign permissions to admin roles which you then assign to admin groups, or you can assign permissions
directly to an admin group. The following are permissions you can grant roles and admin groups:
Deny: Prevents admins from viewing, adding, modifying and deleting the resource. This is the default
permission level.
Read-Only: Allows admins to view and search for the resource. Admins cannot add, modify or delete the
resource.
Read/Write: Allows admins to view, search for, add, modify, and delete the resource.
By default, the appliance denies access to certain resources. Admin groups must have either read-only or read/write
permission to access the following resources:
Grid membersSee Administrative Permissions for Grid Members on page 82
DNS resourcesSee Managing DNS Resource Permissions on page 83.
DHCP resourcesSeeManaging Administrative Permissions for DHCP Resources on page 90.
RADIUS resourcesSee Administrative Permissions for the RADIUS Service on page 98.
File distribution resourcesSee Administrative Permissions for File Distribution Services on page 100.
You can define permissions at a global level, for example, for all Infoblox views or all DHCP networks in the database,
and at a more granular level, such as a specific zone, network, and even an individual database object, such as a
resource record or fixed address.
The appliance applies permissions hierarchically in a parent-child structure. When you define a permission to a
resource, the permission applies to all the other resources and objects contained within that resource. For example,
if you grant an admin group read-write permission to a grid, it automatically has read-write permission to all members
in the grid. However, you can override the grid-level permission by setting a different permission, read-only or deny,
for a grid member. Permissions at more specific levels override those set at a higher level.
When admins have permission to objects that are in a parent object, but are not given rights to the parent object, the
appliance displays the parent object in the tree view, for navigational purposes only. For example, as shown in
Figure 3.2, admins do not have permission to the Internal view and to corp.com, but have permission to the child zone
called sales.corp.com. In this case, the admins can see the Internal view and corp.com in the tree view, but cannot
see their contents. The admins can see the contents of sales.corp.com zone only.
Figure 3.2 Navigating to Objects
Admins in DNS Admins3 can
navigate to sales.corp.com
and create resource records,
even if they have no
permission to the Internal view
and corp.com.
Applying Permissions and Managing Conflicts
When an admin tries to access an object, the appliance checks the permissions of the group to which the admin
belongs. Because permissions at more specific levels override those set at a higher level, the appliance checks object
permissions hierarchicallyfrom the most to the least specific. In addition, if the admin group has permissions
assigned directly to it and permissions inherited from its assigned roles, the appliance checks the permissions in the
following order:
1. Permissions assigned directly to the admin group
2. Permissions inherited from admin roles in the order they are listed in the Roles section of the Administrator
Group editor.
3. Permissions defined for the All Users group.
For example, an admin from the DNS1 admin group tries to access the a1.test.com A record in the test.com zone in
the Infoblox default view. The appliance first checks if the DNS1 admin group has a permission defined for the
a1.test.com A record. If there is none, then the appliance checks the roles assigned to DNS1, and then the All Users
group. If there is no permission defined for the a1.test.com A record, the appliance continues checking for
permissions in the order listed in Table 3.2. The appliance uses the first permission it finds.
Table 3.2 Permission Checking
An admin group that is assigned multiple roles and permissions can have conflicts among the different permissions.
As stated earlier, the appliance uses the first permission it finds and ignores the others. For example, as shown in
Table 3.3, if an admin group has read/write permission to all A records in the test.com zone and a role assigned to it
is denied permission to test.com, the appliance provides read/write access to A records in the test.com zone, but
denies access to the test.com zone and all its other resource records.
Table 3.3 Directly-Assigned Permissions and Roles
The appliance checks object permissions from
the most to the least specific, as listed.
For each object, the appliance checks permissions
in the order listed.
1. a1.test.com A record
2. A records in test.com
3. test.com
4. All zones in the default view
5. Default view
6. All A records
7. All zones
8. All Infoblox views
a. DNS1 admin group
b. Role 1, Role, 2, Role 3
c. All Users group
Permission assigned to the admin group Read/Write to all A records in the test.com
zone
Permission inherited from an admin role Deny to the test.com zone
Effective permissions Deny to the test.com zone
Read/Write to all A records in test.com
Deny to all other resource records in test.com
If the group has multiple roles, the appliance applies the permissions in the order the roles are listed. If there are
conflicts in the permissions among the roles, the appliance uses the permission from the role that is listed first. For
example, as shown in Table 3.4, the first role assigned to the admin group has read-only permission to all A records
in the test.com zone and the second role has read/write permission to the same records. The appliance applies the
permission from the first admin role.
Table 3.4 Multiple Roles
You can check for conflicting permissions when you add permissions to roles and to admin groups, and when you
assign roles to an admin group. When you use the Check for conflicts function, the appliance lists which permissions
are in conflict and indicates which ones it uses and ignores, as shown in Figure 3.3. If you want to change the
permission the appliance uses, you must change the order in which the roles are listed or change the permissions
that are directly assigned to the admin group.
Figure 3.3 Checking for Conflicts
Role 1 permission Read-only to all A records in the test.com zone
Role 2 permission Read/Write to all A records in test.com
Read/Write to all MX records in test.com
Effective permissions Deny to the test.com zone
Read-only to all A records in the test.com zone
Read/Write to all MX records in test.com
Defining Permissions
From the Administrators perspective, you can add permissions to roles and admin groups. You can define global
permissions to resources as well as permissions to specific objects. Note that you can define global permissions from
the Administrators perspective only.
There are two ways to add permissions to specific objects. You can add permissions to specific objects from the
Administrators perspective, as described in the following procedure, as well as from the object itself.
To add permissions to a role or an admin group from the Administrators perspective:
1. Do one of the following from the Administrators perspective:
To define the permissions of an admin role, click + (for Roles) -> + admin_role -> Edit -> Add Permissions.
To define the permissions of an admin group, click + (for Groups) -> admin_group -> Edit -> Add Permissions.
The Add Permissions dialog box appears. Note that it does not list the existing permissions of the role or admin
group. (To view existing permissions, see Viewing and Managing Permissions on page 80.) If you try to add
permission for an object that has an existing permission, the appliance displays an error message.
2. To define global permissions, click Add in the Add Global Permissions tab, as shown in Figure 3.4.
Figure 3.4 Global Permissions Tab
The dialog box displays the default resource, All Members. Do one of the following:
Select Read/Write, Read Only, or Deny for the All Members resource.
or
Click the arrow for Resource to expand the resource list and select the resource for which you are setting the
global permission. Then, select Read/Write, Read Only, or Deny.
You can click Add again to define additional global permissions.
Click Add in the
Global
Permissions tab
to define global
permissions for
an admin group.
3. To define permissions for specific resources and objects, do the following in the Add Object Permissions tab.
Figure 3.5 Add Object Permissions Tab
a. Click Find Object....
b. In the Select Object dialog box, identify the object for which you want to add permission, as follows:
c. In the Text field, enter the name of the object. This field is not case-sensitive.
d. By default, the appliance searches all object types. To narrow down the search, select the type of the object
for which you are searching in the Type drop-down list.
e. Click Search.
The appliance lists the objects it found in the Search Results panel.
f. Select the object for which you are defining permissions and click OK.
The appliance displays the object you selected in the Object field of the Add Object Permissions dialog box.
4. Click Add.
Click the arrow to expand the resource list. The appliance displays the resources associated with the object. You
can set permissions for that object and for its related resources as well.
5. Select the resource for which you are defining permission.
6. Select the appropriate permission: Read/Write, Read Only, or Deny.
7. Optionally, you can check whether the permission you defined conflicts with another permission. Click Check
Conflicts and the appliance displays conflicting permissions in the Permissions Conflict dialog box. For
information, see Applying Permissions and Managing Conflicts on page 75.
If you are setting permission for the selected object only, click OK to close the dialog box.
If you are setting permissions for additional objects, click Apply.
The appliance stores the permission you defined and clears the dialog box, so you can define permission
for another object. Click Add to continue defining permissions for other resources. Click OK when you are
finished.
Click Find
Object in the
Add Object
Permissions tab
to retrieve an
object and
define its
permission.
In addition, you can also set permissions for specific objects from the object itself. For example, to define
permissions for a particular grid member, navigate to that grid member and define its permissions.
To define the permission of a specific object:
1. Navigate to the object. For example, to define permissions for a particular grid member, do the following from the
Grid perspective, click + (for grid) -> + (for Members) -> member.
2. Select the object and do one of the following:
Right-click and select Manage Permissions from the context menu.
Click Edit-> Manage Permissions.
The appliance displays the Manage Resource Permissions dialog box. For example, Figure 3.6 shows the
Manage Resource Permissions dialog box where you define permissions for the selected grid member.
Figure 3.6 Manage Permissions for a Grid Member
3. In the Manage Resource Permissions dialog box, do the following:
Admin Group/Role: Click Add, and then select a role or an admin group in the Select Admin Group or Role dialog
box. After you click OK to close the dialog box, the appliance lists the role or admin group you selected.
Permissions: Click Add. After the appliance displays the object in the Resource column, select Read/Write, Read
Only or Deny.
4. Optionally, you can check whether the permission you defined conflicts with another permission. Click Check
Conflicts and the appliance displays conflicting permissions in the Permissions Conflict dialog box. For
information, see Applying Permissions and Managing Conflicts on page 75
5. Click OK to close the Manage Resource Permissions dialog box.
Viewing and Managing Permissions
Superusers can view the permissions of all admin groups. All other admins can view the permissions of their own
admin group. To view the permissions of a role or an admin group, do one of the following:
To view the permissions of an admin group, from the Administrators perspective, click + (for Groups) -> + (for
admin_group) -> + (for Permissions).
To view the permissions of a role, from the Administrators perspective, click + (for Roles) -> + (for admin_role).
The appliance lists the permission types of the selected role or group, which can be:
AAA Permissions
DHCP Permissions
DNS Permissions
File Distribution Permissions
Grid Permissions
You can select a permission type and view its corresponding permissions in the Permissions panel. By default, the
appliance displays the permissions in alphabetical order. You can display a hierarchical list by clicking the
icon.
Filtering the List of Permissions
You can filter the permissions you view by selecting one of the following:
Effective Permissions: Select to view only the permissions that the appliance is using for this group. The
permissions that were ignored due to conflicts are not listed in this view.
Direct Permissions: Select to view only the permissions that were specifically assigned to the group.
Permissions that were inherited from roles are not listed in this view.
Conflicting Permissions: Select to view only the permissions that are in conflict.
All Permissions: Select to view all permissions.
Modifying Permissions
You can modify the permissions of user-defined admin roles and admin groups. You cannot modify the permissions
of system-defined admin roles. When you change the permissions of a role that has been assigned to multiple admin
groups, the appliance automatically applies the change to the role in all admin groups to which it is assigned. To
change the existing permissions of a role or an admin group:
To modify the permissions of an admin role, click + (for Roles) -> + (for admin_role).
To modify the permissions of an admin group, click + (for Groups) -> + (for admin_group) -> + (for
Permissions).
2. Select the permission type and in the Permissions panel, select the resource that you want to modify.
3. Click Edit -> Permission Properties.
4. In the Permission Properties editor, select the new permission: Read/Write, Read-Only or Deny.
5. Optionally, click Check for conflicts to view any conflicts that result from the change. For information about
conflicting permissions, see Applying Permissions and Managing Conflicts.
6. To save the change, click the Save icon.
Removing Permissions
You can remove permissions from user-defined admin roles and admin groups. You cannot remove permissions from
system-defined admin roles. When you remove permissions from a role, it is removed from the role in all admin
groups to which the role is assigned. You can remove a permission from a group as long as it was not inherited from
a role. You cannot remove permissions that were inherited from a role.
To remove a permission:
To remove the permissions of an admin role, click + (for Roles) -> + (for admin_role).
To remove the permissions of an admin group, click + (for Groups) -> + (for admin_group) -> + (for
Permissions).
2. Select the permission type and in the Permissions panel, select the resource that you want to remove
3. Right-click, and then select Remove.
4. Click Yes when the confirmation dialog appears.
Administrative Permissions for Grid Members
By default, the grid master denies access to grid members when a limited-access admin group does not have defined
permissions. You can grant an admin group read-only or read/write permission, or deny access to all grid members
or you can grant permission to specific grid members, as described in Defining Permissions on page 77.
Note: Only superusers can modify DNS and DHCP grid properties.
The following table lists the different types of permissions that you can define for grid members and the actions
admins can perform with each permission.
Table 3.5 Grid Member Permissions
Admins with the following permission(s) Can perform the following tasks
Read-only to grid members View DNS member properties
View and download syslog
View DNS cache and configuration file
View DHCP member properties
View network statistics and DHCP configuration file
Restart grid DNS and DHCP services
Read-only to grid members
Read/Write to networks and DHCP ranges
Assign members to networks and DHCP ranges
Read/Write to grid members Edit member properties
Clear DNS cache
Read/Write to grid members
Read-only to views
Add grid members to the Match Members list of a
view
Delete a view with grid members in the Match
Members list
Read/Write to zones
Assign members to DNS zones
Managing DNS Resource Permissions
You can grant roles and admin groups read-only or read/write permission, or deny access to the following DNS
resources:
Views
Zones
A records
AAAA records
CNAME
DNAME
MX
PTR
SRV
TXT
Hosts
Bulk Hosts
Shared Record Groups
Shared A records
Shared AAAA records
Shared MX records
Shared SRV records
Shared TXT records
The appliance applies permissions for DNS resources hierarchically. Permissions to an Infoblox view apply to all
zones and resource records in that view. Permissions for a zone apply to all its subzones and resource records, and
resource record permissions apply to those resource records only. To override permissions set at higher level, you
must define permissions at a more specific level. To assign permissions, see Defining Permissions on page 77. The
following sections describe the different types of permissions that you can set for DNS resources:
Administrative Permissions for Views on page 84
Administrative Permissions for Zones on page 85
Administrative Permissions for Resource Records on page 87
Administrative Permissions for Views
Limited-access admin groups can access Infoblox views, including the default view, only if their administrative
permissions are defined. Permissions to an Infoblox view apply to all its zones and resource records. To override
view-level permissions, you must define permissions for its zones and resource records. For example, you can grant
an admin group read-only permission to a view and read/write permission to all its zones. This allows the admins to
display the view properties, but not edit them, and to create, edit and delete zones in the view.
You can grant read-only or read/write permission, or deny access to Infoblox views, as follows:
All viewsGlobal permission that applies to all Infoblox views in the database.
A specific viewApplies to its properties and its zones, if you do not define zone-level permissions. This
overrides the global view permissions.
All zones in a viewIf you do not define permissions for zones, they inherit the permissions of the view they are
in.
For information on setting permissions for a view and its zones, see Defining Permissions on page 77.
The following table lists the different types of permissions that you can set for Infoblox views and the actions admins
can perform with each permission.
Table 3.6 Permissions for Views
Read-only to all views
Display view properties
Display zones and resource records
Read/Write to all views
Create, modify, and delete views
Create, modify, and delete zones and resource
records
Read/Write to a view
Modify and delete the view
Add, modify, and delete all zones and resource
records in the view
Read-only to a view
Read/Write permission grid members
Add grid members to the Match Members list of a
view
Delete a view with grid members in the Match
Members list
Read-only to all zones in a view
Display zone properties, subzones and resource
records
Read/Write to all zones in a view
Create, modify, and delete zones
Add, modify, and delete subzones and resource
records
Administrative Permissions for Zones
By default, zones inherit administrative permissions from the Infoblox view in which they reside. You can override
view-level permissions by setting permissions for specific zones. Permissions set for a zone are inherited by its
subzones and resource records. To override zone-level permissions, set permissions for specific subzones and
resource records.
For example, you can grant an admin group the following permissions:
Read-only to a zone and to all its A, AAAA, and PTR records
Read/Write permission to all MX and SRV records in the zone
Deny to all the other resource recordsCNAME, DNAME, TXT, host, and bulk host
You can grant read-only or read/write permission, or deny access to zones as follows:
All zones Global permission that applies to all zones in all views.
All zones in a viewPermissions at this level override the global permissions.
A specific zoneApplies to the zone properties and resource records, if you do not define permissions for its
resource records. This overrides global and view-level permissions. If you delete a zone and reparent its
subzone, the subzone inherits the permissions of the new parent zone.
Each resource record type in a zoneFor example, you can define permissions for all A records and for all PTR
records in a zone. if you do not define permissions for resource records, they inherit the permissions of the zone
in which they reside.
For information on setting permissions for zones and resource records, see Defining Permissions on page 77.
The following table lists the different types of permissions that you can set for zones and their corresponding tasks.
Table 3.7 DNS Zone Permissions
Read-only to a zone
View zone properties, subzones, and resource
records
Search for the zone, its subzones, and resource
records
Read/Write to all zones
Create, modify, and delete subzones and resource
records
Search for zones, subzones, and resource records
Read/Write to all zones in a view
Create, modify, and delete all zones in the view
records
Search for zones, subzones, and resource records
Read/Write to a zone
Modify and delete the zone
records
Lock and unlock the zone
Search within the zone for its subzones and
resource records
Assign grid members to a zone
Delete a zone with assigned grid members
Read/Write to all grid members in a name
server group
Assign a name server group to a zone
Delete a zone with name server groups assigned
Read/Write to a shared record group Assign a shared record group to a zone
Source zone:
Read-only to the source zone
Read-only to resource records to be copied
Destination zone:
Read/Write to the destination zone
Read/Write to all resource records in the
destination zone
Copy resource records from one zone to another
Administrative Permissions for Resource Records
Resource records inherit the permissions of the zone to which they belong. You can override zone-level permissions
by setting permissions for specific resource records.
You can grant read-only or read/write permission, or deny access to resource records as follows:
Each resource record type in all zones and in all viewsGlobal permission that applies to all resource records of
the specified type; for example, all A records in the database.
Each resource record type in a zone Permissions at this level override global permissions.
A specific resource recordOverrides zone-level permissions.
For information on setting permissions for resource records, see Defining Permissions on page 77. The following
table lists the different types of permissions that you can set for resource records and the actions admins can perform
with each permission.
Table 3.8 DNS Resources
The following are additional guidelines:
Only admins with read/write permission to bulk host records and read/write permission to reverse zones can
create bulk host records and automatically add reverse-mapping zones.
To create host records, admins must have read/write permission to the network and zone of the host.
Admins must have read-only permission to the host records in a zone to view the Host Name Compliance
Report. Admins must have read/write permission to the resource records in a zone to modify host names that
do not comply with the host policy.
Read-only to a resource record type, such as all A
records or all PTR records
View resource records for the specified type only
Search for records of the specified type
Read/Write to a resource record types, such as
all A records or all PTR records
Create, modify, and delete resource records for the
specified type
Read-only to a resource record
View the resource record
Read/Write to a resource record View, modify, and delete the resource record
Administrative Permissions for Shared Record Groups
By default, only superusers can add, edit, and delete shared record groups. Limited-access admin groups can access
shared record groups, only if their administrative permissions are defined.
You can set different permissions for a shared record group and for each type of shared resource record in the group.
For example, you can grant a role or an admin group the following permissions:
Read-only to a shared record group and to all its shared A and AAAA records
Read/Write permission to all the shared MX and SRV records in the shared record group
Deny to the TXT records
You can grant read-only or read/write permission, or deny access to shared record groups, as follows:
All shared record groupsGlobal permission that applies to all shared record groups in the database.
A specific shared record groupOverrides global permissions.
Each shared record type in all shared record groups The shared resource record types include shared A
records, shared AAAA records, shared MX records, shared SRV records, and shared TXT resource records.
Each shared record type in a shared record group Permissions at this level override global permissions.
A specific shared recordOverrides zone-level permissions.
For information on setting permissions for shared record groups, see Defining Permissions on page 77. The following
table lists the different types of permissions that you can set for shared record groups and the actions admins can
perform with each permission.
Table 3.9 Permissions for Shared Record Groups
Read-only to a shared record group View the shared record group
Read/Write to all shared record groups Create, modify, and delete shared record groups
Read/Write to a shared record group Modify and delete the shared record group
Read/Write to a shared record group
Read/Write to target zones
Assign a shared record group to zones
Change the zones associated with the shared
record group
Delete zones with a shared record group assigned.
Before you delete a shared record group, you must
remove all zones associated with it.
Read-only to a shared record type in all
shared record groups
View the shared records for the specific type only
Read/Write to a shared record type in all
shared record groups
Create, modify, and delete shared records for the
specified type
Read-only to a shared record type in a
specific shared record group
View the shared records for the specific type in the
specified shared record group only
Read/Write to a shared record type in a
specific shared record group
Create, modify, and delete shared records for the
specific type in the specified shared record group
only
Read-only to a specific shared record View the shared record
Read/Write to a specific shared record View, modify and delete the shared record
Note the following guidelines:
Shared record group permissions override zone permissions.
Even if a zone is locked, superusers and limited-access users with read/write access can still edit or delete a
shared record in the zone.
Managing Administrative Permissions for DHCP Resources
Limited-access admin groups can access certain DHCP resources only if their administrative permissions are defined.
By default, the appliance denies access when a limited-access admin group does not have defined permissions. You
can grant admin groups read-only or read/write permission, or deny access to the following DHCP resources:
Networks
Shared networks
DHCP ranges
Fixed addresses
MAC address filters
Network templates
DHCP range templates
Fixed address templates
DHCP lease history
You can grant an admin group broad permissions to DHCP resources, such as read/write permission to all networks
and shared networks in the database. In addition, you can grant permission to specific resources, such as a specific
network, a DHCP range, or an individual IP address in a network. Permissions at more specific levels override global
permissions.
The following sections describe the different types of permissions that you can set for DHCP resources:
Administrative Permissions for Networks and Shared Networks on page 91
Administrative Permissions for Fixed Addresses on page 93
Administrative Permissions for DHCP Ranges on page 94
Administrative Permissions for DHCP Templates on page 95
Administrative Permissions for MAC Address Filters on page 96
Administrative Permissions for the DHCP Lease History on page 97
Administrative Permissions for Networks and Shared Networks
Limited-access admin groups can access networks, including shared networks, only if their administrative
permissions are defined. Permissions for a network apply to all its DHCP ranges and fixed addresses. To override
network-level permissions, you must define permissions for specific DHCP ranges and fixed addresses. For example,
you can grant an admin group read-only permission to a network, read/write permission to its DHCP ranges, and
read-only permission to its fixed addresses.
You can grant read-only or read/write permission, or deny access to networks, as follows:
All networks and all shared networksGlobal permission that applies to all networks in the database.
A specific networkNetwork permissions apply to its properties and to all DHCP ranges, fixed addresses and
hosts in the network, if they do not have permissions defined. This overrides global permissions.
All DHCP ranges in a networkIf you do not define permissions for DHCP ranges, they inherit the permissions of
the network in which they reside.
All fixed addresses in a networkIf you do not define permissions for fixed addresses, they inherit the
permissions of the network in which they reside.
To define permissions for a specific network and its DHCP ranges and fixed addresses, see Defining Permissions on
page 77.
The following table lists the different types of permissions that you can set for networks and their corresponding
tasks.
Table 3.10 Network Permissions
Read-only to all networks View the properties of all networks
View network statistics
Read-only to all networks
Read-only to all views
View the IP Address Management panel
Read/Write to all networks Create, modify, and delete networks and
shared networks
Create, modify, and delete DHCP ranges
and fixed addresses
Expand/join networks
Read/Write to all networks
Read-only to network templates
Create networks from templates
Read-only to all shared networks View shared networks
Read/Write to all shared networks Create, modify, and delete shared
networks
Read-only to a specific network View the properties of the network
View network statistics
Search for the network
Read/Write to a specific network Modify and delete the network
Create, modify, and delete DHCP ranges
and fixed addresses in the network
Expand/join networks, if admins have
read/write permission to both networks
Read/Write to a network
Read/Write to the parent zones
Create/Split network and automatically
create the reverse zone
Read/Write to a network
Read/Write to a grid member
Assign a grid member to the network and
its DHCP ranges
Modify and delete a network with the
assigned grid member
Read-only to all DHCP ranges in a network View DHCP ranges
Search for DHCP ranges
Read/Write to all DHCP ranges in a network Create, modify, and delete DHCP ranges
Read-only to all fixed addresses in a network View fixed addresses
Search for fixed addresses
Read/Write to all fixed addresses in a network Create, modify, and delete fixed addresses
Administrative Permissions for Fixed Addresses
Fixed addresses inherit the permissions of the networks in which they reside. You can override network-level
permissions by defining permissions for fixed addresses.
You can grant read-only or read-write permission, or deny access to fixed addresses, as follows:
All fixed addressesGlobal permission that applies to all fixed addresses in the database.
All fixed addresses in a network Permissions at this level override global permissions. If you do not define
permissions for fixed addresses, they inherit the permissions of the network in which they reside.
A single fixed addressOverrides global and network-level permissions.
For information on setting permissions for fixed addresses, see Defining Permissions on page 77.
The following table lists the different types of permissions that you can set for fixed addresses and their
corresponding tasks.
Table 3.11 Permissions for Fixed Addresses
Read-only to all fixed addresses View fixed addresses
Search for fixed addresses
Read-only to all fixed addresses in a
network
View fixed addresses in the network
Search for fixed addresses in the network
Read/Write to all fixed addresses Create, modify, and delete fixed addresses
Read/Write to all fixed addresses in a
network
Create, modify, and delete fixed addresses in the
network
Read-only to a fixed address View the fixed address
Read/Write to a fixed address Modify and delete the fixed address
Administrative Permissions for DHCP Ranges
DHCP ranges inherit the permissions of the networks in which they reside. You can override network-level
permissions by defining permissions for DHCP ranges. You can read-only or read/write permission, or deny access to
DHCP address ranges, as follows:
All DHCP rangesGlobal permission that applies to all DHCP ranges in the database.
All DHCP ranges in a networkPermissions at this level override global permissions. If you do not define
permissions for DHCP ranges, they inherit the permissions of the network in which they reside.
A single DHCP rangeOverrides global and network-level permissions.
For information on setting permissions for DHCP ranges, see Defining Permissions on page 77. The following table
lists the different types of permissions that you can set for DHCP ranges and their corresponding tasks.
Table 3.12 DHCP Ranges
Read-only to all DHCP ranges View DHCP ranges
Read-only to all DHCP ranges in a network
View DHCP ranges

Read/Write to all DHCP ranges Create, modify, and delete DHCP ranges
Read/Write to all DHCP ranges in a network Create, modify, and delete DHCP ranges in the
network
Search for DHCP ranges in the network
Read/Write to a DHCP range Modify and delete the DHCP range
Apply relay agent filers and Option filters to the
DHCP range
Read/Write to a DHCP range
Read-only to a MAC address filter
Apply a MAC address filter to a DHCP range
Read/Write to all grid members that serve
the DHCP range, including members in a
DHCP failover association, if enabled
Assign a grid member to a DHCP range
Modify and delete the DHCP range with the
assigned grid members or DHCP failover
association
Administrative Permissions for DHCP Templates
There are three types of DHCP templatesnetwork, DHCP range, and fixed address templates. To access any of these
templates, a limited-access admin group must have read-only permission to the template. Limited-access admin
groups cannot have read/write permission to the templates. Only superusers can create, modify and delete network,
DHCP range, and fixed address templates. An admin group with read-only permission to the DHCP templates can view
them and use them to create networks, DHCP ranges and fixed addresses, as long as they have read/write
permissions to those DHCP resources as well.
You can set global read-only permission that applies to all DHCP templates, and you can set permissions to specific
templates as well.
For information on setting permissions, see Defining Permissions on page 77. The following table lists the different
types of permissions that you can set for DHCP templates and their corresponding tasks.
Table 3.13 Permissions for DHCP Templates
Note the following additional guidelines:
DHCP range templates and fixed address templates do not inherit their permissions from network templates.
You must set permissions for each type of template.
An admin group can create a network using a network template that includes a DHCP range template and a fixed
address template, even if it has no permission to access the DHCP range and fixed address templates.
Read-only permission to a DHCP template View the template
Read-only permission to a DHCP template
Read/Write permission to all networks
Create a network from a template
Read/Write permission to all DHCP ranges
or to a network
Create a DHCP range from a template
Read/Write permission to all fixed
addresses or to a network
Create a fixed address from a template
Administrative Permissions for MAC Address Filters
Limited-access admin groups can access MAC address filters only if their administrative permissions are defined. The
appliance denies access to MAC address filters for which an admin group does not have defined permissions.
You can grant read-only or read/write permission, or deny access to MAC address filters as follows:
All MAC address filters in the database
A specific MAC address filter
types of permissions that you can set for MAC address filters and their corresponding tasks.
Table 3.14 Permissions for MAC Filters
Administrative Permissions for Network Discovery
Limited-access admin groups can initiate a discovery and manage discovered data based on their administrative
permissions.
You can set global permissions for network discovery as described in Defining Permissions on page 77. The following
table lists the different types of permissions that you can set for network discovery and their corresponding tasks.
Table 3.15 Permissions for Network Discovery
Read-only to a MAC address filter View the MAC address filter and its MAC address
entries
Read-only to a MAC address filter
Apply a MAC address filter to a DHCP range
Delete a MAC address filter from a DHCP range
Read/Write to all MAC address filters Create, modify, and delete MAC address filters
Add and delete MAC address entries
Read/Write to a MAC address filter Modify and delete the MAC address filter
Add, modify, and delete MAC address entries
Read/Write to network discovery
Read-only to networks selected for
discovery
Initiate and control a discovery on networks with
read-only permission
view discovered data
Read/Write to networks selected for
discovery
View discovered data.
Add unmanaged data to existing hosts, and resolve
conflicting IP addresses.
Read/Write to networks selected for
discovery
Read/write to a DNS zone or specific record
type
Convert unmanaged data to a host, fixed address,
reservation, A record, or PTR record
Administrative Permissions for the DHCP Lease History
A limited-access admin group can view and export the DHCP lease history if it has read-only permission to the DHCP
lease history. Permissions to the DHCP lease history are different from the network permissions. Therefore, an admin
group can access the DHCP lease history, regardless of its network permissions. Note that only superusers can import
a DHCP lease history file.
To define permissions for the DHCP lease history:
To define the permissions of an admin role, click + (for Roles) -> + admin_role -> Edit -> Add Permissions.
To define the permissions of an admin group, click + (for Groups) -> admin_group -> Edit -> Add Permissions.
2. Click Add in the Add Global Permissions tab.
From the Resource drop down list, select DHCP Lease History, and then click Read Only or Deny.
3. Click OK to close the dialog box.
Administrative Permissions for the RADIUS Service
If you configured the RADIUS service on the NIOS appliance, you can restrict access to the service and its resources.
By default, the appliance denies access to the resources of the RADIUS service, unless an admin group has their
administrative permissions defined.
You can grant read-only or read/write permission, or deny access to the following RADIUS resources:
Grid AAA PropertiesApplies to the grid and its members, the local and replicated users, policies, and external
services, unless permissions are defined. You can set this from the Administrators perspective only.
Member AAA properties Overrides the grid-level permission for the member only. The permission you set here
does not affect the permissions for the local and replicated users, policies and external services.
AAA Local UsersInherits the grid permission, unless otherwise defined.
AAA Replicated UsersInherits the grid permission, unless otherwise defined.
AAA PoliciesInherits the grid permission, unless otherwise defined.
AAA External ServicesInherits the grid permission, unless otherwise defined.
types of permissions that you can set for RADIUS resources and their corresponding tasks.
Table 3.16 Permissions for AAA
Read-only to AAA grid properties Download CA certificates
Download certificate signing request
Download EAP server certificate
View the AAA member properties
Read/Write to grid AAA properties All tasks in the AAA perspective
Read-only to AAA member properties View syslog
View RADIUS configuration
Export RADIUS detail file
Read/Write to AAA member properties Edit member properties
Read-only to AAA local users View local users
Read/Write to AAA local users Add, modify, and delete local users
Read-only to AAA replicated users View replicated users
Read/Write to AAA replicated users Add, modify, and delete AD domains
Synchronize with AD domain
Delete replicated AD users and groups
Read-only to external services View RADIUS authentication and accounting home
servers, network access servers, and AD, LDAP and
McAfee authentication services
Administrative Permissions for the RADIUS Service
Read/Write to external services Add, modify, and delete network access servers
Add, modify, and delete RADIUS authentication
home servers
Add, modify, and delete RADIUS accounting home
servers
Add, modify, and delete AD authentication services
Add, modify, and delete LDAP authentication
services
Add, modify, and delete McAfee validation services
Read/Write to external services
Read/Write to AAA member properties
Associate the grid member with a NAS
Read-only to AAA policies View policies
Read/Write to AAA policies Add, edit and remove policies
Administrative Permissions for File Distribution Services
You can restrict access to the TFTP, HTTP and FTP services provided by the appliance. By default, the appliance denies
access to the TFTP, HTTP and FTP services, unless an admin group has their administrative permissions defined.
You can grant read-only or read/write permission, or deny access to the following resources:
Grid File Distribution PropertiesApplies to the grid and its members, directories, and files. You can set this
from the Administrators perspective only.
Member File Distribution PropertiesApplies to the grid member properties only.
A specific directoryApplies to the directory and its files.
types of permissions that you can set for file distribution services and their corresponding tasks.
Table 3.17 Permissions for File Distribution Services
Read-only to Grid File Distribution
Properties
View the grid and member file distribution
properties, directories, and files
Read/Write to Grid File Distribution
Properties
Edit the grid and member file distribution
properties
Create and remove directories and files
Read-only to Member File Distribution
Properties
View the member file distribution properties
Read/Write to Member File Distribution
Properties
Edit the member file distribution properties
Read-only to a directory View the directory, its files, and subdirectories
Read/Write to a directory Remove the directory
Add and remove files and subdirectories
Authenticating Administrators
Authenticating Administrators
The NIOS appliance supports the following authentication methods: local database, RADIUS, and Active Directory.
The appliance can use any combination of these authentication methods. It authenticates admins against its local
database by default. Therefore, if you want to use local authentication only, then you must configure the admin
groups and add the local admin accounts, as described in Authenticating Administrators on page 101.
If you want to authenticate admins using RADIUS and Active Directory in addition to local authentication, then you
must define those services on the appliance and define the admin policy. For additional information, see About
Remote Admins on page 102.
Note: Infoblox strongly recommends that even if you are using remote authentication, you must always have at least
one local admin in a local admin group to ensure connectivity to the NIOS appliance in case the remote servers
become unreachable.
Creating Local Admins
When you create an admin account, you must specify the name, password, and admin group of the admin. You can
optionally provide an e-mail address and specify the page size of the GUI.
In addition, you can also control in which time zone the appliance displays the time in the audit log and the DHCP
and IPAM perspective windows, such as the DHCP Lease History and DHCP Leases panels. The appliance can use the
time zone that it automatically detects from the management system that the admin uses to log in. Alternatively, you
can override the time zone auto-detection feature and specify the time zone.
To create an admin account and add it to an admin group:
1. Log in using a superuser account.
2. From the Administrators perspective, click + (for Groups) -> admin_group -> Edit -> Add Local Admin.
3. Enter the following:
Admin Name: Enter the name of the administrator. This is the name that the administrator uses to log in.
Group: Choose the admin group of the administrator. An admin can belong to only one admin group at a
time.
Email Address: Enter the e-mail address for this administrator. Note that this address simply provides
contact information. The NIOS appliance does not send e-mail notifications to it. You define the e-mail
address for notifications on the Email section of the Device or Grid Editor.
Comment: Enter pertinent information about the administrator, such as location or department.
Password: Enter a password for the administrator to use when logging in.
Re-Type Password: Enter the same password.
Override admin group page size: Clear this check box to use the same page length specified for the admin
group. Select this check box to enter a different page length.
this administrator. When there is a lot of data, you can improve the display performance by setting a smaller
page size, such as 100 instead of 1000. You can set the page size from 10 to 2000. The default page size is
100.
Override auto-detect time zone: Select this check box if you want to specify the time zone for the
administrator. Clear this check box if you want the appliance to automatically detect the time zone from the
management system that the administrator uses to connect to the appliance.
Time Zone: Select the time zone that the appliance uses when it displays the dates and time stamps in
the audit log and the DHCP and IPAM perspective windows.
Disable this admin: Select this check box to retain an inactive profile for this administrator in the
configuration. For example, you might want to define a profile for a recently hired administrator who has not
yet started work. Then when he or she does start, you simply need to clear this check box to activate the
profile.
4. Click the Save icon to save your changes.
Modifying and Removing an Admin Account
You can modify and remove the admin accounts you create, but you can only partially modify the default superuser
account adminand only when you are logged in as the superuser admin. Furthermore, because there must
always be a superuser account on the appliance, you can only remove the default admin account after you create
another superuser account.
About Remote Admins
You can configure the NIOS appliance to authenticate admins whose user credentials are stored on a RADIUS server
or AD domain controller. The appliance can authenticate users against more than one authentication server, and
supports remote and local authentication.
To authenticate admins using RADIUS and Active Directory, you must define those services on the appliance and
define the admin policy. The admin policy lists which authentication methods to use and in what order. It also lists
admin groups that you have configured on the appliance and to which you can assign remote admins. An admin
inherits its privileges from its admin group; therefore, all admins must be assigned to an admin group. If you
configured admin groups on the remote authentication server, the group names on the remote authentication server
must match the group names on the NIOS appliance so the appliance can assign an admin to the correct group. If you
did not configure admin groups on the remote authentication server, you must configure a default group for remote
admins on the NIOS appliance.
When an admin logs in with a user name and password, the appliance uses the first method listed in the admin policy
to authenticate the admin. If authentication fails, the appliance tries the next method listed. It tries each method on
the list until it is successful or all methods fail. If all methods fail, then the appliance denies access to the appliance.
If authentication succeeds, the NIOS appliance determines the admins privileges based on the admin group of the
admin. It tries to match the admin group names in the order in which they are listed in the admin policy to any groups
received from the remote server. If it finds a match, the NIOS appliance applies the privileges of that group to the
admin and allows access. If the appliance does not find a match, then it applies the privileges of the default group.
If no default group is defined, then the appliance denies access. Figure 3.7 illustrates the authentication and
authorization process for remote admins.
About Remote Admins
Figure 3.7 Authenticating Remote Admins
To configure the appliance to authenticate admins against a RADIUS server and an AD controller:
Configure the RADIUS authentication service and AD authentication service. For information about the RADIUS
authentication service, see Authenticating Using RADIUS. For information about the AD authentication service,
see Authenticating Admin Accounts Using Active Directory on page 110.
Configure admin groups that match those on the remote server. Optionally, specify a default admin group. For
information about admin groups, see About Admin Groups on page 69.
Configure the admin policy, as described in Defining the Admin Policy on page 112.
Note: Infoblox strongly recommends that even if you are using remote authentication, you must always have at least
one local admin in a local admin group to ensure connectivity to the appliance in case the remote servers
become unreachable.
An admin enters his user name
and password to log in to the
appliance.
The appliance checks the admin policy
for the first authentication method, which
is RADIUS.
The appliance sends an Access-Request
packet to the RADIUS server.
The RADIUS server responds with an
Access-Reject package because the admins user
name and password are not in its database.
The appliance tries the next authentication
method on the list, which is Active Directory
(AD). It sends a request to the AD server.
The AD server finds the user name and password
in its database and sends an access accept
together with the admins group memberships.
User Name Member Of
admin10 IT-Bldg1
IT-Bldg2
RADIUS
Server
AD Server
Remote Admin Groups
Eng
IT-Bldg2
The appliance matches one of the
admins groups with a group in the
admin policy.
The appliance allows the admin
to log in and applies the
privileges of the IT-BLDG2
1
2
3
7
5
6
4
Admin
Policy
Admin NIOS appliance
Authenticating Using RADIUS
RADIUS provides authentication, accounting, and authorization functions. The NIOS appliance supports
authentication using the following RADIUS servers: RADIUSone, FreeRADIUS, Microsoft, Cisco, and Funk.
You must be a superuser to configure admin accounts and RADIUS server properties on the NIOS appliance.
When you configure the appliance to authenticate administrators using a RADIUS server, the appliance acts similarly
to a network access server (NAS), which is a RADIUS client that sends authentication and accounting requests to the
RADIUS server. Figure 3.8 illustrates the authentication process.
Figure 3.8 Authentication using a RADIUS server
1
3
2
4a
4b
NIOS appliance RADIUS Server
A user makes an HTTPS connection
to the NIOS appliance and sends a
user name and password.
The appliance lets the user log in and
applies the authorization profile.
The appliance does not allow the user
to log in.
The appliance sends an
Access-Request packet to the RADIUS
If the RADIUS server authenticates the
user, it sends back an Access-Accept
packet.
If the RADIUS server rejects the
authentication request, it sends back an
Access-Reject packet.
Administrator
The appliance checks the remote admin
policy and selects RADIUS as the
authentication method.
Remote RADIUS Authentication
When you configure the NIOS appliance for remote authentication with a RADIUS server, you must specify the
authentication method of the RADIUS server. Specify PAP (Password Authentication Protocol) or CHAP (Challenge
Handshake Authentication Protocol).
PAP tries to establish the identity of a host using a two-way handshake. The client sends the user name and password
in clear text to the NIOS appliance. The appliance uses a shared secret to encrypt the password and sends it to the
RADIUS server in an Access-Request packet. The RADIUS server uses the shared secret to decrypt the password. If the
decrypted password matches a password in its database, the user is successfully authenticated and allowed to log
in.
With CHAP, when the client tries to log in, it sends its user name and password to the NIOS appliance. The appliance
then creates an MD5 hash of the password together with a random number that the appliance generates. It then
sends the random number, user name, and hash to the RADIUS server in an Access-Request package. The RADIUS
server takes the password that matches the user name from its database and creates its own MD5 hash of the
password and random number that it received. If the hash that the RADIUS server generates matches the hash that
it received from the appliance, then the user is successfully authenticated and allowed to log in.
To configure the NIOS appliance to authenticate administrators using a RADIUS server, you must configure admin
accounts and groups for these administrators on the RADIUS server. Then, on the NIOS appliance, you must do the
following:
Configure RADIUS service on the appliance.
Define one or more admin groups and specify its privileges and settings. The names must match admin group
names defined on the RADIUS server. The NIOS appliance applies these privileges and settings to users
belonging to those groups on the RADIUS server. See About Admin Groups on page 69 for information about
defining admin groups.
If there are no admin groups defined on the RADIUS server, designate an admin group as the default group. See
Configuring the Default Admin Group on page 112 for information about defining a default admin group.
Add RADIUS service to the list of admin authentication methods in the admin policy to enable RADIUS
authentication. See Configuring a List of Authentication Methods on page 113 for more information about
configuring admin policy.
Configuring RADIUS Authentication on the NIOS Appliance
To configure RADIUS server authentication for admins:
1. From the Administrators perspective, click + (for Remote Admins) -> RADIUS Authentication Services -> RADIUS
Service -> Edit -> General RADIUS Properties.
2. In the RADIUS Authentication for Administrators editor, enter the following:
Use MGMT port: Select check box if the MGMT port is enabled and you want the NIOS appliance to
communicate with all RADIUS servers through its MGMT port. If you clear the check box, you can still
selectively use the MGMT port for one or more specific RADIUS servers (see Adding RADIUS Servers on
page 106).
Optionally, modify the Authentication settings. These settings apply to all RADIUS servers that you
configure on the NIOS appliance.
Retry Period: Specify the number of seconds that the appliance waits for a response from the
RADIUS server. The default is 5.
Maximum Retries: Specify how may times the appliance attempts to contact an authentication
If you configured multiple RADIUS servers for authentication and the NIOS appliance fails to contact the first
server in the list, it tries to contact the next server, and so on.
Optionally, modify the Accounting settings.
Retry Period: Specify the number of seconds that the appliance waits for a response from the
Maximum Retries: Specify how may times the appliance attempts to contact an accounting RADIUS
server. The default is 1000.
If you configured multiple RADIUS servers for accounting and the NIOS appliance fails to contact the first
server in the list, it tries to contact the next server, and so on.
Adding RADIUS Servers
You configure RADIUS server settings for admins at the grid level. Therefore all members in a grid use the same set of
RADIUS servers. You can configure multiple RADIUS servers for redundancy. When you do, the appliance tries to
connect to the first RADIUS server on the list and if the server does not respond within the maximum retransmission
limit, then it tries the next RADIUS server on the list.
To add and configure the properties of a RADIUS server:
Service -> Edit -> General RADIUS Properties. The RADIUS Authentication for Administrators editor appears.
2. In the RADIUS Server Group section, click Add.
3. In the RADIUS Server Properties editor, enter the following:
Server Name: Type a name for the RADIUS server. This name is for internal reference; for example, auth1.
It does not need to be the FQDN (fully qualified domain name) of the RADIUS server.
Comment: Enter additional information about the RADIUS server.
Authentication
Type: Specify the authentication method of the RADIUS server. You can specify either PAP
(Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol). The
default is PAP.
IP Address: The IP address of the RADIUS server that is used for authentication.
UDP Port: The destination port on the RADIUS server. The default is port 1812.
Shared Secret: Enter the shared secret that the NIOS appliance and the RADIUS server use to
encrypt and decrypt their messages. This shared secret is a value that is known only to the NIOS
appliance and the RADIUS server.
Accounting
Enable Accounting: Select this check box to enable the accounting feature, so you can track an
administrators activities during a session.
IP Address: The IP address of the RADIUS server that is used for accounting. The default is the IP
address of the authentication RADIUS server.
UDP Port: The destination port on the RADIUS server. The default is port 1813.
Shared Secret: Enter the shared secret that the appliance and the RADIUS server use to encrypt
and decrypt their accounting messages. A shared secret is a value that is known only to the
appliance and the RADIUS server.
Use MGMT port: If you clear the Use MGMT port check box in the General RADIUS Properties editor and
select this check box, the NIOS appliance uses the MGMT port for administrator authentication
communications with just this RADIUS server.
If you select the Use MGMT port check box in the General RADIUS Properties editor, this check box becomes
irrelevant. Whether you select or clear it, the NIOS appliance always uses the MGMT port for
communications with all RADIUS servers, including this one.
Disable this server: Select this check box to disable a RADIUS server if, for example, the connection to the
server is down and you want to stop the NIOS appliance from trying to connect to this server.
4. Click OK.
Testing the RADIUS Server
After you add a RADIUS server to the NIOS appliance, you can validate the configuration. The appliance uses a
pre-defined user name and password when it tests the connection to the RADIUS server. The pre-defined user name
is infoblox_test_user and the password is infoblox_test_password. Do not use these as your administrator user
name and password.
To test the configuration:
Service -> Edit -> General RADIUS Properties. The RADIUS Authentication for Administrators dialog box appears.
2. In the RADIUS Server Group section, select a server and click Modify. The RADIUS Server Properties dialog box
appears.
3. Click Test Configuration.
If the NIOS appliance connects to the RADIUS server using the configuration you entered, it displays a message
confirming the configuration is valid. If it is unable to connect to the RADIUS server, the appliance displays a
message indicating an error in the configuration.
Maintaining the RADIUS Admins Server List on the NIOS Appliance
When you add multiple RADIUS servers, the appliance lists the servers in the order in which you added them. This list
also determines the order in which the NIOS appliance attempts to contact a RADIUS server. You can change the order
of the list, as follows:
2. The RADIUS Server Group section lists the RADIUS servers. Do the following:
To move a server up on the list, select it and click Move Up.
To move a server down on the list, select it and click Move Down.
Disabling a RADIUS Server
You can disable a RADIUS server if, for example, the connection to the server is down and you want to stop the NIOS
appliance from trying to connect to this server. To disable a RADIUS server:
2. In the RADIUS Server Group section, select a server and click Modify. The RADIUS Server Properties dialog box
appears.
3. Click Disable this server.
4. Click OK.
Configuring a RADIUS Server
In addition to setting up the NIOS appliance to communicate with a RADIUS server, you must also set up the remote
RADIUS server to communicate with the NIOS appliance.
Note: If you have two Infoblox appliances in an HA pair, enter both the members of the HA pair as separate access
appliances and use the LAN IP address of both appliances (not the VIP address).
Depending on your particular RADIUS server, you can configure the following RADIUS server options to enable
communication with the NIOS appliance:
Authentication Port
Accounting Port
Domain Name/IP Address of the NIOS appliance
Shared Secret Password
Vender Types
Configuring Admin Groups on the Remote RADIUS Server
Infoblox supports admin accounts on one or more RADIUS servers.
To set up admins and associate them with an admin group on a remote RADIUS server, do the following:
Import Infoblox VSAs (vendor-specific attributes) to the dictionary file on the RADIUS server
For third-party RADIUS servers, import the Infoblox vendor file (the Infoblox vendor ID is 7779)
Define a local admin group on the NIOS appliance (or use an existing group)
Define a remote admin groupwith the same name as the group defined on the NIOS applianceon the RADIUS
server
Associate one or more remote admin accounts on the RADIUS server with the remote admin group
Refer to the documentation for your RADIUS server for more information.
Configuring Remote Admin Accounts on the Remote RADIUS Server
To set up remote admin accounts on a RADIUS server and apply the privileges and properties of the admin group
designated as the default group on the NIOS appliance, do the following:
Define an admin group on the NIOS appliance and specify it as the default group. You define admin groups for
remote admins within the admin policy. See Defining the Admin Policy on page 112 for more information on
configuring remote admin policies and remote admin group lists.
On the RADIUS server:
Create one or more admin accounts. (See RADIUSone documentation.)
Add and activate a policy for the admin accounts, but do not associate the policy with a policy group that
contains an infoblox-group-info attribute.
When an administrator whose account is stored on a RADIUS server attempts to log in to a NIOS appliance, the NIOS
appliance forwards the user name and password for authentication to the RADIUS server. When the server
successfully authenticates the administrator and it responds to the NIOS appliance without specifying an admin
group, the appliance applies the privileges and properties of the default admin group to that administrator. Refer to
the documentation for your RADIUS server for more information.
Authorization Groups Using RADIUS
You can specify authorization privileges for an admin group on the NIOS appliance only. The appliance ignores
authorization settings from the RADIUS server. Therefore, you must configure all admin groups on the NIOS
appliance, regardless of where the admin accounts that belong to those groups are storedon the NIOS appliance
or on the RADIUS server. For information about specifying superuser and limited-access authorization privileges, see
Creating a Superuser Admin Group on page 69 and About Limited-Access Admin Groups on page 70.
Accounting Activities Using RADIUS
You can enable the accounting feature on the RADIUS server to track an administrators activities during a session.
After an administrator successfully logs in, the appliance sends an Accounting-Start packet to the RADIUS server.
Authenticating Admin Accounts Using Active Directory
Active Directory (AD) is a distributed directory service that is a repository for user information. The NIOS appliance
can authenticate admin accounts by verifying user names and passwords against Active Directory. If the admin does
not exist on the AD domain controller, or if the user name and password do not match entries on the domain
controller, the NIOS appliance denies access to the admin. However, if the NIOS appliance verifies the user name and
password successfully, it grants access. In addition, the NIOS appliance queries the AD domain controller for the
group membership information of the admin. The appliance matches the group names from the domain controller
with the admin groups on its local database. It then authorizes services and grants the admin privileges, based upon
the matching admin group on the appliance.
You must be logged in to the NIOS appliance as a superuser to configure the AD authentication service. Figure 3.9
illustrates the Active Directory authentication process.
Figure 3.9 Authentication Using a Domain Controller
1
3
2
4a
4b
A user makes an HTTPS connection to
the NIOS appliance and sends an
account name and password.
The appliance checks the remote admin
authentication policy to determine which
method to use to authenticate the user.
The authentication policy selects AD
authentication as the first method to use.
The appliance sends a request to the
domain controller within the network to
authenticate the admin. The appliance
also requests the admins group
membership information.
The appliance lets the user log in and
applies the authorization profile.
The appliance grants all permissions
specific to the administrator based on
the group membership sent from the
domain controller associated with the
admin account. If there is no group
membership information for the admin,
the default group is assigned (if
configured).
Authentication is successful. The
domain controller successfully
authenticates the admin user. The
group membership information for the
administrator is sent to the appliance.
The first group in the group list
matching the groups returned by the
domain controller is assigned to the
admin, along with the associated
permissions after that admin logs in.
The appliance does not allow the user
to log in.
Authentication is unsuccessful. The
domain controller sends back a deny
access result to the appliance. No
group membership information is sent.
Administrator
NIOS Appliance Domain Controller
Authenticating Admin Accounts Using Active Directory
Admin Authentication Using Active Directory
To configure the NIOS appliance to authenticate admins using Active Directory, you must first configure user accounts
on the domain controller. Then, on the NIOS appliance, do the following:
Configure an AD authentication service on the appliance and configure one or more AD domain controllers to
contact. For information about configuring AD authentication service for admins, see Admin Authentication
Using Active Directory on page 111.
If you configured admin groups on the AD controller, you can create those same groups on the NIOS appliance
and specify their privileges and settings. Note that the admin group names must match those on the AD domain
controller. You can specify a default group as well. The NIOS appliance assigns admins to the default group if
none of the admin groups on the NIOS appliance match the admin groups on the AD domain controller or if
there are no other admin groups configured. For information about configuring group permissions and
privileges, see About Admin Groups on page 69.
Enable Active Directory authentication by adding Active Directory to the list of authentication methods in the
admin policy. The appliance refers to this list in the admin policy to determine which authentication method to
use and in what order. See Defining the Admin Policy on page 112 for more information about configuring
admin policy.
Configuring Active Directory Authentication for Admins
To configure an Active Directory authentication service on the NIOS appliance:
1. From the Administrators perspective, click + (for Remote Admins) -> AD Authentication Services -> Edit -> Add AD
Authentication Service.
2. In the AD Authentication Service Services editor, enter the following:
Name: Enter a name for the service.
Port: Enter the port number on the domain controller to which the appliance sends authentication
requests.
Transport Encryption: Select SSL to transmit through an SSL (Secure Sockets Layer) tunnel. Infoblox
strongly recommends that you select this option to ensure the security of all communications between the
NIOS appliance and the AD server. If you select this option, you must upload a CA certificate from the AD
server. For information about uploading a CA certificate, see Uploading Certificates to the Appliance on
page 627.
Comment: Enter pertinent information about the service.
Disable this AD authentication service: Select this check box to retain an inactive AD service profile.
AD Domain: Enter the DNS style name of the domain in which the user credentials are located.
AD Domain Controller Failover List: Enter the IP address of the domain controller to which the appliance
connects. You can add multiple domain controllers for failover purposes. The NIOS appliance tries to
connect with the first domain controllers on the list. If it is unable to connect, it tries the next domain
controllers on the list, and so on. You can change the order in which the servers are listed by selecting a
server and clicking Move up or Move down.
Timeout: The number of seconds that the NIOS appliance waits for a response from the specified
authentication server.
Defining the Admin Policy
After you configure the properties of each authentication service you want to use, you must then define the admin
policy. The admin policy defines which authentication methods to use, and in what order. In addition, it lists admin
groups for remote admins. You must define at least one admin group for remote admins. The admin group determines
the privileges of the admin account.
Specifying a List of Remote Admin Groups
You can configure a list of admin groups for remote admins, and prioritize each group by moving them up or down
within the list. When the appliance receives information that the admin belongs to one or more groups, the appliance
selects the first group in the list that matches, and assigns that group to the admin. If no groups are returned by the
domain controller or the RADIUS server, the default group is assigned (if specified). To configure the remote admin
group list:
1. From the Administrators perspective, click + (for Remote Admins) -> click + (for Admin Policy) -> Policy
Configuration -> Edit -> Remote Admin Policy Properties. The Policy Configuration editor appears.
2. From the Remote Admin Group Ordering section, click Add to open up the Select Admin Group dialog box and to
add an admin group to the list.
3. Select an admin group from the Select Admin Group dialog box and click OK to add it to the list.
4. Select an admin group from the Remote Admin Group Ordering section and click Move down to move the group
down in the ordering within the list. Select an admin group from the Remote Admin Group Ordering section and
click Move up to move the group up in the ordering within the list.
Configuring the Default Admin Group
You can designate an admin group as the default group. The appliance assigns an admin to the default group if no
other admin groups are defined or if it does not find a matching admin group. Note that the NIOS appliance denies
access to admins if there is no matching admin group to assign and no default group configured. Even though the
authentication is successful, the NIOS appliance denies access to the remote admin because there is no group to
assign to the admin and therefore no permissions defined for the user.
To configure the default admin group:
2. Click Select Default Group to open up the Select Admin Default Group dialog box.
3. Select an admin group from the Select Admin Default Group dialog box to act as the default. Click OK. The Default
Group Name field displays the selection you made.
Changing Password Length Requirements
Configuring a List of Authentication Methods
You can configure a list of authentication methods, and prioritize each method within the list. The appliance uses the
first method on the list. If unsuccessful, the appliance uses the next method on the list. Each authentication method
within the list is used in order as they appear.
To configure a list of authentication methods for remote admins:
2. From the Admin Authentication section, click Add to open up the Select Admin Authentication Method dialog box
and to add an authentication method to the list.
3. Select an authentication method from the Select Admin Authentication Method dialog box and click OK to add it
to the list.
4. Select an authentication method from the Admin Authentication section and click Move down to move the
method down in the ordering within the list. Select an authentication method from the Admin Authentication
section and click Move up to move the method up in the ordering within the list. The first method within the list
is used first.
Changing Password Length Requirements
Password length requirements control how long a password must be for a NIOS appliance admin account. Increasing
this value reduces the likelihood of hackers gaining unauthorized access.
To change password length requirements:
or
2. In the Grid (or Device) editor, click Security.
3. Enter a number from 4 to 64 in the Minimum Password Length field.
Notifying Administrators
You can notify individual administrators about system status via e-mail, or notify a group of people using an alias
e-mail address. If you have configured DNS resolution on your network, the E-mail relay configuration function is not
required. If you did not configure the settings on the DNS Resolver section, you must enter a static IP address of the
target system in the Relay Name/IP Address field. Use the Test e-mail settings button to test the E-mail settings and
to verify that the recipient received the notification. In addition, the appliance sends e-mail to administrators when
certain events occur. Here is a list of events that trigger e-mail notifications:
Changes to link status on ports and online/offline replication status
Events that generate traps, except for upgrade failures (ibUpgradeFailure). For a list of events, see Infoblox MIBs
on page 179
You can define the e-mail settings at the grid and member levels.
Grid Level
To notify an administrator of an independent appliance or a grid:
or
2. In the Grid (or Device) editor, click Email, and then enter the following:
Enable e-mail notification: Select this check box.
E-mail address: Enter the e-mail address of the administrator. Use an e-mail alias to notify multiple people.
Use e-mail relay: Select this check box if the NIOS appliance must send e-mail to an intermediary SMTP
(Simple Mail Transfer Protocol) server that relays it to the SMTP server responsible for the domain name
specified in the e-mail address. Some SMTP servers only accept e-mail from certain other SMTP servers and
might not allow e-mail from the NIOS appliance. In this case, specify the DNS name or IP address of a
different SMTP server that does accept e-mail from the NIOS appliance and that will then relay it to the
SMTP server that can deliver it to its destination.
Clear this check box if it is unnecessary to use an e-mail relay server.
Relay Name/IP Address: If you have configured DNS resolution, enter the DNS name of the relay server.
If DNS resolution is not configured, enter the IP address of the relay server.
3. Optionally, click Test e-mail settings to confirm this feature is operating properly.
Member Level
To define e-mail settings for a member, follow the navigational path below and override the grid-level settings. Click
the Save icon to save your changes.
From the Grid perspective, click Grid -> + (for grid) -> + (for Members) -> member -> Edit -> Member Properties ->
Email.

Chapter 4 Managing Appliance Operations
Managing the operations of a NIOS appliance involves defining system parameters such as time, security and port
settings. This chapter describes how to set these operational parameters and how to set up a static route when the
NIOS appliance can send and receive traffic through multiple gateways. The tasks covered in this chapter include:
Managing Time Settings on page 117
Changing Time and Date Settings on page 117
Changing Time Zone Settings on page 117
Monitoring Time Services on page 118
Using NTP for Time Settings on page 119
Authenticating NTP on page 120
NIOS Appliance as NTP Client on page 122
NIOS Appliance as NTP Server on page 125
Managing Security Operations on page 128
Enabling Support Access on page 128
Enabling Remote Console Access on page 128
Permanently Disabling Remote Console and Support Access on page 129
Restricting HTTP Access on page 129
Enabling HTTP Redirection on page 130
Modifying GUI Session Timeout Settings on page 130
Disabling the LCD Input Buttons on page 130
Modifying Security for a Grid Member on page 131
Ethernet Port Usage on page 132
Modifying Ethernet Port Settings on page 135
Using the MGMT Port on page 136
Appliance Management on page 137
Grid Communications on page 139
DNS Services on page 142
Setting Static Routes on page 144
Enabling DNS Resolution on page 147
Managing Licenses on page 148
Viewing the Installed Licenses on a NIOS Appliance on page 148
Obtaining a 60-Day Temporary License on page 148
Managing Appliance Operations
Obtaining and Adding a License on page 149
Removing Licenses on page 149
Shutting Down, Rebooting, and Resetting a NIOS Appliance on page 151
Rebooting a NIOS Appliance on page 151
Shutting Down a NIOS Appliance on page 151
Resetting a NIOS Appliance on page 151
Managing the Disk Subsystem on the Infoblox-2000 on page 153
About RAID 10 on page 153
Evaluating the Status of the Disk Subsystem on page 154
Replacing a Failed Disk Drive on page 154
Disk Array Guidelines on page 155
Restarting Services on page 156
Managing Time Settings
Managing Time Settings
You can define the date and time settings for your NIOS appliance when it first starts, using the Infoblox Appliance
Startup Wizard. Alternatively, you can set the date and time of the appliance anytime after you first configure it if you
did not do so using the startup wizard or if you need to change it if, for example, you move an appliance from a
location in one time zone to a location in a different time zone. To set the date and time of the appliance, you can
either manually enter the values or configure the appliance to synchronize its time with a public NTP server.
Changing Time and Date Settings
You can set the date and time on grid members and on independent appliances or HA pairs. For appliances in a grid,
you can set the date and time at the grid level and at the member level. Grid-level date and time settings apply to all
members unless you override them at the member level.
Note: You cannot manually set the date and time if you have previously enabled NTP service.
To change the time and date for a grid or for an independent appliance or HA pair:
1. From the Grid or Device perspective, click Grid (or Device) -> Set Date and Time.
2. In the Date and Time dialog box, enter the date (in MM/DD/YYYY format) and time (in HH:MM format) in the
appropriate fields. For PM hours, use the integers 13-24.
3. To close the Date and Time dialog box, click OK.
To change the time and date for a grid member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Grid -> Set Date and Time.
2. In the Date and Time dialog box, enter the date (in MM/DD/YYYY format) and time (in HH:MM format) in the
appropriate fields. For PM hours, use the integers 13-24.
3. To close the Date and Time dialog box, click OK.
Note: Changing the date and time resets the application and terminates the management session.
Changing Time Zone Settings
Whether you enable NTP (Network Time Protocol) or manually configure the date and time, you must always set the
time zone manually. For a grid, you can set the time zone at the grid level, which then applies to all members. If
different members are in different time zones, you can choose the time zone that applies to most members at the grid
level, and then override the setting at the member level for the remaining members.
Note: Changing the time zone does not reset the application nor does it terminate the management session.
To change the time and date for a grid or for an independent appliance or HA pair:
1. From the Grid or Device perspective, click Grid (or Device) -> Set Time Zone.
2. Choose an appropriate time zone from the drop-down list, and then click OK.
To change the time zone for a grid member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Grid -> Set Member Time Zone.
2. In the Member Time Zone dialog box, enter the following:
Override Grid Time Zone: Select this check box.
Member Time Zone: Choose an appropriate time zone for the location of the selected member.
3. To close the Member Time Zone dialog box, click OK.
Monitoring Time Services
You can monitor the internal NTP daemon that runs within a grid to ensure the time among its members is
synchronized, and if you configure the appliance as an NTP server for external clients, you can monitor this service
as well.
In a grid, the grid master and its members use an internal NTP daemon to synchronize their time. It is not
user-configurable and functions regardless of how you set the time on the grid master. You can monitor this internal
NTP service by checking the status icon and corresponding description in the Detailed Status panel. To display the
Detailed Status panel, from the Grid perspective, click View -> Detailed Status. Following is a description of the NTP
status icons in the Detailed Status panel:
When you set the time on a grid master or independent appliance by configuring it to synchronize its time with an NTP
server, the independent appliance and the grid master and its members can function as NTP servers as well. For
information, see Using NTP for Time Settings on page 119. When you enable NIOS appliances as NTP servers, you
can monitor the status of the NTP service by checking the NTP status icons in the Grid panel. Following is a description
of the NTP status icons in the Grid panel:
Icon Color Meaning
Green NTP is running properly.
Yellow The NIOS appliance is synchronizing its time.
Red The NTP service is not running properly. View the corresponding description for additional
information.
Icon Color Meaning
Green NTP is enabled and running properly.
Yellow The NTP service is enabled and the NIOS appliance is synchronizing its time.
Red The NTP service is enabled, but is not running properly on the NIOS appliance. You can check
the syslog messages for additional information.
Gray The NTP service is disabled.
Using NTP for Time Settings
NTP (Network Time Protocol) is a standard protocol that system clocks use to ensure their time is always accurate.
Appliances that use NTP try to get their time as close as possible to UTC (Coordinated Universal Time), the standard
timescale used worldwide. NTP uses UDP (User Datagram Protocol) on port 123 for communications between clients
and servers.
NTP is based on a hierarchy where reference clocks are at the top. Reference clocks use different methods such as
special receivers or satellite systems to synchronize their time to UTC. NTP servers on the first level of the hierarchy
synchronize their time with the reference clocks, and serve time to clients as well. Each level in the hierarchy is a
stratum; stratum-0 is a reference clock. Stratum-1 servers synchronize their clocks with reference clocks. Stratum-2
servers synchronize their clocks with stratum-1 servers, and so forth. The stratum number indicates the number of
levels between the NTP server and the reference clock. A higher stratum number could indicate more variance
between the NTP server and the reference clock.
You can configure a NIOS appliance to function as an NTP client that synchronizes its clock with an NTP server. NTP
clients typically use time information from at least three different sources to ensure reliability and a high degree of
accuracy. There are a number of public NTP servers on the Internet with which the NIOS appliance can synchronize
its clock. For a list of these servers, you can access http://www.ntp.org.
An independent appliance can also function as an NTP server that provides time to client appliances. In a grid, the
grid master can function as an NTP client, synchronizing its time with an external NTP server. The grid master then
automatically functions as an NTP server to the grid members. The grid members, in turn, can function as NTP servers
for other appliances in the network. This allows you to deploy multiple NTP servers to ensure accurate and reliable
time across the network.
Figure 4.1 Infoblox Appliances as NTP Servers
Internet
Stratum-1 NTP Servers use reference
clocks to synchronize their time to
UTC (Coordinated Universal Time).
As an NTP client, the grid master
synchronizes its time with stratum-1
NTP servers. The grid master also
functions as a stratum-2 NTP server
to grid members. NTP messages
between the grid master and grid
members go through encrypted VPN
tunnels.
As NTP clients, the grid members
synchronize their clocks with the grid
master. The grid members also
function as stratum-3 NTP servers to
external devices on their networks.
Reference Clocks
Stratum-1 NTP Servers
Grid
Member
Grid Master
2 Network
Grid
Member
1 Network
VPN
Tunnel
Authenticating NTP
To prevent intruders from interfering with the time services on your network, you can authenticate communications
between a NIOS appliance and a public NTP server, and between a NIOS appliance and external NTP clients. NTP
communications within the grid go through an encrypted VPN tunnel, so you do not have to enable authentication
between members in a grid.
NTP uses symmetric key cryptography, where the server and the client use the same algorithm and key to calculate
and verify a MAC (message authentication code). The MAC is a digital thumbprint of the message that the receiver
uses to verify the authenticity of a message.
As shown in Figure 4.2, the NTP client administrator must first obtain the secret key information from the
administrator of the NTP server. The server and the client must have the same key ID and data. Therefore, when you
configure the NIOS appliance as an NTP client and want to use authentication, you must obtain the key information
from the administrator of the external NTP server and enter the information on the NIOS appliance. When you
configure a NIOS appliance as an NTP server, you must create a key and send the key information to clients in a secure
manner. A key consists of the following:
Key Number: A positive integer that identifies the key.
Key Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication code)
of a message.
M: The key is a 1-31 character ASCII string using MD5 (Message Digest).
S: The key is a 64-bit hexadecimal number in DES (Data Encryption Standard) format. The high order 7 bits
of each octet form the 56-bit key, and the low order bit of each octet is given a value so that the octet
maintains odd parity. You must specify leading zeros so the key is exactly 16 hexadecimal digits long and
maintains odd parity.
A: The key is a DES key written as a 1-8 character ASCII string.
N: The key is a 64-bit hexadecimal number in NTP format. It is the same as the S format, but the bits in each
octet have been rotated one bit right so the parity bit is in the high order bit of the octet. You must specify
leading zeros and odd parity must be maintained.
Key String: The key data used to calculate the MAC. The format depends on the Key Type you select.
When the NTP client initiates a request for time services to the NTP server, it creates the MAC by using the agreed
upon algorithm to compress the message and then encrypts the compressed message (which is also called a
message digest) with the secret key. The client appends the MAC to the message it sends to the NTP server. When the
NTP server receives the message from the client, it performs the same procedure on the message it compresses
the message it received, encrypts it with the secret key and generates the MAC. It then compares the MAC it created
with the MAC it received. If they match, the server continues to process and respond to the message. If the MACs do
not match, the receiver drops the message.
Figure 4.2 NTP Client Administrator Obtaining Secret Key from NTP Server Administrator
+
NTP Server
Administrator
NTP Client
Administrator
Secret Key
Information
MD5 or DES
Message Digest
Encrypted with
Secret Key
MD5 or DES
Message Digest
Encrypted with
Secret Key
NTP Client
MAC
Message Message
MAC MAC
NTP server administrator sends the secret key
information to the NTP client administrator, who
adds the key to the NTP client.
When the NTP client sends a request for time
services to the NTP server, it uses the agreed
upon algorithm and secret key to create the MAC
(message authorization code). It then sends the
MAC and message to the NTP server.
NTP server uses the agreed upon
algorithm and secret key to create the
MAC. It compares this MAC with the MAC
it received. If they match, the server
responds to the request of the client for
time services. If the MACs do not match,
the server ignores the message from the
client.
NIOS Appliance as NTP Client
You can configure an independent NIOS appliance or the grid master in a grid as an NTP client that synchronizes its
system clock time with an external NTP server.
When you enable a NIOS appliance to function as an NTP client, you must specify at least one NTP server with which
the appliance can synchronize its clock. If you specify multiple NTP servers, you should specify servers that
synchronize their time with different reference clocks and that have different network paths. This increases stability
and reduces risk in case a server fails. For a list of public NTP servers, you can access www.ntp.org.
When you specify multiple NTP servers, the NTP daemon on the appliance determines the best source of time by
calculating round-trip time, network delay, and other factors that affect the accuracy of the time. NTP periodically
polls the servers and adjusts the time on the appliance until it matches the best source of time. If the difference
between the appliance and the server is less than five minutes, the appliance adjusts the time gradually until the
clock time matches the NTP server. If the difference in time is more than five minutes, the appliance immediately
synchronizes its time to match that of the NTP server.
To secure communications between a NIOS appliance and an NTP server, you can authenticate communications
between the appliance and the server. When you configure authentication, you must obtain the key information from
the administrator of the NTP server and enter the key on the appliance. For more information, see Authenticating NTP
on page 120.
For appliances in a grid, only the grid master can synchronize its clock with an external NTP server. When you enable
NTP on the grid master in a grid, the grid master automatically functions as an NTP server to the grid members. A grid
member can synchronize its time only with the grid master, and not with an external NTP server or another grid
member. Like all other grid communications, the grid master and its members send NTP messages through an
encrypted VPN tunnel.
Figure 4.3 Grid Master as NTP Client
Grid Master
Grid Member
VPN Tunnels
NTP Server 1 NTP Server 2 NTP Server 3
The grid master uses three public NTP
servers to calibrate its clock to the correct
time. It uses symmetric key cryptography to
authenticate NTP messages.
The grid master serves time to the grid
members. All NTP communications with
the grid go through encrypted VPN tunnels.
Grid Member
Secret Keys
Internet
Following are the tasks to configure an independent NIOS appliance or a grid master as an NTP client:
Enable NTP
Specify one or more NTP servers
Optionally, enable authentication between the appliance and the NTP server. For more information, see Grid
Members as NTP Servers on page 125.
Configuring a NIOS Appliance as an NTP Client
In a grid, the grid master communicates directly with an external NTP server from which it receives its date and time.
The master then forwards the date and time to the other grid members. Likewise, in an independent HA pair, the
active node communicates directly with an external NTP server. The passive node then synchronizes its clock with the
active node.
To configure a grid master or independent NIOS appliance or HA pair to synchronize its time with an external NTP
server:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent NIOS appliance or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit
-> Service Properties.
2. In the NTP Properties editor, select Enable NTP.
3. To define external NTP servers, click Add in the External NTP Servers section.
4. In the NTP External Server dialog box, enter the following information, and then click OK.
NTP Server Address: You can enter either the IP address or the resolvable host name of an NTP server. You
can view a list of NTP servers at ntp.isc.org. To check whether the DNS server can resolve the NTP server
host name, click Resolve.
Enable Authentication: Select the check box to enable authentication of NTP communications between the
external NTP server and the NIOS appliance (grid master, active node in an independent HA pair, or single
independent NIOS appliance).
Note: To prevent intruders from interfering with the time services on your network, you can authenticate
communications between a grid master and external NTP servers, and between grid members and
external NTP clients. NTP communications within the grid go through an encrypted VPN tunnel, so you do
not have to enable authentication between grid master and members.
Authentication Key: Click Select Key to open the Select NTP Authentication Key dialog box, select a key that
you previously entered in the NTP Authentication Keys section (see below), and then click OK.
5. Click the Save and Restart Services icons.
Managing External NTP Servers
You can specify multiple NTP servers for failover purposes. The NIOS appliance attempts to connect to the NTP servers
in the order in which they are listed. You can change the order of the list by selecting an NTP server and using the
Move Up and Move Down buttons. You can add and delete servers and modify their information as well.
Entering an NTP Authentication Key
To add an NTP authentication key:
or
For an independent NIOS appliance or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit
-> Service Properties.
2. In the NTP Properties editor, select Enable NTP.
3. To enter a new key, click Add in the NTP Authentication Keys section.
4. In the NTP Authentication Key dialog box, enter the following information.
Number: A positive integer that identifies a key.
Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication code)
of a message.
MD5 in ASCII format (M): The key is a 1-31 character ASCII string using MD5 (Message Digest).
DES in hex format (S): The key is a 64-bit hexadecimal number in DES (Data Encryption Standard)
format. The high order 7 bits of each octet form the 56-bit key, and the low order bit of each octet is
given a value so that the octet maintains odd parity. You must specify leading zeros so the key is
exactly 16 hexadecimal digits long and maintains odd parity.
DES in ASCII format (A): The key is a DES key written as a 1-8 character ASCII string.
DES in NTP format (N): The key is a 64-bit hexadecimal number in NTP format. It is the same as the S
format, but the bits in each octet have been rotated one bit right so the parity bit is in the high order bit
of the octet. You must specify leading zeros and odd parity must be maintained.
String: The key data used to calculate the MAC. The format depends on the Key Type you select.
5. Click OK to close the NTP Authentication Key dialog box.
Note that if you entered a new key, the appliance checks if the key already exists in the key list. If the key does
exist, but either the key type or key string does not match, the NIOS appliance sends an error message.
Managing Authentication Keys
After you enter an authentication key, you can modify or delete it. Note that you cannot delete a key that an NTP server
references. You must first delete all NTP servers that reference that key and then delete the key.
To delete a key from the list:
or
For an independent appliance or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit ->
Service Properties.
2. In the NTP Properties editor, select the key you want to delete from the NTP Authentication Keys list, and then
click Delete.
NIOS Appliance as NTP Server
After you enable NTP on a grid, the grid membersincluding the grid mastercan function as NTP servers to clients
in different segments of the network. Similarly, after you enable NTP on an independent appliance or HA pair and it
synchronizes its time with an NTP server, you can configure it to function as an NTP server as well.
Figure 4.4 Grid Members as NTP Servers
Following are the tasks to configure a NIOS appliance as an NTP server:
Enable the appliance as an NTP server.
Optionally, enable authentication between the appliance and its NTP clients.
Specify which clients can access the NTP service of the appliance.
Optionally, specify which clients can use ntpq to query the appliance.
X
Grid Master
Grid Member
VPN
Tunnels
Grid Member
The grid master uses three public NTP
servers to calibrate its clock to the
correct time. It uses symmetric key
cryptography to secure NTP messages.
The grid master serves time to the grid
members. All NTP communications
with the grid go through the encrypted
VPN tunnels.
Secret Keys
The grid members serve time to devices on their
networks. Each member uses symmetric key
encryption to secure NTP messages. Each
member also has an access control list that
defines which appliances can access the time
services. When a client that is not on the list tries
to access an appliance functioning as an NTP
server, the appliance ignores the message.
Internet
NTP Server 1 NTP Server 2 NTP Server 3
3 Network 2 Network
Access Control List
Configuring a NIOS Appliance as an NTP Server
You can configure a grid memberincluding the grid masteror an independent appliance or HA pair to function as
an NTP server. When you enable a NIOS appliance to function as an NTP server, you can enable authentication
between a NIOS appliance functioning as an NTP server and its NTP clients. When you enable authentication, you
must specify the keys that the appliance and its clients must use for authentication. In a grid, you can enter NTP
authentication keys at the grid level so that all the members can use them to authenticate their clients. You can also
enter keys at the member level, if you want that member to use different keys from those set at the grid level. After
you enter the keys, you can download the key file and distribute the file to the NTP clients.
To authenticate NTP traffic between a NIOS appliance and NTP clients:
1. Define one or more keys at the grid or member level, or for an independent appliance or HA pair.
2. Distribute the key to the NTP clients.
To enable a appliance as an NTP server and add a new authentication key:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Members ) -> + (for hostname ) -> NTP -> Edit -> Service
Properties.
or
Service Properties.
2. In the Member NTP Properties editor, do the following:
Enable this member as an NTP server: Select this check box.
Enable Authentication: Select the check box to enable authentication of NTP communications between the
external NTP server and the NIOS appliance.
Override Grid NTP authentication setting: Select this check box to enter NTP authentication keys at the
member level instead of using grid-level keys. The member uses these keys when acting as an NTP server
and authenticates requests from NTP clients. Clear the check box to use the grid-level authentication keys.
3. Click Add (for NTP Authentication Keys), enter the following information, and then click OK.
Number: A positive integer that identifies a key.
Key Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication
code) of a message.
MD5 in ASCII format (M): The key is a 1-31 character ASCII string using MD5 (Message Digest).
DES in hex format (S): The key is a 64-bit hexadecimal number in DES (Data Encryption Standard)
format. The high order 7 bits of each octet form the 56-bit key, and the low order bit of each octet is
given a value so that the octet maintains odd parity. You must specify leading zeros so the key is
exactly 16 hexadecimal digits long and maintains odd parity.
DES in ASCII format (A): The key is a DES key written as a 1-8 character ASCII string.
DES in NTP format (N): The key is a 64-bit hexadecimal number in NTP format. It is the same as the S
format, but the bits in each octet have been rotated one bit right so the parity bit is in the high order bit
of the octet. You must specify leading zeros and odd parity must be maintained.
String: The key data used to calculate the MAC. The format depends on the Key Type you select.
You can download the key file, which is usually called ntp.keys, and distribute the file to the NTP clients. To download
a key file at the grid or independent appliance level:
To copy an NTP authentication key for distribution to NTP clients:
or
Service Properties.
2. Choose the key in the NTP Authentication Keys list, and then click Modify.
3. Note the key number and type, and select the contents of the String field.Paste the key string in a text file and
include the key number and type (M, S, A, or N) in the file.
4. Distribute this to the NTP clients using a secure transport.
Defining Access Control
The NTP access control list specifies which clients can use a NIOS appliance as an NTP server. If you do not use the
access control list, then the NIOS appliance does not allow access to its NTP service.
To specify which clients can access the NTP service of a NIOS appliance:
or
Service Properties.
2. Click Add in the NTP Access Control section.
3. In the Add Access Range dialog box, enter the following information, and then click OK.
IP Address Option
Address: To allow a client from a single IP address to use the NTP service of an appliance, select this
option and enter the IP address in the Address field.
or
Network: To allow clients from a subnet to use the NTP service of an appliance, select this option and
enter the network address in the Address field and choose an appropriate netmask from the drop-down
list.
or
Any: To allow clients from any address to use the NTP service of an appliance, select this option.
Defining Query Access Control
The NIOS appliance can accept queries from clients using ntpq, the standard utility program used to query NTP
servers about their status and operational parameters. The NTP query access control list specifies from which clients
the NIOS appliance is allowed to accept ntpq queries. If you do not use this list, then the appliance does not accept
ntpq queries from any client.
To specify from which clients a NIOS appliance can accept ntpq queries:
or
Service Properties.
2. Click Add in the NTP Query Access Control section.
3. In the Add NTP Query Client dialog box, enter the following information, and then click OK.
IP Address Option
Address: To accept ntpq queries from specific clients, select this option and enter the IP address in the
Address field.
or
Network: To accept ntpq queries from a subnet, select this option and enter the network address in the
Address field and choose an appropriate netmask from the drop-down list.
or
Any: Select this option to accept ntpq queries from any address.
Managing Security Operations
The procedures in this section apply to both independent and grid installations.
You can specify these security operations:
Enabling Support Access on page 128
Enabling Remote Console Access on page 128
Permanently Disabling Remote Console and Support Access on page 129
Restricting HTTP Access on page 129
Enabling HTTP Redirection on page 130
Modifying GUI Session Timeout Settings on page 130
Disabling the LCD Input Buttons on page 130
Modifying Security for a Grid Member on page 131
Enabling Support Access
Infoblox Technical Support might need access to your NIOS appliance to troubleshoot problems. This function
enables an SSH (Secure Shell) daemon that only Infoblox Technical Support can access. If you have any questions,
contact Infoblox Technical Support at support@infoblox.com. By default, this option is disabled.
To enable Infoblox Technical Support access:
or
2. In the Grid (or Device) editor, click Security, and then select Enable Support access.
Note: When configuring grid members, you can selectively override the grid-level Support access setting at the
member level.
Enabling Remote Console Access
This function makes it possible for a superuser admin to access the Infoblox CLI from a remote location using an SSH
(Secure Shell) v2 client. The management system must have an SSH v2 client to use this function. After opening a
remote console connection using an SSH client, log in using a superuser name and password. By default, this option
is disabled.
To enable remote console access:
or
2. In the Grid (or Device) editor, click Security, and then select Enable remote console access.
Note: When configuring grid members, you can selectively override the grid-level remote console access setting at
the member level.
Permanently Disabling Remote Console and Support Access
You can permanently disable remote console (Secure Shell v2) access for appliance administration and for Infoblox
Technical Support to perform remote troubleshooting. Disabling this type of access might be required in a
high-security environment.
WARNING: After permanently disabling remote console and support access, you cannot re-enable them! Not
even resetting an appliance to its factory default settings can re-enable them.
To permanently disable remote console access and Infoblox Technical Support access:
or
2. In the Grid (or Device) editor, click Security, and then select Permanently disable remote console and support
access.
Restricting HTTP Access
You can specify the IP addresses from which administrators are allowed to access the NIOS appliance. When the NIOS
appliance receives a connection request, it tries to match the source IP address in the request with IP addresses in
the list. If there is at least one item in the HTTP Access Control list and the source IP address in the request does not
match it, the NIOS appliance ignores the request.
Caution: If you specify an address or network other than the one from which you are currently accessing the
appliance, when you save your configuration, you will lose your administrative session and be unable to
reconnect.
To restrict HTTP access to the Infoblox GUI to select addresses:
or
2. To set restrictions on the IP addresses from which administrators can access the NIOS appliance, select Enable
HTTP access restrictions in the Security section, click Add, enter the following, and then click OK:
Address Type:
Address: To allow administrative access to the GUI from a single IP address, select this option and enter
the IP address in the Address field. Note that if you specify an address other than the one from which
you are currently accessing the appliance, when you save your configuration, you will lose your
administrative session and be unable to reconnect.
Network: To restrict administrative access to the GUI to a subnet, select this option and enter the
network address in the Address field and choose an appropriate netmask from the drop-down list. Note
that if you specify a subnet other than the one from which you are currently accessing the appliance,
when you save your configuration, you will lose your administrative session and be unable to
reconnect.
The application restarts and your management session terminates.
4. From the JWS (Java Web Start) login prompt, log back in to the appliance.
Enabling HTTP Redirection
You can enable the NIOS appliance to redirect administrative connection requests using HTTP to the secure HTTPS
protocol. When you disable redirection, the NIOS appliance ignores any administrative connection requests not using
HTTPS. By default, the NIOS appliance does not redirect HTTP connection requests to HTTPS.
To enable redirection:
or
2. In the Grid (or Device) editor, click Security, and then select Auto-Redirect HTTP -> HTTPS.
The application restarts and your management session terminates.
4. From the JWS (Java Web Start) login prompt, log back in to the appliance.
Modifying GUI Session Timeout Settings
You can set the length of idle time before an administrative session to the Infoblox GUI times out. The default timeout
value is 600 seconds (10 minutes).
Note: If you change Session Timeout settings, you must log out of the session by selecting File -> Logout, and log
back in. The setting takes effect only after you log out and log back in.
To modify session timeout settings:
or
2. Click Security n the Grid (or Device) editor and enter a number between 60 and 31536000 seconds (one minute
one year) in the Session Timeout field. The default session timeout is 600 seconds (10 minutes).
4. Select File -> Logout to log out of the GUI.
5. Log back into the GUI to apply the new timeout value to the session.
The GUI tracks mouse and keyboard activity. If there is no activity for the specified timeout interval, the
appliance displays a message that the timeout has occurred. Click OK to restart the GUI.
Disabling the LCD Input Buttons
By default, the LCD input function is enabled, which allows you to use the LCD buttons on the front panel of a NIOS
appliance to change the IP address settings of the LAN port. You can disable this function if the appliance is in a
location where you cannot restrict access exclusively to NIOS appliance administrators and you do not want anyone
to be able to make changes through the LCD.
To disable LCD input to the appliance:
or
2. In the Grid (or Device) editor, click Security, and then clear Enable LCD input.
Modifying Security for a Grid Member
You can override a number of grid-level security settings at the member level.
Note: You can only manage session timeout settings, HTTPS redirection, HTTP access, audit log rolling, password
length, and login banner text at the grid level.
To enable support access for a member:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Member Properties.
2. In the Grid (or Device) editor, click Security, and then enter the following:
To override grid-level settings for remote console access, select the Override grid remote console access
setting check box, and then select or clear the Remote console access enabled check box.
To override grid-level settings for Infoblox Technical Support access, select the Override grid support access
setting check box, and then select or clear the Enable support access check box.
To override grid-level LCD input settings, select the Override grid support LCD input setting check box, and
then select or clear the Enable LCD input check box.
Ethernet Port Usage
The three Ethernet ports on a NIOS appliance perform different functions, which vary depending on deployment and
configuration choices. The three Ethernet ports that transmit and receive traffic to the NIOS appliance are as follows:
LAN port This is the default port for single independent appliances, single grid members, and passive nodes
in HA pairs. All deployments use the LAN port for management services if the MGMT port is disabled. On
Infoblox-500, -1000, and -1200 appliances, this port is labeled LAN. On Infoblox-550, -1050, -1550, and -1552
appliances, it is labeled LAN1. (The LAN2 port is reserved for future use.)
HA port This is the default port for the active grid master node and the active node in an independent HA pair.
MGMT port If the MGMT port is enabled, the NIOS appliance uses it for many types of management services
(see Table 4.2 on page 133 for specific types).
Table 4.1 displays the type of traffic per port for both grid and independent deployments. For a more detailed list of
the different types of traffic, see Table 4.2 on page 133.
Table 4.1 Appliance Roles and Configuration, Communication Types, and Port Usage
To see the service port numbers and the source and destination locations for traffic that can go to and from a NIOS
appliance, see Table 4.2. This information is particularly useful for firewall administrators so that they can set policies
to allow traffic to pass through the firewall as required.
Note: The colors in both tables represent a particular type of traffic and correlate with each other.
Appliance Role HA Pair HA Status MGMT Port
Database
Synchronization
Network
Identity
Services
Management
Services
GUI
Access
HA Grid Master Yes Active Disabled VIP on HA VIP on HA LAN VIP on HA
HA Grid Master Yes Passive Disabled LAN LAN
Single Grid Master No Disabled LAN LAN LAN LAN
HA Grid Member Yes Active Disabled LAN VIP on HA LAN
HA Grid Member Yes Passive Disabled LAN LAN
Single Grid Member No Disabled LAN LAN LAN
Independent HA Pair Yes Active Disabled VIP on HA VIP on HA LAN VIP on HA
Independent HA Pair Yes Passive Disabled LAN LAN
Single Independent No Disabled LAN LAN LAN
HA Grid Master Yes Active Enabled VIP on HA VIP on HA MGMT MGMT
HA Grid Master Yes Passive Enabled LAN MGMT
Single Grid Master No Enabled LAN LAN or MGMT MGMT MGMT
HA Grid Member Yes Active Enabled LAN or MGMT VIP on HA MGMT
HA Grid Member Yes Passive Enabled LAN or MGMT MGMT
Single Grid Member No Enabled LAN or MGMT LAN or MGMT MGMT
Independent HA Pair Yes Active Enabled VIP on HA VIP on HA MGMT MGMT
Independent HA Pair Yes Passive Enabled LAN MGMT
Single Independent No Enabled LAN or MGMT MGMT MGMT
Ethernet Port Usage
Table 4.2 Sources and Destinations for Services
Service SRC IP DST IP Proto
SRC
Port
DST
Port
Notes
Key
Exchange
LAN on grid
member
VIP on HA grid
master, or LAN
on single master
17 UDP 2114 2114 Initial key exchange for
establishing VPN tunnels
Required for Keystone
VPN LAN on grid
member
VIP on HA grid
master, or LAN
on single master
17 UDP 1194 or
5002,
or 1024
->
63999
1194 or
5002,
or 1024
->
63999
Default VPN port 1194 for
grids with new DNSone 3.2
installations and 5002 for
grids upgraded to DNSone
3.2; the port number is
configurable
Required for Keystone
DHCP Client LAN, VIP, or
broadcast on
NIOS appliance
17 UDP 68 67 Required for DHCP service
DHCP LAN or VIP on
NIOS appliance
Client 17 UDP 67 68 Required for DHCP service
DHCP
Failover
LAN or VIP on
Infoblox DHCP
failover peer
LAN or VIP on
Infoblox DHCP
failover peer
6 TCP 519 519 Required for DHCP failover
DHCP
Failover
VIP on HA grid
master or LAN on
single master
LAN or VIP on
grid member in a
DHCP failover
pair
6 TCP 1024 ->
65535
7911 Informs functioning grid
member in a DHCP failover
pair that its partner is down
Required for DHCP failover
DDNS
Updates
LAN or VIP LAN or VIP 17 UDP 1024 ->
65535
53 Required for DHCP to send
DNS dynamic updates
DNS
Transfers
LAN, VIP, or
MGMT, or client
LAN, VIP, or
MGMT
6 TCP 53, or
1024 ->
65535
53 For DNS zone transfers, large
client queries, and for grid
members to communicate
with external name servers
Required for DNS
DNS
Queries
Client LAN, VIP, or
broadcast on
NIOS appliance
17 UDP 53, or
1024 ->
65535
53 For DNS queries
Required for DNS
NTP NTP client VIP or LAN 17 UDP 1024 ->
65535
123 Required if the NIOS
appliance is an NTP server
RADIUS
Authenti-
cation
NAS (network
access server)
LAN or VIP 17 UDP 1024
65535
1812 For proxying RADIUS
Authentication-Requests.
The default destination port
number is 1812, and can be
changed to 1024 63997.
RADIUS
Accounting
NAS (network
access server)
LAN or VIP 17 UDP 1024
65535
1813 For proxying RADIUS
Accounting-Requests. The
default destination port
number is 1813, and can be
changed to 1024 63998.
RADIUS
Proxy
LAN or VIP RADIUS home
server
17 UDP 1814 1024 ->
63997
(auth),
or 1024
->
63998
(acct)
Required to proxy requests
from RADIUS clients to
servers. The default source
port number is 1814, and
although it is not
configurable, it is always two
greater than the port number
for RADIUS authentication.
ICMP Dst
Port
Unreach-
able
VIP, LAN, or
MGMT, or
UNIX-based
client
LAN or UNIX-
based client
1 ICMP
Type 3
Required to respond to the
UNIX-based traceroute tool
to determine if a destination
has been reached
ICMP Echo
Reply
VIP, LAN, or
MGMT, or client
VIP, LAN, or
MGMT, or client
1 ICMP
Type 0
Required for response from
ICMP echo request (ping)
ICMP Echo
Request
VIP, LAN, or
MGMT, or client
VIP, LAN, or
MGMT, or client
1 ICMP
Type 8
Required to send pings and
respond to the Windows-
based traceroute tool
ICMP TTL
Exceeded
Gateway device
(router or
firewall)
Windows client 1 ICMP
Type 11
Gateway sends an ICMP TTL
exceeded message to a
Windows client, which then
records router hops along a
data path
NTP LAN on active
node of grid
master or LAN of
independent
appliance
NTP server 17 UDP 1024 ->
65535
123 Required to synchronize
Keystone, TSIG authenti-
cation, and DHCP failover
Optional for synchronizing
logs among multiple
appliances
SMTP LAN or VIP Mail server 6 TCP 1024 ->
65535
25 Required if SMTP alerts are
enabled
SNMP NMS (network
management
system) server
VIP, LAN, or
MGMT
17 UDP 1024 ->
65535
161 Required for SNMP
management
SNMP Traps VIP on grid
master or HA
pair, LAN or
MGMT of
independent
appliance
NMS server 17 UDP 1024 ->
65535
162 Required for SNMP trap
management
SRC
Port
DST
Port
Notes
Ethernet Port Usage
Modifying Ethernet Port Settings
By default, the NIOS appliance automatically negotiates the optimal connection speed and transmission type (full or
half duplex) on the physical links between the 10/100Base-T and 10/100/1000Base-T ports on the NIOS appliance
and the Ethernet ports on a connecting switch. It is usually unnecessary to change the default auto-negotiation
setting; however, you can manually configure connection settings for a port if necessary.
Occasionally, for example, even though both the NIOS appliance and the connecting switch support 1000-Mbps
(megabits per second) full-duplex connections, they might fail to auto-negotiate that speed and type, and instead
connect at lower speeds of either 100 or 10 Mbps using potentially mismatched full- and half-duplex transmissions.
If this occurs, first determine if there is a firmware upgrade available for the switch. If so, apply the firmware upgrade
and test the connection. If that does not resolve the issue, manually set the ports on the NIOS appliance and on the
switch to make 1000-Mbps full-duplex connections.
To change Ethernet port settings:
or
Note: You must enable the MGMT port before modifying its port settings. See Using the MGMT Port on page 136.
2. In the Grid Member or Device editor, click LAN/HA Ports or MGMT Port, and then enter the following:
Use Automatic [ LAN | HA | MGMT ] Port Settings: Clear check box.
[ LAN | HA | MGMT ] Speed: Choose the connection speed that you want the port to use.
[ LAN | HA | MGMT ] Duplex: Choose Full for concurrent bidirectional data transmission or Half for data
transmission in one direction at a time.
Note: The port settings on the connecting switch must be identical to those you set on the NIOS appliance.
SSHv2 Client LAN, VIP, or
MGMT on NIOS
appliance
6 TCP 1024 ->
65535
22 Administrators can make an
SSHv2 connection to the
LAN, VIP, or MGMT port
Optional for management
Syslog LAN or MGMT of
NIOS appliance
syslog server 17 UDP 1024 ->
65535
514 Required for remote syslog
logging
Traceroute LAN or UNIX-
based appliance
VIP, LAN, or
MGMT, or client
17 UDP 1024 ->
65535
33000
->
65535
NIOS appliance responds
with ICMP type code 3 (port
unreachable)
TFTP Data LAN or MGMT TFTP server 17 UDP 1024 ->
65535
69,
then
1024 ->
63999
For contacting a TFTP server
during database and
configuration backup and
restore operations
HTTP Management
System
VIP, LAN, or
MGMT
6 TCP 1024 ->
65535
80 Required if the HTTP-redirect
option is set on the grid
properties security page
HTTPS/
SSL
Management
System
VIP, LAN, or
MGMT
6 TCP 1024 ->
65535
443 Required for administration
through the GUI
SRC
Port
DST
Port
Notes
Using the MGMT Port
Note: This feature is not supported on NIOS virtual appliances.
The MGMT (Management) port is a 10/100Base-T Ethernet connector on the front panel of an Infoblox-500, -1000,
and -1200 appliance and a 10/100/1000Base-T Ethernet connector on the front panel of an Infoblox-550, -1050,
-1550, and -1552 appliance. It allows you to isolate the following types of traffic from other types of traffic on the LAN
and HA ports:
Appliance Management on page 137
DNS Services on page 142
For information about what types of traffic qualify as appliance management, grid communications, and DNS
services, see Table 4.2 on page 133.
Note: The MGMT port currently does not support DHCP, NTP, NAT, RADIUS proxying, or TFTP.
Some NIOS appliance deployment scenarios support more than one concurrent use of the MGMT port. The following
table depicts MGMT port uses for various appliance configurations.
Table 4.3 Supported MGMT Port Uses for Various appliance Configurations
* Although you manage all grid members through the grid master, if you enable the MGMT port on common grid
members, they can send syslog events, SNMP traps, and e-mail notifications, and receive SSH connections on that
port.
Infoblox does not support MGMT port usage for some appliance configurations (indicated by the symbol in
Table 4.3) because it cannot provide redundancy through the use of a VIP. A grid master that is an HA pair needs the
redundancy that a VIP interface on the HA port provides for grid communications. Similarly, DNS servers in an HA pair
need that redundancy to answer DNS queries. Because the MGMT port does not support a VIP and thus cannot
provide redundancy, grid masters (and potential grid masters) do not support grid communications on the MGMT
port.
In addition, NIOS appliances in an HA pair support DNS services on the active node only (indicated by the symbol
in Table 4.3). Only the active node can respond to queries that it receives. If a DNS client sends a query to the MGMT
port of the node that happens to be the passive node, the query can eventually time out and fail.
Appliance
Configuration
Appliance
Management
Grid
Communications
DNS
Services
Single Independent Appliance
Not Applicable
Independent HA Pair
Not Applicable
Grid Master

Grid Master Candidate

HA Grid Member
*
Single Grid Member
*
Using the MGMT Port
The MGMT port is not enabled by default. By default, a NIOS appliance uses the LAN port (and HA port when deployed
in an HA pair). You must log in using a superuser account to enable and configure the MGMT port. You can enable the
MGMT port through the Infoblox GUI (as explained in the following sections) or through a console connection with the
following command: set i nt er f ace mgmt speed aut o dupl ex aut o
Note: For information about connecting Ethernet cables to the MGMT port, refer to Cabling for the MGMT Port on
page 727.
Appliance Management
You can restrict administrative access to a NIOS appliance by connecting the MGMT port to a subnet containing only
management systems. This approach ensures that only appliances on that subnet can access the Infoblox GUI and
receive appliance management communications such as syslog events, SNMP traps, and e-mail notifications from
the appliance.
If you are the only administrator, you can connect your management system directly to the MGMT port. If there are
several administrators, you can define a small subnetsuch as 10.1.1.0/29, which provides six host IP addresses
(10.1.1.110.1.1.6) plus the network address 10.1.1.0 and the broadcast address 10.1.1.7and connect to the
NIOS appliance through a dedicated switch (which is not connected to the rest of the network). Figure 4.5 shows how
an independent appliance separates appliance management traffic from network protocol services. Note that the
LAN port is on a different subnet from the MGMT port.
Figure 4.5 Appliance Management from One or More Management Systems
The NIOS appliance serves
DNS and DHCP to the public
network through the LAN port.
Public Network
1.1.1.0/24
DNS and DHCP Services
A single management system connects
directly to the MGMT port of the NIOS
appliance through an Ethernet cable.
Private Network
10.1.1.0/30
Several management systems connect
to the MGMT port of the NIOS
appliance through a dedicated switch.
Private Network
10.1.1.0/29
Note:
Because the two private networks are
used solely for appliance management
and are completely isolated from the rest
of the networkand therefore from each
othertheir address space can overlap
without causing any routing issues
LAN
1.1.1.5
MGMT
10.1.1.1
Ethernet
Cable
NIOS
appliance-1
LAN
1.1.1.6
MGMT
10.1.1.1
Infoblox
Appliance -2
Ethernet
Cable
Dedicated
Switch
DNS and DHCP Clients
Management Systems
10.1.1.2 - 10.1.1.5
Similarly, you can restrict management access to a grid master to only those appliances connected to the MGMT ports
of the active and passive nodes of the grid master.
To enable the MGMT port on an independent appliance or grid master for appliance management and then cable the
MGMT port directly to your management system or to a network forwarding appliance such as a switch or router:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> grid_master -> Edit -> Member Properties.
or
Note: You must enable the MGMT port before modifying its port settings. See Using the MGMT Port on page 136.
2. In the Grid Member or Device editor, click MGMT Port, and then enter the following in Node 1 subsection for a
single grid master or independent appliance, and in the Node 1 and Node 2 subsections for an HA grid master or
independent HA pair:
Enable management (MGMT) port: Select check box.
Enable VPN services on the MGMT port: Clear check box.
Restrict Support and remote console access to MGMT port: Select the check box to restrict SSH (Secure
Shell) v2 access to the MGMT port only. This restricts Infoblox Technical Support and remote console
connectionsboth of which use SSH v2to just the MGMT port. For an HA pair, you can make an SSH v2
connection to the MGMT port on both the active and passive nodes.
Clear the check box to allow SSH v2 access to both the MGMT and LAN ports. For an HA pair, you can make
an SSH v2 connection to the MGMT and LAN ports on both the active and passive nodes.
IP Address: Type the IP address for the MGMT port, which must be in a different subnet from that of the LAN
and HA ports.
Subnet Mask: Choose an appropriate subnet mask for the number of management systems that you want
to access the appliance through the MGMT port.
Gateway: Type the default gateway for the MGMT port. If you need to define any static routes for traffic
originating from the MGMT portsuch as SNMP traps, syslog events, and email notificationsdestined for
remote subnets beyond the immediate subnet, specify the IP address of this gateway in the route.
Use automatic MGMT port settings: Select the check box to instruct the NIOS appliance to negotiate the
optimum port connection type (full or half duplex) and speed with the connecting switch automatically. If
you clear the check box, manually configure the same settings on both the NIOS appliance and the switch.
By default, the check box is selected.
3. Click the Save icon to save your settings.
4. Close the current JWS (Java Web Start) application window.
5. Cable the MGMT port to your management system or to a switch or router to which your management system can
also connect.
6. If your management system is in a subnet from which it cannot reach the MGMT port, move it to a subnet from
which it can.
The Infoblox Grid (or Device) Manager GUI is now accessible through the MGMT port on the NIOS appliance from
your management system.
7. Start a new JWS session, and then log in to the IP address of the MGMT port.
8. Check the Detailed Status and Grid panels to make sure the status icons are green.
Using the MGMT Port
Grid Communications
You can isolate all grid communications to a dedicated subnet as follows:
For grid communications from the grid master, which can be an HA pair or a single appliance, the master uses
either the VIP interface on the HA port of its active node (HA master) or its LAN port (single master). Neither a
single nor HA grid master can use its MGMT port for grid communications. (This restriction applies equally to
master candidates.)
Common grid members connect to the grid master through their MGMT port.
This ensures that all database synchronization and grid maintenance operations are inaccessible from other network
elements while the common grid members provide network protocol services on their LAN ports.
Figure 4.6 shows how grid members communicate to the master over a dedicated subnet.
Figure 4.6 Grid Communications
The private network
(10.1.1.0/24) is reserved for
grid communications
between the grid master and
all grid members, and for
appliance management
between the management
system and the grid master.
Private Network
10.1.1.0/24
for Grid Communications
and appliance Management
Public Network
1.1.1.0/24
DNS and DHCP Services
HA Grid Master Master Candidate
HA
HA
HA
HA
VIP
10.1.1.10
VIP
10.1.1.5
Management
System
10.1.1.30
HA
HA
MGMT
10.1.1.15
MGMT
10.1.1.20
Passive
Node
MGMT
10.1.1.21
Active Node
HA Member Single Member
LAN
1.1.1.6
VIP
1.1.1.7
The common grid
members connect to the
private network through
their MGMT ports*.
They connect to the
public network through
their LAN and HA ports
(using a VIP).
The grid master and
master candidate
connect to the private
network using a VIP
on their HA ports.
The common grid
members use the public
network (1.1.1.0/24) for
DNS and DHCP services.
* Only the active node of an HA member connects to the grid master. The
passive node communicates just with the active node. If there is an HA failover,
the newly promoted active node must first join the grid before continuing grid
communications with the grid master on behalf of the HA member.
Enabling Grid Communications over the MGMT Port for Existing Grid Members
To enable the MGMT port for grid communications on an existing single or HA grid member:
1. Log in to the grid master with a superuser account.
3. In the Grid Member editor, click MGMT Port, and then enter the following for Node 1. For an HA member, enter
the IP address, subnet mask, and gateway address for both Node 1 and Node 2.
Enable management (MGMT) Port: Select the check box.
Enable VPN services on the MGMT Port: Select the check box.
connectionsboth of which use SSH v2to just the MGMT port. For an HA pair, you can make an SSH v2
connection to the MGMT port on both the active and passive nodes.
Clear the check box to allow SSH v2 access to both the MGMT and LAN ports. For an HA pair, you can make
an SSH v2 connection to the MGMT and LAN ports on both the active and passive nodes.
IP Address: Type the IP address of the MGMT port on the grid member, which must be in a different subnet
from that of the LAN and HA ports.
Subnet Mask: Choose the subnet mask for the MGMT port IP address.
Gateway: Type the default gateway for the MGMT port.
Use automatic MGMT port settings: Select the check box to instruct the NIOS appliance to negotiate the
optimum port connection type (full or half duplex) and speed with the connecting switch automatically. If
you clear the check box, manually configure the same settings on both the NIOS appliance and the switch.
By default, the check box is selected.
4. If the IP addresses of the LAN and HA ports are in the same subnet as the IP address of the MGMT port, click Node
Properties in the Grid Member editor, and then change the IP address of the LAN port (for a single member) and
LAN and HA ports (for an HA member).
The master communicates the new port settings to the member, which immediately begins using them. The
member stops using its LAN port for grid communications and begins using the MGMT port.
6. To confirm that the member still has grid connectivity, check that the status icons for that member are green on
the Detailed Status and Grid panels.
Enabling Grid Communications over the MGMT Port for New Grid Members
To enable the MGMT port for grid communications on a single appliance or HA pair and then join it to a grid:
Member MGMT Port Configuration on the Grid Master
1. Log in to the grid master with a superuser account.
2. From the Grid perspective, click grid -> Add Grid Member.
3. In the Grid Member editor, click Node Properties, configure the network settings for a single member or the
network and HA settings for an HA member, and then clear the Master Candidate check box. Any member
that is a master candidate cannot use the MGMT port for grid communications.
4. In the Grid Member editor, click MGMT Port, and then enter the following for Node 1 (for a single appliance).
For an HA pair, enter the IP address, subnet mask, gateway address, and port settings for both Node 1 and
Node 2.
Enable VPN services on the MGMT Port: (You must add the member before you can select this check
box, which you do in step 7.)
Using the MGMT Port
connectionsboth of which use SSH v2to just the MGMT port. For an HA member, you can make an
SSH v2 connection to the MGMT port on both the active and passive nodes.
Clear the check box to allow SSH v2 access to both the MGMT and LAN ports. For an HA member, you can
make an SSH v2 connection to the MGMT and LAN ports on both the active and passive nodes.
IP Address: Type the IP address of the MGMT port on the grid member. This is the address that you
previously set when configuring the appliance. The MGMT port address cannot be in the same subnet
as the addresses of the LAN and HA ports.
Subnet Mask: Choose the subnet mask for the MGMT port IP address.
Gateway: Type the default gateway for the MGMT port.
Use automatic MGMT port settings: Select the check box to instruct the member to negotiate the
optimum port connection type (full or half duplex) and speed with the connecting switch automatically.
If you clear the check box, manually configure the same settings on both the NIOS appliance and the
switch. By default, the check box is selected.
5. Click the Save icon to add the member.
6. In the Grid perspective, select the member you just created, click Edit -> Member Properties.
7. In the Grid Member editor, click MGMT Port, select Enable VPN services on the MGMT Port, and then click
the Save icon.
MGMT Port Configuration on Appliance or HA Pair
1. Log in as a superuser to the MGMT port of the appliance or active node of the HA pair that you want to join
to the grid.
3. In the Grid Member editor, click MGMT Port, and then change the following for Node 1 (for a single
appliance). For an HA pair, enter the IP address, subnet mask, and gateway address for both Node 1 and
Node 2.
Enable VPN services on the MGMT Port: (You cannot select this because the appliance or HA pair is not
yet a grid member. When the appliance or HA pair joins the grid, it receives its new configuration from
the grid master, and in that configuration, this option is set.)
Note: For the remainder of the MGMT port settings, configure the same settings that you previously set for the
single or HA member on the grid master (see step 4 in Member MGMT Port Configuration on the Grid
Master on page 140).
4. If the IP addresses of the LAN and HA ports are in the same subnet as the IP address of the MGMT port, click
Node Properties in the Grid Member editor, and then change the IP address of the LAN port (for a single
member) and LAN and HA ports (for an HA member).
6. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Join Grid.
7. Enter the following in the Join Grid dialog box:
Virtual IP of Grid Master: Type the VIP address of the grid master for the grid to which you want to add
the single appliance or HA pair.
Grid Name: Type the name of the grid.
Grid Shared Secret: Type the shared secret of the grid.
Re-type Grid Shared Secret: To ensure accuracy, retype the shared secret.
Use MGMT port to join grid: Because you have already enabled the MGMT port, this option is available.
Select it to connect to the grid through the MGMT port.
For a single appliance, it connects to the grid master from its MGMT port. The grid master allows it to join the
grid, and sends it its configuration andif the appliance is running a different software version from the rest of
the gridthe software version for the grid.
When an HA pair joins the grid through their MGMT ports, each node joins separately. The process occurs as
follows:
1. You join the active node to the grid first (step 7) and the grid master sends it the remainder of its
configuration andif the node is running a different software version from the rest of the gridthe software
version for the grid.
2. The HA pair fails over.
3. You now log in to the other node, which is now active, and join it to the grid (repeat step 7). The master
sends it its configuration and (if necessary) the version of software running on the grid.
4. The HA pair fails over again, so that the node that was active when you started the join operation becomes
the active node again when you finish it.
After an appliance or HA pair is part of the grid, you continue configuring it through the grid master.
DNS Services
You can configure a single independent appliance or single grid member to provide DNS services through the MGMT
port in addition to the LAN port. For example, the appliance can provide DNS services through the MGMT port for
internal clients on a private network, and DNS services through the LAN port for external clients on a public network.
While providing DNS services on the MGMT port, you can still use that port simultaneously for appliance
management. Figure 4.7 shows a management system communicating with a single independent appliance through
its MGMT port while the appliance also provides DNS services on that port to a private network. Additionally, the
appliance provides DNS services to an external network through its LAN port.
Figure 4.7 DNS Services on the LAN and MGMT Ports, and appliance Management on the MGMT Port
Like a single independent appliance, a single grid member can also support concurrent DNS traffic on its MGMT and
LAN ports. However, because you manage all grid members through the grid master, a grid member only uses an
enabled MGMT port to send SNMP traps, syslog events, and email notifications, and to receive SSH connections.
External
Network
External DNS Clients External DNS Client
Single
Independent
Appliance
LAN
Port
MGMT
Port
Internal DNS Clients Internal
Network
Management System
Appliance management and
internal DNS services go
through the MGMT port.
External DNS services go
through the LAN port.
Using the MGMT Port
In addition, the active node of an HA pair can provide DNS services through its MGMT port. To use this feature, you
must enable DNS services on the MGMT ports of both nodes in the HA pair and specify the MGMT port IP addresses
of both nodes on the DNS client as well, in case there is a failover and the passive node becomes active. Note that
only the active node can respond to queries that it receives. If a DNS client sends a query to the MGMT port of the
node that happens to be the passive node, the query can eventually time out and fail.
To enable DNS services on the MGMT port of an appliance:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> grid_master -> Edit -> Member Properties.
or
2. In the Grid Member or Device editor, click MGMT Port, and then enter the following in Node 1 subsection for a
single grid master or independent appliance, and in the Node 1 and Node 2 subsections for an HA grid master or
independent HA pair:
IP Address: Enter the IP address of the MGMT port. The MGMT port IP address must be in a different subnet
from that of the LAN and HA ports.
Subnet mask: Choose an appropriate subnet mask for the MGMT port.
Gateway: Enter the IP address of the gateway for the MGMT port.
3. Click the Save icon to save your settings for the MGMT port.
4. From the DNS perspective of the Member DNS Properties editor, click DNS Members -> + (for grid ) -> member ->
DNS -> Modify -> General.
5. In the Member DNS Properties editor, click General, and then select Enable DNS Services on the MGMT Port.
7. Click the Restart Services icon if it flashes.
8. To see that the appliance now also serves DNS on the MGMT port:
From the DNS perspective, click DNS Members -> + (for grid ) -> member -> View -> Properties, and look in the
General section. Check that the value for Enable DNS Services on the MGMT Port is true.
or
From the DNS perspective, click DNS Members -> + (for grid ) -> member -> View -> DNS Configuration, and check
that the IP address of the MGMT port appears in the address match list in the listen-on substatement.
Setting Static Routes
When you put the NIOS appliance on a segment of the network where there is a single path to and from it, a single
default route is sufficient. For example, in Figure 4.8 on page 144, the appliance is in the DMZ behind a firewall and
connects to the rest of the network through the DMZ interface on the firewall. For example, when hosts send DNS
queries from the Internet and the internal network to the appliance and when the appliance replies to those hosts,
the firewall takes care of all the routing.
Figure 4.8 Single Default Route
When the NIOS appliance is on a segment of the network where there are multiple gateways through which traffic to
and from the appliance can flow, a single default route is insufficient. For an example, see Figure 4.9.
NIOS appliance
Internet
Internal Network
Firewall
DMZ
1.2.2.1
The appliance responds to all queries from the
Internet and internal network by sending its
responses to the DMZ interface (1.2.2.1) on
the firewall.
The appliance only needs a single default route
to the firewall. The firewall then routes the
traffic where it needs to go.
The default route points all traffic from the LAN or LAN1
port on the NIOS appliance to the DMZ interface
(1.2.2.1) on the firewall.
Default route:
Network: 0.0.0.0
Netmask: 0.0.0.0
Gateway: 1.2.2.1
LAN
Port
Setting Static Routes
Figure 4.9 Erroneously Routed DNS Replies
To resolve the problem illustrated in Figure 4.9 on page 145, add a second route pointing traffic destined for
10.1.1.0/24 to use the gateway with IP address 1.2.2.2 on firewall-2. This is shown in Figure 4.10.
Figure 4.10 Properly Routed DNS Replies
Internet
Internal Network
10.1.1.0/24
Switch
1.2.2.1
1.2.2.2
The default route points all traffic from the NIOS
appliance to the DMZ interface (1.2.2.1) on
firewall-1.
Default route:
Network: 0.0.0.0
Netmask: 0.0.0.0
Gateway: 1.2.2.1
DNS queries from the Internet reach the
appliance through firewall-1, and the
appliance sends its replies back through
firewall-1.
DNS queries from the internal network reach
the appliance through firewall-2, but because
there is only one default route, the appliance
erroneously sends DNS replies to the DMZ
interface (1.2.2.1) on firewall-1.
NIOS appliance
Firewall-1
Firewall-2
DMZ
Internet
Internal Network
10.1.1.0/24
Switch
1.2.2.1
1.2.2.2
The default route on the NIOS appliance
points traffic destined for the Internet to the
DMZ interface (1.2.2.1) on firewall-1.
Default route:
Network: 0.0.0.0
Netmask: 0.0.0.0
Gateway: 1.2.2.1
A second route on the appliance points
traffic destined for 10.1.1.0/24 to the DMZ
interface (1.2.2.2) on firewall-2.
Route to:
Network: 10.1.1.0
Netmask: 255.255.255.0
Gateway: 1.2.2.2
NIOS appliance
Firewall-1
Firewall-2
DMZ
1.2.2.0/24
Whenever you want the NIOS appliance to send traffic through a gateway other than the default gateway, you need
to define a separate route. Then, when the appliance performs a route lookup, it chooses the route that most
completely matches the destination IP address in the packet header.
When you enable the MGMT port, the gateway you reference in a static route determines which port the NIOS
appliance uses when directing traffic to a specified destination.
If a route definition references a gateway that is in the same subnet as the IP and VIP addresses of the LAN (or
LAN1) and HA ports, the NIOS appliance uses the LAN (or LAN1) or HA port when directing traffic to that
gateway.
If a route definition references a gateway that is in the same subnet as the MGMT port, the NIOS appliance uses
the MGMT port when directing traffic to that gateway.
Figure 4.11 Static Routes for the LAN and MGMT Ports
The need for routes can apply to any type of traffic that originates from the appliance, such as DNS replies, DHCP
messages, SNMP traps, ICMP echo replies, Infoblox GUI management, and grid communications.
Internet
MGMT
Gateway
Switch
Switch
NIOS
appliance
Internal Network
10.1.1.0/24
Subnet
10.1.3.0/24
Subnet
10.1.2.0/24
LAN Port
1.2.2.5
1.2.2.2
10.1.1.1
Administrators 10.1.2.1 10.1.3.1 MGMT Port
10.1.2.5
Fr omLAN:
1. 2. 2. 0/ 24 dev et h1 scope l i nk
10.1.1.0/24 via 1.2.2.2 dev eth1
def aul t vi a 1. 2. 2. 1 dev et h1
Fr omMGMT:
10. 1. 2. 0/ 24 dev et h0 scope l i nk
10.1.3.0/24 via 10.1.2.1 dev eth0
Fr omal l :
10.1.1.0/24 via 1.2.2.2 dev eth1
10.1.3.0/24 via 10.1.2.1 dev eth0
1. 2. 2. 0/ 24 dev et h1 pr ot o ker nel scope l i nk sr c 1. 2. 2. 5
10. 1. 2. 0/ 24 dev et h0 pr ot o ker nel scope l i nk sr c 10. 1. 2. 5
Route Tables on the NIOS appliance
Two static routes direct traffic from the NIOS appliance:
From the LAN port (eth1, 1.2.2.5) through the gateway
at 1.2.2.2 to the 10.1.1.0/24 subnet.
From the MGMT port (eth0, 10.1.2.5) through the
gateway at 10.1.2.1 to the 10.1.3.0/24 subnet.
Note: There is a route table for each port
as well as a comprehensive route table.
For an HA pair, the LAN port route table
is duplicated for the HA port.
In this illustration, the static routes are
shown in green.
LAN Gateway
(Firewall-2)
LAN Gateway
(Firewall-1)
1.2.2.1
DMZ
1.2.2.0/24
Enabling DNS Resolution
To set a static route, do the following:
1. For a grid member: From the Grid perspective, click + (for grid ) -> + (for Member s) -> member -> Edit -> Member
Properties.
or
For an independent appliance or HA pair: From the Device perspective, click hostname -> Edit -> Device
Properties.
2. In the Member or Device editor, click Static Routes, click Add, and then enter the following:
Network Address: Type the address of the remote network to which the NIOS appliance routes traffic.
Netmask: Choose the netmask that defines the remote network.
Gateway Address: Type the IP address of the gateway on the local subnet through which the NIOS appliance
directs traffic to reach the remote network. The gateway address must meet the following requirements:
It must belong to a working gateway router or gateway switch.
It must be in the same subnet as the NIOS appliance.
Note: Consult your network administrator before specifying the gateway address for a static route on the
appliance. Specifying an invalid gateway address can cause problems, such as packets being dropped or
sent to an incorrect address.
Enabling DNS Resolution
You can specify a network server to perform domain name queries and specify up to two name servers for resolving
a DNS name, plus use a search list to perform partial name resolution.
If a NIOS appliance provides DHCP services only, specify a DNS name server or servers that the appliance can use for
DNS lookups. You specify the IP address of a preferred name server and that of an alternate name server, plus use a
search list for performing partial name resolution.
To enable DNS resolution for a grid or for an independent appliance or HA pair:
or
2. In the Grid editor, click DNS Resolver, and then enter the following:
Use DNS name resolver: Select the check box to enable the NIOS appliance to send DNS queries to the
preferred or alternate name servers whose IP addresses you specify in the following fields.
Preferred Name Server: Type the IP address of the server to which the appliance sends queries first.
Alternate Name Server: Type the IP address of the name server to which you want the NIOS appliance to
send queries if it does not receive a response from the preferred name server.
Search Domain Group: Define a group of domain names that the NIOS appliance can add to partial queries
that do not specify a domain name. For example, if you define a RADIUS authentication home server as
as1, and you list "corp100.com" and "hq.corp100.com" in the domain group list, then the NIOS
appliance sends a query for "as1.corp100.com" and another query for "as1.hq.corp100.com" to the
preferred or alternate name server.
To add a domain name to the group, type a domain name in the Domain field, and then click Add. To
remove a domain name from the group, select it, and then click Delete.
Note: You can override the grid-level settings at the member level.
Managing Licenses
Licenses come pre-installed on a NIOS appliance according to the software packages you ordered at the time of
purchase. If you wish to upgrade an existing appliance with the Keystone license, you must contact Infoblox Technical
Support and follow the procedures in Obtaining and Adding a License on page 149.
There are three types of licenses:
Maintenance licenses Examples: NIOS and Keystone maintenance licenses. The duration of maintenance
licenses are one, two, or three years. You can obtain these licenses from your Infoblox sales representative.
Service licenses Examples: DNS, DHCP, Keystone. These are permanent licenses. You can obtain these
licenses from your Infoblox sales representative.
Temporary licenses You can enable one of several sets of temporary service licenses through the CLI
command set t emp_l i cense . These licenses last for 60 days.
Two weeks before a maintenance license or a temporary license expires, an expiration warning appears during the
GUI login process. The warning reappears during each login until you renew the license. To do renew a license, contact
your Infoblox sales representative. If you decide not to renew an expired license and want to stop the warning from
reappearing, do the following:
1. Back up the configuration and database as described in Backing Up and Restoring a Configuration File on
page 222.
2. Log in to the Infoblox CLI, enter the show license command, and save all the license key strings.
3. Remove all the licensesand the entire configuration and databaseby entering the reset all
licenses command. For details, see Removing Licenses on page 149.
4. Add the unexpired licenses back to the appliance using either the Infoblox GUI or CLI.
5. Restore the backup file as described in Backing Up and Restoring a Configuration File on page 222.
Viewing the Installed Licenses on a NIOS Appliance
If the appliance you are identifying is part of a grid, you must log in to the master GUI for the grid to view the licenses
installed. If the appliance is deployed as a single independent appliance, log in to the GUI for that appliance.
To view the licenses installed on a NIOS appliance, follow these steps:
1. Log in to the Infoblox GUI using a superuser account.
2. From the Grid or Device perspective, click hostname -> View -> Properties.
3. Click the + icon beside the License section to expand it and view the licenses installed on the appliance.
Obtaining a 60-Day Temporary License
You can use the CLI command set t emp_l i cense to generate and install temporary 60-day licenses. This can
provide licensed features and functionality for the interim, while you wait for your permanent license to arrive.
To generate a temporary license:
1. Log in to the NIOS appliance through a remote console window. For more information on how to open a remote
console window, see the User Guide for your appliance.
2. After the Infoblox command prompt, enter the following command:
set t emp_l i cense
The following options appear:
1. DNSone (DNS, DHCP)
2. DNSone with Keystone (DNS, DHCP, Grid)
3. Network Services for Alcatel-Lucent VitalQIP (QIP, Grid)
4. Network Services for Voice (DHCP, Grid)
5. Network Services for Authentication (RADIUS, Grid)
Managing Licenses
6. Network Services Suite (DNS, DHCP, RADIUS, Grid)
7. Add DNS Server license
8. Add DHCP Server license
9. Add RADIUS Server license
10. Add Grid license
3. Enter the number for the license you want to install.
4. Confirm the selection when prompted, and the following message appears:
Tempor ar y l i cense i s i nst al l ed.
Obtaining and Adding a License
A valid Keystone license is required for grid NIOS appliance deployments. You can upgrade existing independent
appliances to use a Keystone license and then add them to a grid. To upgrade your license, contact your Infoblox sales
representative.
To add a license:
1. Log in to the Infoblox GUI using a superuser account.
2. From the Grid or Device perspective, click hostname -> Edit -> Add License.
3. In the Add License dialog box, copy the hardware ID and serial number of your appliance and paste this
information into an e-mail to Infoblox Support.
4. When you receive the license key, use the shortcut keys Ctrl-C (for copy) and Ctrl-V (for paste) to copy the license
key from the response e-mail, and then paste it in the Enter license string field.
5. Click OK to close the Add License dialog box.
6. Close the browser window and log in to the Infoblox GUI.
7. If you are activating licenses for an HA pair, you must repeat this procedure for the second node.
Removing Licenses
You can remove licenses and reset a NIOS appliance to its factory default settings. For example, if you have a NIOS
appliance running the DNSone package with the Keystone upgrade, but you want to use it as an independent
appliance and manage it through the Device Manager GUI, you can do the following:
1. Log in to the NIOS appliance CLIlocally through the Console port or remotely through an SSHv2 connection
and use the show license command to view all the licenses installed on the appliance.
The output of the the show l i cense command looks similar to the following:
I nf obl ox > show l i cense
Ver si on: 4. 0r 1
Har dwar e I D: ecaf c0c469e8c75eb59cb7e4b5912a6
Li cense Type: Keyst one DVS
Expi r at i on Dat e: 11/ 04/ 2006
Li cense St r i ng: GQAAAAOS5WYr GV/ J EzH6wr HYQ8L1b25y3Y+VPPY=
Li cense Type: DNS
Expi r at i on Dat e: Per manent
Li cense St r i ng: EQAAAAKS4n90WFGNUSi r wvyUT9/ z
Li cense Type: DHCP
Expi r at i on Dat e: Per manent
Li cense St r i ng: EgAAAAKU8nMl RBzcTWX63r HYFoymOQ==
Li cense Type: Keyst one Mai nt enance
Li cense St r i ng: GwAAAA2Z6HAt BkPFPyf zg/ yVRsLzI 2x0kYyKaPb22g==
Li cense Type: NI OS Mai nt enance
Li cense St r i ng: GwAAAAi V/ nAGGl j QEDv0h/ yVRsLzI 2x0kYyKb/ P20Q==
2. Copy the output of the show l i cense command, and save it to a text file on your management system.
3. Reset the NIOS appliance and remove all the licenses by entering the reset all licenses command.
4. This command returns all settings to their default values and removes all licenses.
I nf obl ox > r eset al l l i censes
The ent i r e syst emwi l l be er ased t o def aul t set t i ngs and al l l i censes wi l l be r emoved.
WARNI NG: THI S WI LL ERASE ALL DATA AND LOG FI LES THAT HAVE BEEN CREATED ON THI S SYSTEM.
ARE YOU SURE YOU WANT TO PROCEED? ( y or n) : y
The application restarts with the default settings and no licenses.
5. Log in to the CLI through the Console port, and check that all the licenses are gone by entering the
show license command.
I nf obl ox > show license
Ver si on: 4. 0r 1
Har dwar e I D: ecaf c0c469e8c75eb59cb7e4b5912a6
I nf obl ox >
6. Add back only the DNS, DHCP, and NIOS Maintenance licenses by entering the set license command and
then copying and pasting the text string for each license:
I nf obl ox > set license
Ent er l i cense st r i ng: EQAAAAKS4n90WFGNUSirwvyUT9/z
I nst al l l i cense? ( y or n) : y
Li cense i s i nst al l ed.
Ent er l i cense st r i ng: EgAAAAKU8nMlRBzcTWX63rHYFoymOQ= =
Ent er l i cense st r i ng: GwAAAAiV/nAGGljQEDv0h/yVRsLzI2x0kYyKb/P20Q==
7. To check that the licenses are now installed, enter the show license command.
When you next log in to the GUI, the Infoblox Device Manager appears instead of the Infoblox Grid Manager.
Shutting Down, Rebooting, and Resetting a NIOS Appliance
Shutting Down, Rebooting, and Resetting a NIOS Appliance
To reboot and shut down a NIOS appliance, you can use the Infoblox Manager GUI or the Infoblox CLI. To reset a NIOS
appliance, you must use the Infoblox CLI.
Rebooting a NIOS Appliance
You can reboot a single NIOS appliance, a single node in an HA pair, or both nodes in an HA pair.
To reboot a single NIOS appliance or one or both nodes in an HA pair using the GUI:
1. From the Grid or Device perspective, click hostname -> Edit -> Reboot.
2. For an HA pair, choose whether to boot one node (and which one) or both nodes, and then click OK.
To reboot a single NIOS appliance using the CLI:
1. Log in to the Infoblox CLI using a superuser account for the NIOS appliance that you intend to reboot.
2. Enter the following CLI command: reboot
Shutting Down a NIOS Appliance
Under normal circumstances, you do not need to turn off or shut down a NIOS appliance. It is designed to operate
continuously. However, if you want to turn off a NIOS appliance and it is inconvenient to turn off the power switch,
you can shut down the NIOS appliance using the GUI. Before shutting down a remote appliance, make sure you can
restart it. You cannot restart the system using the GUI.
Note: If there is a disruption in power when the NIOS appliance is operating, the NIOS appliance automatically
reboots itself when power is restored.
To shutdown a NIOS appliance using the GUI:
1. Log in to the Infoblox Manager GUI using a superuser account.
2. From the Grid or Device perspective, click hostname -> Edit -> Shutdown.
3. For an HA pair, choose whether to shut down one node (and which one) or both nodes, and then click OK.
The NIOS appliance shuts down. The fans might continue to operate until the appliance cools down.
To shutdown a NIOS appliance using the CLI:
1. Log in to the Infoblox CLI using a superuser account.
2. Enter the following CLI command: shutdown
Resetting a NIOS Appliance
There are three ways to reset a NIOS appliance:
Resetting the Database on page 152
Resetting a NIOS Appliance to Factory Settings on page 152
Resetting the NIOS Appliance to Factory Settings and Removing Licenses on page 152
You can perform these functions only through the CLI.
Resetting the Database
You can reset the database if you lose the administrator account and password or if you want to clear the database
but preserve the log files to diagnose a problem. This function removes the configuration files, and the DNS and DHCP
data from the appliance database. During this procedure, you are given the option to preserve the network settings
of the appliance, which are the IP address and subnet mask, the IP address of the gateway, the host name, and the
remote access setting.
To reset the database:
2. Enter the following CLI command: reset database
The appliance then displays a message similar to the following:
The f ol l owi ng net wor k set t i ngs can be r est or ed af t er r eset :
I P Addr ess: 10. 1. 1. 10
Subnet Mask: 255. 255. 255. 0
Gat eway: 10. 1. 1. 1
Host Name: ns1. cor p100. com
Remot e Consol e Access: t r ue
The ent i r e dat abase wi l l be er ased.
Do you wi sh t o pr eser ve basi c net wor k set t i ngs? ( y or n)
3. Press the Y key to preserve the network settings or the N key to return the network settings to their default values
(192.168.1.2, 255.255.255.0, 192.168.1.1).
Resetting a NIOS Appliance to Factory Settings
You can reset a NIOS appliance to its original factory settings. This removes the database, network settings, logs, and
configuration files. Then, it reboots with its factory settings, which are the default user name and password, and
default network settings. When you perform this procedure, the appliance does not give you the option to preserve
your network settings.
Note: If you have previously imported HTTPS certificates, the appliance regenerates the certificates and replaces
them.
To reset the NIOS appliance to its factory settings:
2. Enter the following CLI command: reset all
Resetting the NIOS Appliance to Factory Settings and Removing Licenses
You can also reset a NIOS appliance to its original factory settings and remove all the licenses installed on the
appliance. This removes the database, network settings, logs, configuration files, and licenses. The appliance then
reboots with its factory settings, which are the default user name and password, and default network settings.
Note: If you have previously imported HTTPS certificates, the NIOS appliance regenerates the certificates and
replaces them.
To reset the NIOS appliance to its factory settings and remove all its licenses:
2. Enter the following CLI command: reset all licenses
Managing the Disk Subsystem on the Infoblox-2000
Among its many features, the Infoblox-2000 uses redundant disk drives in a RAID 10 array. This configuration
provides the optimum mix of performance with completely redundant data storage with recovery features in the event
of disk failures. The disk array is completely self managed. There are no maintenance or special procedures required
to service the disk subsystem.
Caution: It is important to never remove more than one disk at a time from the array. Removing two or more disks at
once can cause a failure and possibly unrecoverable condition.
About RAID 10
RAID 10 (or sometimes called RAID 1+0) is a stripe of mirrors. This means that the array combinesor stripes
multiple disk drives, creating a single logical volume (RAID 0). Striping disk drives improves database write
performance over a single disk drive for large databases. The disks are also mirrored (RAID 1), so that each disk in
the logical volume is fully redundant. Please seeFigure 4.12.
Figure 4.12 RAID 10 Array Configuration
When evaluating a fault on the Infoblox-2000, it is best to think of the disk subsystem as a single, integrated unit with
four components, rather than four independent disk drives.
RAID 0
RAID 1 RAID 1
Disk 1
Primary
Disk 1
Backup
Disk 2
Primary
Disk 2
Backup
Evaluating the Status of the Disk Subsystem
You can monitor the disk subsystem through the Infoblox GUI, the scrolling front panel LCD display, and four front
panel LEDs next to the disk drives. In addition, you can monitor the disk status by using the CLI command show
har dwar e_st at us.
The Detailed Status panel provides a detailed status report on the appliance and service operations. To see a detailed
status report, from the Grid perspective, select grid, and then click View -> Detailed Status. After displaying the
Detailed Status panel, you can view the status of individual grid members and services by selecting them in the Grid
panel. For more information on the Detailed Status Panel, see Viewing Detailed Status on page 160.
The RAID icon indicates the status of the RAID array on the Infoblox-2000.
Appliance Front Panel
The disk drives are located on the right side of the appliance front panel. To the right of each drive there is an LED
that displays the status of each drive.
Table 4.4 Disk Drive LEDs
In addition, the front panel LCD scrolls and displays the disk array status every 20 seconds.
Replacing a Failed Disk Drive
The Infoblox-2000 was designed to provide continuous operation in the event of a failed disk. Hot-swapping a disk
drive is a simple process that does not require issuing commands or a GUI operation. To replace a disk drive, follow
this procedure:
1. Identify and verify the failed drive via the Grid Manager, front panel LCD, or CLI.
2. If the activity light is green or blinking yellow, make sure you have identified the correct drive. There are
conditions where a drive could be in the process of failing and still be green or yellow.
Note: Do not remove a correctly functioning drive
3. Push in the latch for the drive and pull the release lever out towards you.
4. When the drive disengages, slide it out of the slot.
Icon Color Meaning
Green The RAID array is functioning properly.
Yellow A new disk was inserted and the RAID array is rebuilding.
Red The RAID array is degraded. At least one disk is not functioning properly. The GUI lists the disks
that are online. Replace only the disks that are offline.
LED Color Condition Action
Green Disk operating normally None
Yellow Disk read/write activity Disk is functioning normally or is synchronizing if recently
inserted.
Dark Disk has failed or not inserted Verify the failure in the GUI or CLI. Remove the disk and
replace with a functional disk drive. Note that the drive
rebuilds with its twin.
Replacement drives are shipped as a complete unit, ready to insert into the appliance. There is no preparation
required. To install a replacement drive, follow this procedure:
1. Insert the replacement drive into the drive bay slot.
2. Gently slide the drive into place. When you feel the release lever engage, continue applying gentle pressure to
the drive while pushing the release lever towards the appliance.
3. The release lever locks into place and the LED next to the disk drive lights up. Note that if the alarm buzzer is
sounding, it automatically turns off about 20 seconds after the drive is inserted.
4. The disk drive automatically goes into rebuild mode.
Disk Array Guidelines
Infoblox has designed the disk array to be completely self managing. There are no maintenance procedures required
for a normally functioning disk array. Mishandling the disk array can cause an unrecoverable error that could result
in a failed appliance. Following are some guidelines for managing the disk array:
Only remove one disk at a time. Never remove two or more disks from the appliance at once. This rule includes a
powered down appliance.
There is no way to know the arrangement of the primary and backup disk drives in the RAID 10 array.
You can hot swap a drive while the appliance remains in production.
There is never a condition that requires you to power down the appliance or unmount a disk drive to replace a
failed unit.
If you inadvertently remove the wrong disk drive, do not immediately remove the disk drive you originally
intended to remove. Verify the status of the array before removing another drive. Removing a second drive could
render the appliance inoperable.
If a drive has failed, there is an audio alarm buzzer. The alarm automatically stops about 20 seconds after a
functional disk has been inserted into the array.
Only remove failed or failing disk drives. Never remove an optimally functioning drive.
In the unlikely event that two disk drives fail simultaneously and the appliance is still operational, remove and
replace the failed disk drives one at a time.
Rebuild time can vary. The rebuild process takes approximately two hours on an idle appliance. On very busy
appliances (over 90% utilization), the disk rebuild process can take as long as 40 hours. On a grid master
serving a very large grid, the rebuild process could take at least 24 hours.
If your acceptance procedures require a test of the RAID hot-swap features, any drive can be removed, but only
one disk drive at a time should be removed. Removing two disks has a 50% probability of an appliance failure.
Removing more than two disks results in an appliance failure and requires an RMA of the appliance.
Restarting Services
Whenever you make a change (such as add a zone, network, or a range) you click the Restart icon to restart services.
You can restart the DNS, DHCP, RADIUS, and VitalQIP services after you make configuration changes. You can also
specify a future restart time.
You can restart services at the grid level or the member level as described in:
Restarting Grid Services on page 156
Restarting Member Services on page 157
The following rules apply to superusers and limited-access users:
You can cancel a schedule that you create to restart services. A superuser can cancel any scheduled restarts.
Only a superuser or administrators with read and write permission to all of the grid members can schedule a
grid restart.
When a superuser schedules a grid restart, a limited-access user cannot schedule a member-level restart.
Limited-access users cannot cancel a superusers scheduled changes.
Limited-access users cannot create or modify a schedule for a grid member if a schedule for the member
(created by another user) already exists.
The system writes every scheduled change action to the audit log as follows:
USER l ogon_i d act i on ser vi ce r est ar t schedul e ' schedul e' on gr i d ( or member ) gr i d name
or member node i d
For example:
USER j doe i nser t ser vi ce r est ar t schedul e ' 02/ 20/ 2007 01: 30: 00' on gr i d I nf obl ox
USER j doe del et ed ser vi ce r est ar t schedul e ' 02/ 22/ 2007 01: 30: 00' on node i d 3
For more information on the audit log, see Using the Audit Log on page 170.
Restarting Grid Services
Only a superuser or administrators with read and write permission to all grid members can schedule a grid restart.
You can restart services at the grid level either simultaneously or sequentially, and also specify the restart services
time.
After you enter a specific date and time, the system schedules to restart services at the specified time on each grid
member, one by one. To restart services at the grid level:
1. Click the Restart Services icon.
The Restart Grid Services dialog box appears.
2. Enter the following in the Restart services on all members section:
Simultaneously: Restarts the services on all of the members in a grid at the same time.
Sequentially: This is the default option. Restarts the services on each grid member according to the
number of seconds you enter in the Sequential Delay field. For example, if you enter the sequential
delay as 10 seconds, the system restarts services on the first member, and 10 seconds later on the
second member.
3. Select one of the following options in the Restart services time section:
Immediately: Restarts services at once.
Scheduled: Enter the following information to schedule all grid members to restart at a certain date and
time:
Date: Enter the date on which the services should restart in MM/DD/YYYY (month/day/year)
format.
Time: Enter the time in hh:mm:ss (hours: minutes: seconds) format. Hours must be a numeric
value between 0 and 23. For example, if you make the change at 10:00 a.m. on Wednesday and
want the change to occur at 10:30 p.m., enter 22:30:00.
Restarting Services
Time Zone: Select a time zone from the drop-down menu. The drop-down menu displays the grid
default time (see Changing Time Zone Settings on page 117). However, you can select a different
time zone. For example, if the grid default time zone is Eastern time and you are in California, you
can schedule a restart in the Pacific time zone. Enter the date and time and select the Pacific time
zone and click the Save icon. When you invoke the GUI the next time, the system calculates the
time difference between the two time zones and displays the scheduled time in the grid default
time zone (Eastern time).
Note: The NIOS appliance converts the time zone to the grid default time zone only after you save and reinvoke
the GUI.
Click the Show Details button to view the following restart services details: IP address of the grid
members that are restarting, services that are restarting (such as DNS, DHCP, and RADIUS), the restart
date and time, and the time zone.
4. Click OK.
The Restart Services icon changes from the Infoblox logo to a clock to indicate that a
restart has been scheduled.
Restarting Member Services
The member restart time always supersedes the grid restart time. If the member restart time is later than the grid
restart time, then the member restarts services at its scheduled time. If the member restart time is ahead of the grid
restart time, then the member restarts services at its scheduled restart time, and again during the grid restart time.
To restart member services:
The Restart Member Services dialog box appears.
2. You can specify whether the member should restart services when necessary or you can force it to restart
services. Select one of the following under the Restart services section:
Restart services (if needed): This option restarts all active DNS, DHCP, RADIUS, and VitalQIP proxy
services if there are any changes requiring a service restart. To see which services are enabled and
must be restarted, click Show Details.
Force restart services: This option forces all active services to restart regardless of their state.
3. Select one of the following options in the Restart services time section:
Immediately: Restarts services instantly.
Scheduled: Enter the date, time, and select the time zone as follows:
Date: Specify the date on which the services should restart in MM/DD/YYYY (month/day/year)
format.
Time: Specify the time in hh:mm:ss (hours: minutes: seconds) format. Hours must be a numeric
value between 0 and 23. For example, if you make the change at 10:00 a.m. on Wednesday and
want the change to occur at 10:30 p.m., enter 22:30:00.
Time Zone: Select a time zone from the drop-down menu. The drop-down menu displays the
member default time zone (see Changing Time Zone Settings on page 117). But, you can select a
different time zone when you create the schedule. For example, if the member default time zone is
Eastern time and you are in California, you can schedule a restart in the Pacific time zone. Enter the
date and time and select the Pacific time zone and click the Save icon. When you invoke the GUI
the next time, the system calculates the time difference between the two time zones and displays
the scheduled time in the member default time zone (Eastern time).
Note: The NIOS appliance converts the time zone to the grid default time zone only after you save and reinvoke
the GUI.
Click the Show Details button to view the following restart services details: IP addresses of the
members that are restarting, services that are restarting (such as DNS, DHCP, and RADIUS), the restart
date and time, and the time zone.
The Restart Services icon changes from the Infoblox logo to a clock to indicate that a
restart has been scheduled.
Canceling a Scheduled Restart
Limited-access users can only cancel a schedule that they created. Superusers can cancel a schedule that any user
created. You can cancel scheduled changes for the grid only from the grid level and scheduled changes for the
member only from the member-level.
You can cancel a scheduled restart either by using the Manage Restart Services option or by resetting the restart
services time to Immediately (instead of selecting Scheduled) in the Restart Member Services dialog box.
Use the following steps to cancel a scheduled restart using the Manage Restart Services option. When you use this
option, the system cancels the schedule to restart services on the member or grid and does not restart services.
1. From the Grid or Device perspective, select the drop-down menu next to the clock icon in the GUI.
2. Select Manage Restart Services.
The Manage Grid Services dialog box or the Manage Device Services dialog box appears.
3. Click Cancel Restart.
The Cancel Schedule Warning message appears.
4. Click Yes and click OK.
The Restart Services icon in the GUI changes back from the clock icon to the Infoblox logo provided there is
no other scheduled restart.
Use the following steps to cancel a scheduled restart by resetting the restart services time. When you use this option,
the system cancels the scheduled restart and restarts the services on the member or the grid at once.
1. From the Grid or Device perspective, click the grid or the member.
2. Select the drop-down menu next to the clock icon in the GUI.
3. Select Restart Member Services or Restart Grid Services.
The Restart Member Services or Restart Grid Services dialog box appears.
4. Select Immediately in the Restart services time section and click OK.
The Cancel Schedule Warning message appears.
5. Click Yes and click OK.
The Restart Services icon in the GUI changes back from the clock icon to the Infoblox logo provided there is
no other scheduled restart.

Chapter 5 Monitoring the Appliance
This chapter describes the status icons in the Infoblox GUI that indicate the state of appliances, services, database
capacity, ethernet ports, HA, and grid replication. It also explains how to use the various logs and the traffic capture
tool to monitor a NIOS appliance. You can set the monitoring parameters at the grid and member levels.
The topics in this chapter include:
Viewing Detailed Status on page 160
Appliance Status on page 160
Service Status on page 160
DB Capacity Used on page 161
Disk Usage on page 161
HA, LAN, or MGMT Port on page 162
LCD on page 162
Memory Usage on page 162
Replication on page 163
Using a Syslog Server on page 165
Specifying Syslog Servers on page 165
Configuring Syslog for a Grid Member on page 166
Setting DNS Logging Categories on page 167
Viewing the Syslog on page 168
Searching for Text on page 168
Downloading the Syslog File on page 169
Monitoring Tools on page 170
Using the Audit Log on page 170
Using the Replication Log on page 172
Using the Traffic Capture Tool on page 173
Monitoring the Appliance
Viewing Detailed Status
The NIOS GUI changes the color of status icons to indicate the state of appliances, services, database capacity,
ethernet ports, HA, and grid replication. For the Infoblox-1552 and 2000, the GUI displays status icons for the power
supplies. For the Infoblox-2000, the GUI displays icons to indicate the state of the RAID array and disk controller
backup battery.
To see a detailed status report for a grid, from the Grid perspective, select grid, and then click View -> Detailed Status.
After displaying the Detailed Status panel, you can view the status of individual grid members and services by
selecting them in the Grid panel.
The Detailed Status panel provides a detailed status report on the following appliance and service operations:
Appliance Status
The status icons indicate the operational status of a grid member and a general description about what it is currently
doing. The appliance status icon can be one of the following colors:
Following are some appliance descriptions that might appear in the Description column: Running, Offline,
Connecting, Synchronizing, Authentication Failed, Shared secret did not match, Not Licensed, SW Revision Mismatch,
Downloading Release from Master, and Shutting Down.
Service Status
After you enable DHCP, DNS, HTTP (for file distribution), RADIUS, TFTP, or VitalQIP services, the Infoblox GUI indicates
its status with a green or red icon. Because the status icons for NTP have a different meaning, those meanings are
explained in a separate table.
DHCP, DNS, HTTP (File Distribution) , RADIUS, TFTP, or VitalQIP
Icon Color Meaning
Green The appliance is operating normally in a running state.
Yellow The appliance is connecting or synchronizing with its grid master.
Red The grid member is offline, is not licensed (that is, it does not have a DNSone license with the
Keystone upgrade that permits grid membership), is upgrading or downgrading, or is shutting
down.
Icon Color Meaning
Green A service is enabled and running properly.
Red A service is enabled but not running. (A red status icon can also appear temporarily when a
service is enabled and begins running, but the monitoring mechanism has not yet notified the
GUI engine.)
NTP
The type of information that can appear in the Description column for a service corresponds to SNMP trap messages.
DB Capacity Used
Status icons for DB Capacity Used indicate the current percentage of the database in use on a selected grid member.
The maximum is 100%.
Disk Usage
This indicates the percentage of the data partition on the hard disk drive currently in use.
FAN
The status icon indicates whether the fan(s) are functioning. The corresponding description displays the fan speed.
Icon Color Meaning
Green NTP is enabled and running properly.
Yellow (grid member) NTP is enabled and running properly on the grid master, but it is not running on
this member, although it is enabled on this member.
Red (grid master) NTP is enabled on the grid master, but it is not running on the master.
Icon Color Meaning
Green Under 85% database capacity is currently in use.
Yellow Over 85% database capacity is currently in use. When the capacity exceeds 85%, the icon
changes from green to yellow and the NIOS appliance sends an SNMP trap.
Icon Color Meaning
Green Under 85% capacity
Yellow Between 85% and 95% capacity
Red Over 95% capacity
Icon Color Meaning
Green All fans are functioning properly.
Red At least one fan is not running.
HA, LAN, or MGMT Port
The status icons for the HA, LAN/LAN1, and MGMT ethernet ports indicate the state of their network connectivity.
LCD
The LCD status icon indicates its operational status.
Memory Usage
The status icon for memory usage indicates the current percentage of memory in use.
Note: You can see more details about memory usage through the CLI command: show memor y
Power Supply
The Infoblox-1552 and Infoblox-2000 have redundant power supplies. The power supply icon indicates the
operational status of the power supplies.
Icon Color Meaning
Green The port is properly connected to a network. Its IP address appears in the Description column.
Red The port is not able to make a network connection.
Icon Color Meaning
Green The LCD is functioning properly.
Red The LCD process is not running.
Icon Color Meaning
Green Under 90% capacity
Yellow Between 90% and 95% capacity and increased activity
Red Over 95% capacity and increased activity
Icon Color Meaning
Green The power supplies are functioning properly.
Red One power supply is not running. To find out which power supply failed, check the LEDs of the
power supplies.
RAID
This icon indicates the status of the RAID array on the Infoblox-2000.
RAID Battery
This icon indicates the status of the disk controller backup battery on the Infoblox-2000.
Temperatures
This icon is always green. The description reports the CPU and system temperatures.
Replication
The current state of replication between a grid member and master or between the passive and active nodes in an HA
pair.
Grid Member <> Master
Icon Color Meaning
Green The RAID array is functioning properly.
Yellow A new disk was inserted and the RAID array is rebuilding.
Red The RAID array is degraded. At least one disk is not functioning properly. The GUI lists the disks
that are online. Replace only the disks that are offline.
Icon Color Meaning
Green The battery is charged. The description indicates the estimated number of hours of charge
remaining on the battery
Red The battery is not charged.
Icon Color Meaning
Green Grid communications are operating normally and ongoing database updates are occurring.
Yellow The member is synchronizing itself with the master, and either complete or partial database
replication is occurring. All master candidates receive the complete database. All regular
members (that is, members not configured as master candidates) receive the section of the
database that applies to themselves.
Red The member and master are not replicating the database between themselves.
HA Pair Passive Node <> Active Node
Icon Color Meaning
Green HA communications are operating normally and database replication is occurring.
Yellow The passive node is synchronizing itself with the active node, and database replication is
occurring.
Red The passive and active nodes are not replicating the database between themselves.
Using a Syslog Server
Syslog is a widely used mechanism for logging system events. NIOS appliances generate syslog messages which you
can view through the system log viewer and download to a directory on your management station. In addition, you
can configure a NIOS appliance to send the messages to one or more external syslog servers for later analysis. Syslog
messages provide information about appliance operations and processes. You can also include audit log messages
and specific BIND messages among the messages the appliance sends to the syslog server.
You can set syslog parameters at the grid and member levels. At the member level, you can override grid-level syslog
settings and enable syslog proxy.
The topics in this section include:
Specifying Syslog Servers on page 165
Configuring Syslog for a Grid Member on page 166
Setting DNS Logging Categories on page 167
Viewing the Syslog on page 168
Searching for Text on page 168
Downloading the Syslog File on page 169
Specifying Syslog Servers
To configure a NIOS appliance to send messages to a syslog server:
or
2. In the Grid or Device editor, click Monitoring, and then enter the following:
Syslog
In addition to storing the system log on a grid member, you can configure grid to send the log to an external
syslog server.
Override grid syslog settings: Select this check box to override grid-level settings and apply member-level
settings. Clear it to apply grid-level settings to this member. If Member Type is Riverbed, you must select
this check box to override grid-level settings. The appliance automatically configures the syslog size to
20MB for Riverbed members.
Syslog size (MBytes): Specify the maximum size of the syslog file. Enter a value from 10 to 300. The default
is 300MB.
When the syslog file reaches its maximum size, the appliance automatically writes the file into a new file by
adding a . 0 extension to the first file and incrementing subsequent file extensions by 1.
Enable external syslog server: Select this check box to enable the NIOS appliance to send messages to a
specified syslog server.
Syslog Server Group: To define one or more syslog servers, click Add, enter the following, and then click OK:
Server Address: Type the IP address of a syslog server.
Connection Type: Specify whether the appliance uses TCP or UDP to connect to the external syslog
server.
Port: Specify the destination port number.
Out Interface: Specify the interface through which the appliance sends syslog messages to the syslog
server.
Severity Filter: Choose a filter from the drop-down list. When you choose a severity level, grid members
send messages for that severity level plus all messages for all severity levels above it. The lowest
severity level is debug (at the top of the drop-down list), and the highest severity level is emerg (at the
bottom of the list). Accordingly, if you choose debug, grid members send all syslog messages to the
server. If you choose err, grid members send messages with the severity levels err, crit, alert, and
emerg. If you choose emerg, they send only emerg messages.
Message Source: Specify which syslog messages the appliance sends to the external syslog server:
Internal: The appliance sends syslog messages that it generates.
External: The appliance sends syslog messages that it receives from other devices, such as syslog
servers and routers.
Any: The appliance sends both internal and external syslog messages.
Copy audit log messages to syslog: Select the check box for the NIOS appliance to include audit log
messages among the messages it sends to the syslog server. This function can be helpful for monitoring
administrative activity on multiple appliances from a central location.
Audit Log Facility: Choose the facility where you want the syslog server to sort the audit log messages.
Configuring Syslog for a Grid Member
You can override grid-level syslog settings and enable syslog proxy for individual members. When you enable syslog
proxy, the member receives syslog messages from specified devices, such as syslog servers and routers, and then
forwards these messages to an external syslog server. You can also enable appliances to use TCP for sending syslog
messages. TCP is more reliable than using UDP; this reliability is important for security, accounting, and auditing
messages sent through syslog.
To configure syslog parameters for a member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Edit -> Member Properties.
2. In the Grid Member editor, click Monitoring, and enter the following:
Syslog
In addition to storing the system log on a grid member, you can configure a member to send the log to a syslog
server.
Override grid syslog settings: Select the check box to override grid-level settings and apply member-level
settings. Clear it to apply grid-level settings to this member. If Member Type is Riverbed, you must select
this check box to override grid-level settings. The appliance automatically configures the syslog size to
20MB for Riverbed members.
Syslog size (MBytes): Specify the maximum size of the syslog file. Enter a value from 10 to 300. The default
is 300MB.
When the syslog file reaches its maximum size, the appliance automatically writes the file into a new file by
adding a . 0 extension to the first file and incrementing subsequent file extensions by 1.
Enable external syslog server: Select this check box to enable the NIOS appliance to send messages to a
specified syslog server.
Syslog Server Group: To define one or more syslog servers, click Add, enter the following, and then click OK:
Server Address: Type the IP address of a syslog server.
Connection Type: Specify whether the appliance uses TCP or UDP to connect to the external syslog
server.
Port: Specify the destination port number.
Out Interface: Specify the interface through which the appliance sends syslog messages to the syslog
server.
Severity Filter: Choose a filter from the drop-down list. When you choose a severity level, the NIOS
appliance sends messages for that severity level plus all messages for all severity levels above it. The
lowest severity level is debug (at the top of the drop-down list), and the highest severity level is emerg
(at the bottom of the list). Accordingly, if you choose debug, the single appliance or active node in an
HA pair sends all syslog messages to the server. If you choose err, it sends messages with the
severity levels err, crit, alert, and emerg. If you choose emerg, it sends only emerg messages.
Message Source: Specify which syslog messages the appliance sends to the external syslog server:
Internal: The appliance sends syslog messages that it generates.
External: The appliance sends syslog messages that it receives from other devices.
Any: The appliance sends both internal and external syslog messages.
Enable syslog proxy: Select this check box to enable the appliance to receive syslog messages from other
devices, such as syslog servers and routers, and then forward these messages to an external syslog server.
Enable listening on TCP: Select this check box if the appliance uses TCP to receive messages from other
devices.
Port: Enter the number of the port through which the appliance receives syslog messages from other
devices.
Enable listening on UDP: Select this check box if the appliance uses UDP to to receive messages from other
devices.
Port: Enter the number of the port through which the appliance receives syslog messages from other
devices.
Proxy Client Access Control: Click Add, enter the following in the Access Control Item dialog box, and then
click OK:
IP Address option: Select IP Address if you are adding the IP address of an appliance or select Network
if you are adding the network address of a group of appliances.
Address: Enter the IP address of the appliance or network.
Subnet Mask: If you entered a network IP address, you must also enter its subnet mask.
Setting DNS Logging Categories
You can specify which of 14 BIND logging message categories you want syslog to capture, and furthermore, you can
filter these messages by severity. For information about severity types, refer to Using a Syslog Server on page 165.
To specify logging categories:
1. From the Grid perspective, click + (for grid ) -> + (for Services) -> DNS -> Service Properties.
or
From the Device perspective, click + (for hostname ) -> DNS -> Service Properties.
2. In the Grid DNS Properties editor, click Logging, and then enter the following:
Logging Facility: Select a facility from the drop-down list. This is the location on the syslog server to which
you want to sort the DNS logging messages.
Select one of more of these log categories:
Enable General: Records the BIND messages that are not specifically classified.
Enable Config: Records the configuration file parsing messages.
Enable DNSSEC: Records the DNSSEC-signed responses.
Enable Network: Records the network operation messages.
Enable Queries: Records the query response messages.
Enable Security: Records the approved and denied requests.
Enable Transfer-in: Records zone transfer messages from the remote name servers to the appliance.
Enable Transfer-out: Records zone transfer messages from the NIOS appliance to remote name servers.
Enable Update: Records the dynamic update instances.
Enable Resolver: Records the DNS resolution instances, including recursive queries from resolvers.
Enable Notify: Records the asynchronous zone change notification messages.
Enable Lame Servers: Records bad delegation instances.
Enable Database: Records BINDs internal database processes.
Enable Client: Records client requests.
Viewing the Syslog
In addition to saving syslog messages to a remote syslog server, a NIOS appliance also stores the system messages
locally. When the syslog file reaches its maximum size, which is 300 MB for Infoblox appliances and 20 MB for NIOS
virtual appliances, the appliance automatically writes the file into a new file by adding a . 0 extension to the first file
and incrementing subsequent file extensions by 1.
Files are compressed during the rotation process, adding a . gz extension following the numerical increment
(file. #. gz). The sequential incrementation goes from zero through nine. When the eleventh file is started, the first
log file (file. 0. gz) is deleted, and subsequent files are renumbered accordingly. For example, the current log file
moves to file. 0. gz, the previous file. 0. gz moves to file. 1. gz, and so on through file. 9. gz. A maximum of
10 log files (0-9) are kept.
To view syslog messages on a NIOS appliance:
1. From the Grid perspective, click + (for grid ) -> + (for Members) -> member -> File -> System Log -> ip_addr .
or
From the Device perspective, click hostname -> File -> System Log -> ip_addr .
Note: You can also right-click a grid member or independent appliance or HA pair, and then select System Log
-> ip_addr in the short-cut menu.
The appliance displays the syslog messages for the specified member.
2. To refresh the contents in the System Log File viewer, click View -> Refresh (or press the F5 key).
3. To delete the contents in the System Log File viewer, click View -> Clear. Note that only a superuser can clear the
syslog file.
Searching for Text
Instead of paging through the syslog messages to locate messages, you can limit the display to syslog messages with
certain text strings. To search for specified text strings:
or
2. Click the Search icon in the upper right corner of the System Log File viewer.
3. Enter the text string and then click Search.
The appliance displays the results of your search in a Search Results panel.
Downloading the Syslog File
You can download the syslog file to a specified directory, if you want to print and analyze it.
To download a syslog file:
or
2. Click the Download File icon in the upper right corner of the System Log File viewer, navigate to a directory where
you want to save it, optionally change the file name (the default names are node_1_sysLog.tar.gz and
node_2_sysLog.tar.gz ), and then click OK.
Monitoring Tools
You can view the audit log, the replication log, and the traffic capture tool in a grid or HA pair to monitor administrator
activity, and capture traffic for diagnostic purposes.
This section includes the following topics:
Using the Audit Log on page 170
Using the Replication Log on page 172
Using the Traffic Capture Tool on page 173
Using the Audit Log
The audit log contains a record of all Infoblox administrative activity. It provides detailed information on changes such
as:
Date and time stamp of the change. If you have different admin accounts with different time zone settings, the
appliance uses the time zone of the admin account that you use to log in to the appliance to display the date
and time stamp.
Administrator name
Changed object name
New value of the object. If you change multiple properties of an object, the audit log lists all changes in a
comma-separated log entry. You can also search the audit log to find the new value of an object.
The system logs the following successful operations:
Write operations such as add, modify, or remove objects.
System management operations such as restart service and reboot unit.
When the audit log reaches it maximum size, which is 100 MB, the appliance automatically writes the file into a new
file by adding a . 0 extension to the first file and incrementing subsequent file extensions by 1. Files are compressed
during the rotation process, adding a . gz extension following the numerical increment (file. #. gz). The sequential
incrementation goes from zero through nine. When the eleventh file is started, the first log file (file. 0. gz) is
deleted, and subsequent files are renumbered accordingly. For example, the current log file moves to file. 0. gz,
the previous file. 0. gz moves to file. 1. gz, and so on through file. 9. gz. A maximum of 10 log files (0-9) are
kept. To list the audit log files and their sizes, log in to the Infoblox CLI and execute the show l ogf i l es command.
To view the audit log:
From the Grid perspective, select grid -> File -> Audit Log.
or
From the Device perspective, select hostname -> File -> Audit Log .
You can also do the following:
To refresh the audit log view, select View -> Refresh (or press the F5 key).
To delete the contents of the audit log file, select View -> Clear.
You can search for audit logs that pertain to particular DNS and DHCP objects. To search the audit log file:
1. Click the Search icon in the upper right corner of the Audit Log File viewer.
2. In the Search Audit Log dialog box, enter the search criteria as follows:
Match Fields: In this section, you specify the fields the appliance uses to filter the Audit Log. Enter the following:
Admin Name: Enter the name of the administrator to view the Audit Log changes made only by a specific
administrator. The name you enter in this field need not be complete. You can use regular expressions to
expand your search. For example, you can just enter ad* or adm to search for the admin name
administrator. Also, the data you enter is not case sensitive.
Message/Value: Enter any word or sentence from the message to be searched or the value of the object that
was created, modified, or deleted. The data you enter is not case sensitive.
Monitoring Tools
The message you enter in this field need not be complete. You can use regular expressions to expand your
search. For example, to find messages with the word created, you can just enter cre or cre*.
For example, if you changed the Comment field for an authoritative zone from today is tuesday to today is
wednesday, the Audit Log displays this change in the Message column as follows:
comment Fr om: t oday i s t uesday To: t oday i s wednesday
In this case, you can search for the string today is wednesday but you cannot search for To: today is
wednesday.
You can also search based on the value of the object you changed. For example, if you change the end IP
address of a DHCP range from 10.0.20.0 to 10.0.30.0, you can enter 30 in the Message/Value field to find
the log for this change.
Object Restrictions: In this section, you can specify additional filter criteria to restrict the Audit Log search.
Object Type: This drop-down list displays the different types of objects that you can select for the search.
You can select No Object Type Restrictions to search all object types or you can select a specific object
type. When you select a specific object type, you can enter an object name.
Object Name: To restrict the search to a specific object, you can enter a name for the object type you
specified. You can enter a partial name and use regular expressions as well. For example, to find a DNS
object called test.com, you can just enter tes or te*.
Time Range
In this section, you can either select from a predefined time range or specify your own custom range. The
appliance uses the time zone that it automatically detects from the management system that the admin uses to
log in. Or you can override the time zone auto-detection feature at the admin and member level by specifying a
time zone.
For example, if you are in the Eastern Standard Time zone, then the time range section in the dialog displays the
Eastern Standard Time regardless of the grid time zone setting. If you change the time zone on your computer,
you must log out and then log back in to the NIOS appliance for the new time zone to take effect.
Predefined range: Select one of the following predefined date and time ranges from the drop-down menu:
All: Displays all audit log messages logged at all available dates and times.
Last Week: Displays all audit log activity that occurred one week before the current time.
Last Day: Displays audit log activity that occurred one day (24 hours) before the current time.
Last 12 Hours: Displays all audit log activity that occurred 12 hours before the current time.
Last 4 Hours: Displays audit log activity that occurred four hours before the current time.
Last Hour: Displays all audit log activity that occurred one hour before the current time.
Custom range: Click and select one of the following:
From: Either select Oldest message or click Specify and then enter the start date and time in the
year/month/date and hours:minutes:seconds format.
To: Either select Newest message or click Specify and then enter the end date and time in the
year/month/date and hours:minutes:seconds format.
3. Click Search
The appliance displays the results of your search in a Search Results panel.
To download the audit log file, click the Download File icon in the upper right corner of the Audit Log File viewer,
navigate to a directory where you want to save it, optionally change the file name (the default name is
auditLog.tar.gz ), and click OK.
Audit Log Format
The format of the audit log is similar to the syslog:
[ dat e and t i me st amp] [ user name] : message
For example:
[ 2007/ 05/ 05 11: 13: 54. 208] [ admi n] : updat ed gr i d t i me zone
Note: The dates and timestamps in the audit log are determined by the time zone setting of the admin account
that you use to log in to the NIOS appliance.
Specifying the Audit Log Type
Select either the Detailed (default) or Brief audit log type as follows:
1. Select Grid -> Edit -> Grid Properties.
2. Click the Grid Properties section to expand it.
3. Select one of the following types in the Audit Log section:
Detailed: This is the default type. It is automatically selected. It provides detailed information on all
administrative changes such as the date and time stamp of the change, administrator name, changed
object name, and the new values of all properties.
Brief: Provides information on administrative changes such as the date and time stamp of the change,
administrator name, and the changed object name. It does not show the new value of the object. The
following are examples of brief audit log messages:
[ 2007/ 06/ 08 12: 36: 35. 768] [ admi n] : Modi f i ed Admi nGr oup t est _gr oup
[ 2007/ 07/ 10 12: 39: 19. 424] [ admi n] : Del et ed Aut hZone t est . comvi ew=def aul t
Using the Replication Log
The Replication Status panel reports the status of the database replication between grid members and master. The
Replication Status panel reports the status of the database replication between grid members and master, and
between the two nodes in an independent HA pair. You can use this information to check the health of grid and HA
pair activity.
To view the replication log:
From the Grid perspective, click grid -> View -> Replication Status.
or
From the Device perspective, click hostname -> View -> Replication Status .
To refresh the contents in the Replication Log viewer, click View -> Refresh (or press the F5 key).
Monitoring Tools
Using the Traffic Capture Tool
You can capture the traffic on one or all of the ports on a NIOS appliance, and then view it using a third-party network
protocol analyzer application, such as the Ethereal Network Protocol Analyzer.
The NIOS appliance saves all the traffic it captures into a .cap file and compresses it into a .tar.gz file. Your
management system must have a utility that can extract the .tar file from the .gzip file, and an application that can
read the .cap (capture) file format. This section explains the process of first capturing traffic, and then downloading
it to your management system. After that, you can extract the traffic capture file and view it with a third-party traffic
analyzer application.
Note: The NIOS appliance always saves a traffic capture file as tcpdumpLog.tar.gz. If you want to download multiple
traffic capture files to the same location, rename each downloaded file before downloading the next.
1. From the Grid perspective, click -> + (for grid) -> + (for Members) -> member -> Tools -> Capture Traffic.
or
From the Device perspective, click hostname -> Tools -> Capture Traffic.
2. In the Traffic Capture dialog box, enter the following:
HA port: Select to capture all traffic that the HA port receives and transmits.
LAN port: Select to capture all traffic that the LAN port receives and transmits.
MGMT port: Select to capture all traffic that the MGMT port receives and transmits.
All ports (promiscuous mode not supported): Select to capture traffic addressed to all ports. Note that the
NIOS appliance only captures traffic that is addressed to it.
Seconds to run: Specify the number of seconds that you want the traffic capture tool to run.
Note: NIOS virtual appliances support capturing traffic only on the LAN port.
3. Click Start.
A message appears warning that the use of the traffic capture tool causes a decrease in network service
processing and prompts you to confirm your use of the tool.
4. Click Yes.
5. When you want to view the captured traffic, click Download.
6. Another message appears stating that clicking Download causes the traffic capture operation (if it is still ongoing)
to stop and asks if you want to proceed.
7. Click OK.
8. Navigate to where you want to save the file, rename it if you want, and then click OK or Save.
9. Use terminal window commands (Linux) or a software application (such as StuffIt or WinZip) to extract the
contents of the .tar.gz file.
10. When you see the traffic.cap file in the directory where you extracted the .tar.gz file, open it with the third-party
network protocol analyzer application.
Using the Capacity Report
You can view the capacity usage and object type information of an appliance in the Capacity Report panel. The
capacity report displays capacity and object type information of an independent appliance, a grid master, or a grid
member. For an HA pair, the report displays information that is on the active node.
The top half of the panel displays a capacity summary, and the bottom half displays the object types that the
appliance supports and the total counts for each object type.
To view the capacity report:
From the Grid perspective, click + (for grid) -> + (for Members) -> member -> View -> Capacity Report.
or
From the Device perspective, select hostname -> View -> Capacity Report.
The capacity summary contains the following information:
Name: The name of the appliance.
Role: The role of the appliance. The value can be Grid Master, Grid Master Candidate, Grid Member, or
Standalone.
Hardware Type: The type of hardware. For an HA pair, the report displays the hardware type for both the active
and passive nodes.
Maximum Capacity: The maximum number of objects that the appliance can support.
Total Objects: The total number of objects that are currently in the database.
% Capacity Used: The percentage of the capacity that is in use.
The report categorizes object types that you can manage through the NIOS appliance. For objects that are only used
for internal system operations, the report groups and shows them under the object type Other.
The report displays the following information for object types:
Object Type: The type of objects. For example, DHCP Lease, Admin Group, or PTR Record.
Total: The total number of objects for a specific object type.
You can print the object type information or export it to a CSV file. For information on printing the object types, see
Printing from the GUI on page 56; and for information on exporting to a CSV file, see Exporting Data on page 60.

NIOS 4.3r1 Infoblox Administrator Guide 175
Chapter 6 Monitoring with SNMP
This chapter describes how you can use SNMP (Simple Network Management Protocol) to monitor NIOS appliances
in your network. It contains the following topics:
Understanding SNMP on page 176
SNMP MIB Hierarchy on page 177
MIB Objects on page 178
Infoblox MIBs on page 179
Loading the Infoblox MIBs on page 179
ibTrap MIB on page 180
Interpreting Infoblox SNMP traps on page 181
Types of Traps (OID 3.1.1.1.1) on page 182
Trap Binding Variables (OID 3.1.1.1.2) on page 184
Trap Severity (OID 3.1.1.1.2.2.0) on page 185
ibProbableCause Values (OID 3.1.1.1.2.4.0) on page 186
ibSubsystemName Values (OID 3.1.1.1.2.9.0) on page 187
ibPreviousState (OID 3.1.1.1.2.9.0) and ibCurrentState (OID 3.1.1.1.2.10.0) on page 188
ibTrapDesc (OID 3.1.1.1.2.11.0) on page 189
ibPlatformOne MIB on page 202
ibDHCPOne MIB on page 207
ibDNSOne MIB on page 210
ibIPWC MIB on page 212
Configuring SNMP on page 217
Accepting SNMP Queries on page 217
Setting System Information on page 217
Adding SNMP Trap Receivers on page 218
Configuring SNMP for a Grid Member on page 218
Click the Save icon to save your settings. on page 218
Monitoring with SNMP
Understanding SNMP
You can use SNMP (Simple Network Management Protocol) to manage network devices and monitor their processes.
An SNMP-managed device, such as a NIOS appliance, has an SNMP agent that collects data and stores them as
objects in MIBs (Management Information Bases). The SNMP agent can also send traps (or notifications) to alert you
when certain events occur within the appliance or on the network. You can view data in the SNMP MIBs and receive
SNMP traps on a management system running an SNMP management application, such as HP OpenView, IBM Tivoli
NetView, or any of the freely available or commercial SNMP management applications on the Internet.
Figure 6.1 SNMP Overview
You can configure a NIOS appliance as an SNMP-managed device. NIOS appliances support SNMP versions 1 and 2,
and adhere to the following RFCs:
RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management
Frameworks
RFC 3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
RFC 3413, Simple Network Management Protocol (SNMP) Applications
RFC 3416, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
RFC 3418, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
RFC 1155, Structure and identification of Management information for TCP/IP-based internets
RFC 1213, Management Information Base for Network Management of TCP/IP-based internets:MIB-II
Traps
Queries
SNMP Management System
Agent
MIB
MIB
MIB
MIB
MIB
NIOS Appliance
SNMP MIB Hierarchy
SNMP MIB Hierarchy
Infoblox supports the standard MIBs defined in RFC-1213, Management Information Base for Network Management
of TCP/IP-based internets: MIB-II, in addition to implementing its own enterprise MIBs. The Infoblox MIBs are part of
a universal hierarchical structure, usually referred to as the MIB tree. The MIB tree has an unlabeled root with three
subtrees. Figure 6.2 illustrates the branch of the MIB tree that leads to the Infoblox enterprise MIBs. Each object in
the MIB tree has a label that consists of a textual description and an OID (object identifier). An OID is a unique
dotted-decimal number that identifies the location of the object in the MIB tree. Note that all OIDs begin with a dot
(.) to indicate the root of the MIB tree.
As shown in Figure 6.2, Infoblox is a branch of the Enterprise subtree. IANA (Internet Assigned Numbers Authority)
administers the Enterprise subtree, which is designated specifically for vendors who define their own MIBs. The
IANA-assigned enterprise number of Infoblox is 7779; therefore, the OIDs of all Infoblox MIB objects begin with the
prefix .1.3.6.1.4.1.7779.
The Infoblox SNMP subtree branches down through two levels, ibProduct and ibOne, to the Infoblox MIBs: ibTrap,
ibPlatformOne, ibDNSone, and ibDHCPOne. The ibTrap MIB defines the traps that NIOS appliances send, and the
ibPlatformOne, ibDNSone, and ibDHCPOne MIBs provide information about the appliance. For detailed information
about these MIBS, see Infoblox MIBs on page 179.
Figure 6.2 MIB Hierarchy
(.1.3.6.1)
Internet
(.1.3.6)
U.S. Department of Defense (DOD)
(.1.3.6.1.4)
Private
(.1.3.6.1.4.1)
Enterprise
(.1.3.6.1.4.1.7779)
Infoblox
(.1)
International Organization
for Standardization (ISO)
(.1.3)
ORG
(.1.3.6.1.4.1.7779.3)
Infoblox SNMP Tree
(.1.3.6.1.4.1.7779.3.1)
ibProduct
(.1.3.6.1.4.1.7779.3.1.1)
ibOne
(.1.3.6.1.4.1.7779.3.1.1.1)
ibTrap
(.1.3.6.1.4.1.7779.3.1.12)
ibPlatformOne
(.1.3.6.1.4.1.7779.3.1.1.3)
ibDNSOne
(.1.3.6.1.4.1.7779.3.1.1.4)
ibDHCPOne
(.0)
International Telegraph and
Telephone Consultative Committee
(CCITT)
(.0)
CCITT and ISO
MIB Objects
The Infoblox MIB objects were implemented according to the guidelines in RFCs 1155 and 2578. They specify two
types of macros for defining MIB objects: OBJECT-TYPE and NOTIFICATION-TYPE. These macros contain clauses that
describe the characteristics of an object, such as its syntax and its status. OBJECT-TYPE macros describe MIB objects,
and NOTIFICATION-TYPE macros describe objects used in SNMP traps.
Each object in the ibPlatformOne, ibDNSone, and ibDHCPOne MIBs contains the following clauses from the
OBJECT-TYPE macro:
OBJECT-TYPE: Provides the administratively-assigned name of the object.
SYNTAX: Identifies the data structure of the object, such as integers, counters, and octet strings.
MAX-ACCESS: Identifies the type of access that a management station has to the object. All Infoblox MIB objects
provide read-only access.
STATUS: Identifies the status of the object. Values are current, obsolete, and deprecated.
DESCRIPTION: Provides a textual description of the object.
INDEX or AUGMENTS: An object that represents a conceptual row must have either an INDEX or AUGMENTS
clause that defines a key for selecting a row in a table.
OID: The dotted decimal object identifier that defines the location of the object in the universal MIB tree.
The ibTrap MIB defines the SNMP traps that a NIOS appliance can send. Each object in the ibTrap MIB contains the
following clauses from the NOTIFICATION-TYPE macro:
NOTIFICATION-TYPE: Provides the administratively-assigned name of the object.
OBJECTS: Provides an ordered list of MIB objects that are in the trap.
STATUS: Identifies the status of the object. Values are current, obsolete, and deprecated.
DESCRIPTION: Provides the notification information.
Infoblox MIBs
Infoblox MIBs
You can configure a NIOS appliance as an SNMP-managed device so that an SNMP management station can send
queries to the appliance and retrieve information from its MIBs. Perform the following tasks to access the Infoblox
MIBs:
1. Configure a NIOS appliance to accept queries, as described in Accepting SNMP Queries on page 217.
2. Load the MIB files onto the management system. To obtain the latest Infoblox MIB files:
a. From the Grid Perspective, select id_grid -> Tools -> Download SNMP MIBs.
b. In the Save As dialog box, navigate to a directory to which you want to save the MIBs.
c. Click Save.
3. Use a MIB browser or SNMP management application to query the objects in each MIB.
The NIOS appliance allows read-only access to the MIBs. This is equivalent to the Get and Get Next operations in
SNMP.
Loading the Infoblox MIBs
If you are using an SNMP manager toolkit with strict dependency checking, you must download the following Infoblox
MIBs in the order they are listed:
1. IB-SMI-MIB.txt
2. IB-TRAP-MIB.txt
3. IB-PLATFORMONE-MIB.txt
4. IB-DNSONE-MIB.txt
5. IB-DHCPONE-MIB.txt
6. IB-IPWC-MIB.txt (if you use the Infoblox IPAM WinConnect service)
In addition, if the SNMP manager toolkit the you use requires a different MIB file naming convention, you can rename
the MIB files accordingly.
NET-SNMP MIBs
NIOS appliances support NET-SNMP (formerly UCD-SNMP), a collection of applications used to implement the SNMP
protocol. When you download the Infoblox MIBs from the Infoblox Support site, you can download some of the
NET-SNMP MIBs and load them onto your SNMP management system. The NET-SNMP MIBs provide the top-level
infrastructure for the SNMP MIB tree. They define, among other things, the objects in the SNMP traps that the agent
sends when the SNMP engine starts and stops. For additional information on NET-SNMP and the MIB files distributed
with NET-SNMP, refer to http://net-snmp.sourceforge.net/.
RADIUS MIBs
The NIOS appliance supports the RADIUS-ACC-SERVER-MIB and RADIUS-AUTH-SERVER-MIB. You can download these
MIBs along with the Infoblox enterprise MIBs. When you install the RADIUS server license on the appliance and
configure RADIUS services, the appliance responds to queries for data from the RADIUS MIBs, if configured to do so.
For information on these MIBs, refer to RFC 2619, RADIUS Authentication Server MIB and RFC 2621, RADIUS
Accounting Server MIB.
ibTrap MIB
NIOS appliances send SNMP traps when events, internal process failures, or critical service failures occur. The ibTrap
MIB defines the types of traps that a NIOS appliance sends and the value that each MIB object represents. The
Infoblox SNMP traps report objects which the ibTrap MIB defines. Figure 6.3 illustrates the ibTrap MIB structure. It
provides the OID and textual description for each object.
Note: OIDs shown in the illustrations and tables in this section do not include the prefix .1.3.6.1.4.1.7779.
The ibTrap MIB comprises two trees, ibTrapOneModule and ibNotificationVarBind. The ibTraponeModule tree
contains objects for the types of traps that a NIOS appliance sends. The ibNotificationVarBind tree contains objects
that the Infoblox SNMP traps report. You cannot send queries for the objects in this MIB module. The objects are used
only in the SNMP traps.
Figure 6.3 ibTrapOne MIB Structure
(3.1.1.1) ibTrap MIB
(3.1.1.1.1)
ibTrapOneModule
(3.1.1.1.2)
ibNotificationVarBind
(3.1.1.1.1.1.0)
ibEquipmentFailureTrap
(3.1.1.1.1.2.0)
ibProcessingFailureTrap
(3.1.1.1.1.3.0)
ibThresholdCrossingEvent
(3.1.1.1.1.4.0)
ibStateChangeEvent
(3.1.1.1.1.5.0)
ibProcStartStopTrap
(3.1.1.1.2.1.0)
ibNodeName
(3.1.1.1.2.2.0)
ibTrapSeverity
(3.1.1.1.2.3.0)
ibObjectName
(3.1.1.1.2.4.0)
ibProbableCause
(3.1.1.1.2.5.0)
ibSubsystemName
(3.1.1.1.2.6.0)
ibCurThresholdValue
(3.1.1.1.2.7.0)
ibThresholdHigh
(3.1.1.1.2.8.0)
ibThresholdLow
(3.1.1.1.2.9.0)
ibPreviousState
(3.1.1.1.2.10.0)
ibCurrentState
(3.1.1.1.2.11.0)
ibTrapDesc
Infoblox MIBs
Interpreting Infoblox SNMP traps
Depending on the SNMP management application that your management system uses, the SNMP traps that you
receive might list the OIDs for all relevant MIB objects from both the ibTrapOneModule and ibNotificationVarBind
trees. For OIDs that have string values, the trap lists the text. For OIDs that contain integers, you can use the tables in
this section to find out the values. Some SNMP management applications list only the object name and the
corresponding values in the SNMP trap. Whether your SNMP management application lists OIDs or not, you can use
the tables in this section to find out the corresponding values and definitions for each MIB object.
The following is a sample trap that a NIOS appliance sends:
418: J an 31 18: 52: 26 ( none) snmpt r apd[ 6087] : 2008- 01- 31 18: 52: 26 10. 35. 1. 156 [ UDP:
[ 10. 35. 1. 156] : 32772] : DI SMAN- EVENT- MI B: : sysUpTi meI nst ance = Ti met i cks: ( 1080)
0: 00: 10. 80 SNMPv2- MI B: : snmpTr apOI D. 0 = OI D: SNMPv2- SMI : : ent er pr i ses. 7779. 3. 1. 1. 1. 1. 4. 0
SNMPv2- SMI : : ent er pr i ses. 7779. 3. 1. 1. 1. 2. 1. 0 = STRI NG: " 10. 35. 1. 156"
SNMPv2- SMI : : ent er pr i ses.
7779. 3. 1. 1. 1. 2. 3. 0 = STRI NG: " nt p_sync" SNMPv2- SMI : : ent er pr i ses. 7779. 3. 1. 1. 1. 2. 9. 0 =
I NTEGER: 15 SNMPv2- SMI : : ent er pr i ses. 7779. 3. 1. 1. 1. 2. 10. 0 = I NTEGER: 16
SNMPv2- SMI : : ent er pr i ses. 7779. 3. 1. 1. 1. 2. 11. 0 = STRI NG: " The NTP ser vi ce i s out of
synchr oni zat i on. "
The sample trap lists the OIDs and their corresponding values that can help you identify the cause of the event or
problem. You can find the definition for each OID or object and its value using the tables in this section. To identify
possible cause and recommended actions for the trap, use the ibTrapDesc tables. For information, see ibTrapDesc
(OID 3.1.1.1.2.11.0) on page 189.
You can interpret the sample trap as follows:
Using the ibTrapOneModule table, you find out that OID 7779.3.1.1.1.1.4.0 represents an Object State Change
trap. This type of trap includes the following objects. For each object, the trap displays the OID and its
corresponding value. The following is how you can interpret the rest of the trap:
ibNodeName (OID 7779.3.1.1.1.2.1.0)
Using the ibNotificationVarBind (OID 3.1.1.1.2) table, you find out that OID 7779.3.1.1.1.2.1.0
represents the MIB object ibNodeName, which is the IP address of the appliance on which the trap
occurred. Therefore, the statement 7779. 3. 1. 1. 1. 2. 1. 0 = STRI NG: " 10. 35. 1. 156"
SNMPv2- SMI : : ent er pr i ses. tells you that the IP address of the appliance on which the trap
occurred has an IP address of 10.35.1.156.
ibObjectName (OID 7779.3.1.1.1.2.3.0)
The statement 7779. 3. 1. 1. 1. 2. 3. 0 = STRI NG: " nt p_sync"
SNMPv2- SMI : : ent er pr i ses. tells you that the MIB object ibOjectName, which is the name of
the object for which the trap was generated, has a value of ntp_sync, which represents NTP
synchronization issues.
ibPreviousState (OID 7779.3.1.1.1.2.9.0)
The statement 7779. 3. 1. 1. 1. 2. 9. 0 = I NTEGER: 15 SNMPv2- SMI : : ent er pr i ses. tells
you that the MIB object ibPreviousState, which indicates the previous state of the appliance, has a
value of 15. Using the ibPreviousState and ibCurrentState Values table, you know that 15
represents ntp-sync-up, which means that the NTP server was up and running.
ibCurrentState (OID 7779.3.1.1.1.2.10.0)
The statement 7779. 3. 1. 1. 1. 2. 10. 0 = I NTEGER: 16 SNMPv2- SMI : : ent er pr i ses. tells
you that the MIB object ibCurrentState, which indicates the current state of the appliance, has a
value of 16. Using the ibPreviousState and ibCurrentState Values table, you know that 16
represents ntp-sync-down, which means that the NTP server is now out of sync.
ibTrapDesc (OID 7779.3.1.1.1.2.11.0)
The last statement 7779. 3. 1. 1. 1. 2. 11. 0 = STRI NG: " The NTP ser vi ce i s out of
synchr oni zat i on. " states the description of the trap. Using the Object State Change Traps table
for ibTrapDesc, you can find out the details of the trap description and recommended actions for
this problem.
Types of Traps (OID 3.1.1.1.1)
ibTrapOneModule defines the types of traps that the NIOS appliance can send. There are five types of SNMP traps.
Table 6.1 describe the types of traps and their objects in the ibTrapOneModule tree.
Table 6.1 ibTrapOneModule
OID Trap Type MIB Object Description
3.1.1.1.1.1.0 Equipment
Failure
ibEquipmentFailureTrap The NIOS appliance generates this trap when a
hardware failure occurs. This trap includes the
following objects:
ibNodeName
ibTrapSevertiy
ibObjectName (equipment name)
ibProbableCause
ibTrapDesc
For a list of trap descriptions for this type of trap,
see Equipment Failure Traps on page 189.
3.1.1.1.1.2.0 Processing and
Software
Failure
ibProcessingFailureTrap The NIOS appliance generates this trap when a
failure occurs in one of the software processes. This
trap includes the following objects:
ibNodeName
ibTrapSeverity
ibSubsystemName
ibProbableCause
ibTrapDesc
see Processing and Software Failure Traps on page
190.
3.1.1.1.1.3.0 Threshold
Crossing
ibThresholdCrossingEvent The NIOS appliance generates this trap when any of
the following events occur:
System memory or disk usage exceeds 90%.
A problem occurs when the grid master
replicates its database to its grid members.
DHCP address usage crosses a watermark
threshold. For more information about tracking
IP address usage, see Chapter 18, Managing
IP Data IPAM, on page 557.
This trap includes the following objects:
ibNodeName
ibObjectName (threshold name)
ibCurThresholdvalue
ibThresholdHigh
ibThresholdLow
ibTrapDesc
see Threshold Crossing Traps on page 195.
Infoblox MIBs
3.1.1.1.1.4.0 Object State
Change
ibStateChangeEvent The NIOS appliance generates this trap when there
is a change in its state, such as:
The link to one of the configured ports goes
down, and then goes back up again.
A failover occurs in an HA (high availability)
pair configuration.
A member connects to the grid master.
An appliance in a grid goes offline.
ibNodeName
ibObjectName
ibPreviousState
ibCurrentState
ibTrapDesc
For a list of possible trap descriptions for this type
of trap, see Object State Change Traps on page
199.
3.1.1.1.1.5.0 Process Started
and Stopped
ibProcStartStopTrap The NIOS appliance generates this type of trap
when any of the following events occur:
When you enable HTTP redirection.
When you change the HTTP access setting.
When you change the HTTP session time out
setting.
When a failover occurs in an HA pair
configuration.
ibNodeName
ibSubsystemName
ibTrapDesc
For a list of possible trap descriptions for this type
of trap, see Process Started and Stopped Traps on
page 201.
OID Trap Type MIB Object Description
Trap Binding Variables (OID 3.1.1.1.2)
Each SNMP trap contains information about the event or the problem. The Infoblox SNMP traps include MIB objects
and their corresponding values from the ibNotificationVarBind module. Table 6.2 describes the objects in the
ibNotificationVarBind module.
Table 6.2 ibNotificationVarBind (OID 3.1.1.1.2)
Note: The OIDs shown in the following table do not include the prefix .1.3.6.1.4.1.7779..
OID MIB Object Description
3.1.1.1.2.1.0 ibNodeName The IP address of the appliance on which the trap occurs. This may or
may not be the same as the appliance that sends the trap. This object
is used in all types of traps.
3.1.1.1.2.2.0 ibTrapSeverity The severity of the trap. There are five levels of severity. See Trap
Severity (OID 3.1.1.1.2.2.0) on page 185 for details.
3.1.1.1.2.3.0 ibObjectName The name of the object for which the trap was generated. This is used
in the Equipment Failure traps, Threshold Crossing traps, and the
Object State Change traps. The following shows what this object
represents depending on the type of traps:
Equipment Failure traps: The equipment name.
Threshold Crossing traps: The threshold name.
State Change traps: The object that changes state.
3.1.1.1.2.4.0 ibProbableCause The probable cause of the trap. See ibProbableCause Values on page
186 for the definitions of each value.
3.1.1.1.2.5.0 ibSubsystemName The subsystem for which the trap was generated, such as NTP or
SNMP. This object is used in the Processing and Software Failure traps
and the Process Start and Stop traps. See ibSubsystemName Values
(OID 3.1.1.1.2.9.0) on page 187 for definitions of each value.
3.1.1.1.2.6.0 ibCurThresholdValue The current value of the threshold counter. This object is used in the
Threshold Crossing traps.
3.1.1.1.2.7.0 ibThresholdHigh The value for the high watermark. This only applies when the
appliance sends a trap to indicate that DHCP address usage is above
the configured high watermark value for a DHCP address range. This
object is used in Threshold Crossing traps. For additional information,
see Setting Watermark Properties on page 567.
3.1.1.1.2.8.0 ibThresholdLow The value for the low watermark. This only applies when the
appliance sends a trap to indicate that DHCP address usage went
below the configured low watermark value for a DHCP address range.
This object is used in Threshold Crossing traps. For additional
information, see Setting Watermark Properties on page 567.
3.1.1.1.2.9.0 ibPreviousState The previous state of the appliance. This object is used in the Object
State Change traps. See ibPreviousState (OID 3.1.1.1.2.9.0) and
ibCurrentState (OID 3.1.1.1.2.10.0) on page 188 for definitions of
each value.
Infoblox MIBs
Trap Severity (OID 3.1.1.1.2.2.0)
The object ibTrapSeverity defines the severity level for each Infoblox SNMP trap. There are five levels of severity.
3.1.1.1.2.10.0 ibCurrentState The current state of the appliance. This object is used in the Object
State Change traps. See ibPreviousState (OID 3.1.1.1.2.9.0) and
ibCurrentState (OID 3.1.1.1.2.10.0) on page 188 for the definition of
each value.
3.1.1.1.2.11.0 ibTrapDesc The description of the trap. This object is used in all types of traps.
See ibTrapDesc (OID 3.1.1.1.2.11.0) on page 189 for the description,
possible cause, and recommended actions for each Infoblox SNMP
trap.
Value Description
1 Undetermined
2 Informational: Event that requires no further
action.
3 Minor: Event that does not require user
intervention.
4 Major: Event that requires user intervention
and assistance from Infoblox Technical
Support.
5 Critical: Problem that affects services and
system operations, and requires assistance
from Infoblox Technical Support.
OID MIB Object Description
ibProbableCause Values (OID 3.1.1.1.2.4.0)
Table 6.4 lists the values that are associated with the object ibProbableCause (OID 3.1.1.1.2.4.0). These values
provide information about the events, such as software failures, that trigger traps.
Table 6.3 ibProbableCause Values
Value
OID 3.1.1.2.4.0
ibProbableCause
0 ibClear
1 ibUnknown
2 ibPrimaryDiskFailure
3 ibFanFailure-old
4 ibPowerSupplyFailure
5 ibDBFailure
6 ibApacheSoftwareFailure
7 ibSerialConsoleFailure
11 ibControldSoftwareFailure
12 ibUpgradeFailure
13 ibSNMPDFailure
15 ibSSHDSoftwareFailure
16 ibNTPDSoftwareFailure
17 ibClusterdSoftwareFailure
18 ibLCDSoftwareFailure
19 ibDHCPdSoftwareFailure
20 ibNamedSoftwareFailure
23 ibRadiusdSoftwareFailure
24 ibNTLMSoftwareFailure
25 ibNetBIOSDaemonFailure
26 ibWindowBindDaemonFailure
27 ibTFTPDSoftwareFailure
28 ibQIPRemoteServerSoftwareFailure
29 ibBackupSoftwareFailure
30 ibBackupDatabaseSoftwareFailure
31 ibBackupModuleSoftwareFailure
32 ibBackupSizeSoftwareFailure
33 ibBackupLockSoftwareFailure
34 ibHTTPFileDistSoftwareFailure
Infoblox MIBs
ibSubsystemName Values (OID 3.1.1.1.2.9.0)
Table 6.4 lists the values that are associated with the object ibSubsystemName (OID 3.1.1.1.2.9.0). These values
provide information about the subsystems that trigger the traps.
Table 6.4 ibSubsystemName Values
35 ibOSPFSoftwareFailure
36 ibAuthDHCPNamedSoftwareFailure
37 ibFan1Failure
38 ibFan2Failure
39 ibFan3Failure
40 ibFan1OK
41 ibFan2OK
42 ibFan3OK
43 ibIPWCSoftwareFailure
44 ibFTPDSoftwareFailure
3001 ibRAIDIsOptimal
3002 ibRAIDIsDegraded
3003 ibRAIDIsRebuilding
3004 ibRAIDStatusUnknown
3005 ibRAIDBatteryIsOK
3006 ibRAIDBatteryFailed
Value
OID 3.1.1.1.2.9.0
ibSubsystemName
0 Uses the original ibObjectName and
ibSubsystemName when the trap is cleared.
1 N/A
2 N/A
3 N/A
4 N/A
5 Db_jnld
6 httpd
7 serial_console
11 controld
Value
OID 3.1.1.2.4.0
ibProbableCause
ibPreviousState (OID 3.1.1.1.2.9.0) and ibCurrentState (OID 3.1.1.1.2.10.0)
The ibPreviousState object indicates the state of the appliance before the event triggered the trap. The ibCurrentState
object indicates the current state of the appliance. Table 6.5 shows the message and description for each state.
Table 6.5 ibPreviousState and ibCurrentState Values
12 N/A
13 Snmpd
15 Sshd
16 Ntpd
17 Clusterd
18 Lcd
19 Dhcpd
20 Named
23 Radiusd
24 NTLM
25 Netbiosd
26 Winbindd
27 Tftpd
28 QIP
29 N/A
30 N/A
31 N/A
32 N/A
33 N/A
34 HTTPd
35 OSPF
Value Description Definition
1 ha-active The HA pair is in ACTIVE state.
2 ha-passive The HA pair is in PASSIVE state.
3 ha-initial The HA pair is in INITIAL state.
4 grid-connected The appliance is connected to the grid.
5 grid-disconnected The appliance is not connected to the grid.
6 enet-link-up The ethernet port link is active.
Value
OID 3.1.1.1.2.9.0
ibSubsystemName
Infoblox MIBs
ibTrapDesc (OID 3.1.1.1.2.11.0)
The ibTrapDesc object lists the trap messages of all Infoblox SNMP traps. This section lists all the SNMP traps by their
trap types. Each trap table describes the trap message, severity, cause, and recommended actions.
Equipment Failure Traps
7 enet-link-down The ethernet port link is inactive.
8 replication-online The replication is online.
9 replication-offline The replication is offline.
10 replication-snapshotting The replication is snapshotting.
11 service-up The service is up.
12 service-down The service is down.
13 ha-replication-online The HA pair replication is online.
14 ha-replication-offline The HA pair replication is offline.
15 ntp-syn-up The NTP server is synchronizing.
16 ntp-syn-down The NTP server is out of sync.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Description/Cause Recommended Actions
Primary Drive Full
Primary drive is full. Major The primary disk drive
reached 100% of usage.
1. Review the syslog file to identify the
possible cause of this problem.
2. Contact Infoblox Technical Support for
assistance.
Fan Monitoring
Fan <n> failure has
occurred.
Minor The specified fan failed.
The fan number <n> can
be 1, 2, or 3.
Inspect the specified fan for mechanical or
electrical problems.
Fan <n> is OK. Informational The specified fan is
functioning properly. The
fan number <n> can be 1,
2, or 3.
No action is required.
Power Supply Failure: monitored at 1 minute
A power supply
failure has occurred.
Major The power supply failed. 1. Inspect the power supply for the
possible cause of the failure.
assistance.
Value Description Definition
Processing and Software Failure Traps
RAID monitoring, at 1 minute interval
A RAID battery failure
has occurred.
Major The system RAID battery
failed. The alert light is
red.
1. Inspect the battery for the possible
cause of the failure.
assistance.
The systems RAID
battery is OK.
Informational The system RAID battery
is charging and
functioning properly. The
alert light changed from
red to green.
Unable to retrieve
RAID array state!
Undetermined The appliance failed to
retrieve the RAID array
state. The alert light is
red.
assistance.
The systems RAID
array is now running
in an optimal state.
Informational The RAID system is
functioning at an optimal
state.
The systems RAID
array is in a
degraded state.
Major The RAID system is
degrading.
assistance.
The systems RAID
array is rebuilding.
Minor The RAID system is
rebuilding.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Named Daemon Failure
A named daemon
monitoring failure
has occurred.
Critical The named process
failed.
assistance.
DHCP Daemon Failure
A DHCP daemon
monitoring failure
has occurred.
Critical The dhcpd process failed. 1. Review the syslog file to identify the
assistance.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Infoblox MIBs
VitalQIP Remote Server Failure
A VitalQIP remote
server failure has
occurred.
Critical The qip-msgd or the
qip-rmtd process failed.
assistance.
SSH Daemon Failure
An SSH daemon
Major The sshd process failed.
assistance.
NTP Daemon Failure, monitored every 10 minutes
An NTP daemon
Major The ntpd process failed.
assistance.
Cluster Daemon Failure
A cluster daemon
Critical The clusterd process
failed.
assistance.
LCD Daemon Failure
An LCD daemon
Major The LCD process failed.
The alert light is yellow.
1. Inspect the LCD panel for the possible
cause of this problem.
assistance.
Apache Software httpd failure, monitored every 2 minutes
An Apache software
Critical The request to monitor
the Apache server failed.
assistance.
Serial Console Failure
An Infoblox serial
console software
Major The Infoblox serial
console failed.
assistance.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Controld Software Failure
A controld failure has
occurred.
Critical The controld process
failed.
assistance.
SNMP Sub-agent Failure
An SNMP server
Major The one-subagent
process failed.
assistance.
TFTPD and FTPD Failure
A TFTPD daemon
Critical The tftpd process failed.
assistance.
An FTPD daemon
Critical The ftpd process failed.
assistance.
HTTP File Distribution, monitored at 10 second intervals
An HTTP file
distribution daemon
Critical The HTTP file distribution
process failed.
assistance.
auth_named Process Failure
An auth named
server failure has
occurred.
Critical The auth_named server
failed.
assistance.
IPWC Processes, monitored at 30 second intervals for IB-250 and 10 second intervals for other appliances
An IPAM WinConnect
server failure has
occurred.
Critical The IPWC (IPAM
WinConnect) 6server
failed.
assistance.
DNS ONE quagga Processes (zebra & ospfd)
An OSPF routing
daemon failure has
occurred.
Critical Either the zebra process
or the ospfd process
failed.
assistance.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Infoblox MIBs
radiusd Monitoring
A RADIUS daemon
monitoring failure
has occurred.
Critical The radiusd process
failed.
assistance.
Backup Failure
Backup failed. Not
implemented.
The backup failed.
One of the following
could be the cause of the
failure:
The appliance could
not access a backup
directory.
The IPAM
WinConnect backup
failed.
The backup was
interrupted by one of
the following signals:
SIGINT, SIGHUP, or
SIGTERM.
Incorrect login or
connection failure in
an FTP backup.
The backup failed to
create temporary
files.
assistance.
Database Backup Failure
Database backup
failed.
Not
implemented.
The db_dump process
failed.
assistance.
Backup Module Failure
Module backup
failed.
Not
implemented.
The backup of product-
specific files failed.
assistance.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Backup File Size Exceeded
File size exceeded
the quota. Backup
failed.
Not
implemented.
The backup failed
because the file size
exceeded the limit of
5GB.
Limit the size of the backup file to less than
5GB.
Another backup is in
progress. Backup will
not be performed.
Not
implemented.
The backup failed
because of an attempt to
back up or merge files
while another backup or
restore was in progress.
Wait until the backup or restore is complete
before starting another backup.
Watchdog Process Monitoring
WATCHDOG:
<registered client
name> failed on
<server IP address>
Critical The watchdog process
detected a registered
client failure on a specific
server.
The <registered client
name> could be one of the
following:
Clusterd timeout
thread
DB Sentinel
run_server loop
Process manager
main loop
Clusterd monitor
Disk monitor
assistance.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Infoblox MIBs
Threshold Crossing Traps
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
System Memory Usage
System has run out
of memory.
Major The appliance ran out of memory.
The appliance encountered this
problem when one of the following
occurred:
The total free memory on the
appliance was less than or equal
to 0%.
The total physical memory was
less than the total free memory.
The percentage of free memory
compared to the total physical
memory was less than 5%, and
the free swap percentage was
less than 80%.
memory was less than 5%, plus
the numbers of both swap INs
and swap OUTs were greater
than or equal to 3,200.
memory was between 5% and
10%, the free swap percentage
was greater than or equal to
80%, plus the numbers of both
swap INs and swap OUTs were
greater than or equal to 3,200.
memory was greater than 10%,
less than 80%, plus the
numbers of both swap INs and
swap OUTs were greater than or
equal to 3,200.
Note: Free memory = free physical
RAM + free cache buffers.
The high threshold for swap
pages is 3,200.
1. Review the syslog file to
identify the possible cause
of this problem.
2. Contact Infoblox Technical
Support for assistance.
System memory
usage is over 90%.
Minor The memory usage on the appliance
exceeded 90%.
The appliance encountered this
occurred:
memory was less than 5%, and
less than 90%.
memory was less than 5%, plus
the number of swap INs was less
than 3,200 and the number of
swap OUTs was greater than or
equal to 3,200.
memory was between 5% and
10%, and the free swap
percentage was less than 80%.
memory was greater than 5%,
plus the number of swap INs
was less than 3,200 and the
number of swap OUTs was
greater than or equal to 3,200.
Note: Free memory = free physical
RAM + free cache buffers.
The high threshold for swap
pages is 3,200.
of this problem.
System memory is
OK.
Minor The memory usage on the system is
back to normal from the previous
state.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Infoblox MIBs
Primary Hard Drive Usage (monitored every 30 seconds)
System primary
hard disk usage is
over 90%.
Minor The primary hard disk usage
exceeded 90%. The alert light is
yellow.
of this problem.
Primary drive is full. Major The primary hard disk usage
exceeded 95%. The alert light is red.
of this problem.
Primary drive
usage is OK.
Minor The primary hard disk usage is 85%
or lower. The alert light is green.
Replication Statistics Monitoring
Grid queue
replication
problem.
Not
implemented.
The system encountered this
problem when all of the following
conditions occurred:
The node was online.
The number of the replication
queue being sent from the
master column was greater than
0, or the number of the queue
received was greater than 0.
It was more than 10 minutes
since the last replication queue
was sent and monitored.
of this problem.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
DHCP Range Threshold Crossing
DHCP threshold
crossed:
Member: <DHCP
server node VIP>
Network: <network>
Range: <DHCP
range>
High Watermark:
<high watermark
percentage> (95%
by default)
Low Watermark:
<low watermark
percentage> (0% by
default)
Current Usage:
<current usage
percentage>
Active Leases:
<number of active
leases>
Available Leases:
<number of
available leases>
Total Addresses:
<total addresses>
Not
implemented.
The system encountered this
conditions occurred:
The address usage in the DHCP
range was greater than the high
watermark.
The address usage in the DHCP
range was less than the low
watermark.
of this problem.
DHCP DDNS Updates Deferred
DHCP DNS updates
deferred:
Retried at least
once: <number of
retries>
Maximum number
of deferred
updates since start
of problem episode
(or restart): <max
number>
Not
implemented.
The DNS updates were deferred
because of DDNS update errors.
of this problem.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Infoblox MIBs
Object State Change Traps
Database Capacity Usage
Over 85%
database capacity
used.
Minor The appliance database usage
exceeded 85%.
1. Increase the database
capacity.
Database capacity
used is OK.
Minor The appliance database usage is less
than 85%.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Service Shutdown
Shutting down
services due to
database snapshot.
Not
implemented.
The appliance is shutting
down its services while
synchronizing the
database with the grid
master.
Shutting down
services due to
database snapshot.
Not
implemented.
The appliance is shutting
down its services while
synchronizing the
database with the grid
master.
Network Interfaces Monitoring
LAN port link is
down. Please check
the connection.
Major The LAN port is up, but
the link is down.
Check the LAN link connection.
HA port link is down.
Please check the
connection.
Major The HA port is up, but the
link is down.
Check the HA link connection.
MGMT port link is
down. Please check
the connection.
Major The MGMT port is
enabled, but the link is
down.
Check the MGMT link connection.
LAN port link is up. Major The LAN port link is up
and running.
HA port link is up. Major The HA port link is up and
running.
MGMT port link is up. Major The MGMT port link is up
and running.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
HA State Change from Initial to Active
The node has
become ACTIVE.
Not
implemented.
A node in an HA pair
becomes active. The HA
pair starts up.
HA State Change from Passive to Active
The node has
become ACTIVE.
Not
implemented.
The node changed from a
passive to an active node.
HA State Change from Initial to Passive
The node has
become PASSIVE.
Not
implemented.
A node in an HA pair
becomes passive. The HA
pair starts up, and the
node is not a grid master
candidate.
Node Connected to Grid
The grid member is
connected to the grid
master.
Not
implemented.
The grid member joined
the grid, and it is not a
grid master candidate.
Node Disconnected to Grid
The grid member is
not connected to the
grid master.
Not
implemented.
The grid member lost its
connection to the grid
master.
Replication State Monitoring
HA replication
online.
Not
implemented.
The replication queue is
online.
HA replication
offline.
Not
implemented.
offline.
NTP is out of sync, monitored every 30 seconds
The NTP server is out
of synchronization.
Major The Infoblox NTP server
and the external NTP
server are not
synchronized.
assistance.
Replication State Monitoring
Replication queue is
offline.
Not
implemented.
offline.
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Infoblox MIBs
Process Started and Stopped Traps
ibTrapDesc
OID 3.1.1.1.2.11.0
ibTrapServerity
OID 3.1.1.1.2.2
Httpd Start
The process started
normally.
Informational The httpd process
started.
Httpd Stop
The process stopped
normally.
Informational The httpd process
stopped.
ibPlatformOne MIB
The ibPlatformOne MIB provides information about the CPU temperature of the appliance, the replication status, and
the average latency of DNS requests. Figure 6.4 illustrates the structure of the PlatformOne MIB. (Note that the OIDs
in the illustration do not include the prefix .1.3.6.1.4.1.7779.) The ibPlatformOne MIB branches out into six subtrees:
ibCPUTemperature tracks the CPU temperature of the appliance
ibClusterReplicationStatusTable provides information in tabular format about the replication status of the
appliance. See ibClusterReplicationStatusTable on page 203 for more information.
ibNetworkMonitor provides information about the average latency of authoritative and nonauthoritative replies
to DNS queries for different time intervals. See ibNetwork Monitor on page 203 for more information.
ibHardwareType provides the model number of the Infoblox hardware platform.
ibHardwareId provides the hardware iD of the NIOS appliance.
ibSerialNumber provides the serial number of the Infoblox hardware platform.
Figure 6.4 PlatformOneMIB Structure
(3.1.1.2) ibPlatformOne MIB
(3.1.1.2.1) ibPlatformOneModule
(3.1.1.2.1.1)
ibCPUTemperature
(3.1.1.2.1.2)
ibClusterReplicationStatusTable
(3.1.1.2.1.2.1)
ibClusterReplicationStatusEntry
(3.1.1.2.1.3)
ibNetworkMonitor
(3.1.1.2.1.3.1)
ibNetworkMonitorDNS
(3.1.1.2.1.3.1.1)
ibNetworkMonitorDNSActive
(3.1.1.2.1.3.1.2)
ibNetworkMonitorDNSNonAA
(3.1.1.2.1.3.1.3)
ibNetworkMonitorDNSAA
(3.1.1.2.1.2.1.1)
ibNodeIPAddress
(3.1.1.2.1.2.1.2)
ibNodeReplicationStatus
(3.1.1.2.1.2.1.3)
ibNodeQueueFromMaster
(3.1.1.2.1.2.1.4)
ibNodeLastRepTimeFromMaster
(3.1.1.2.1.2.1.5)
ibNodeQueueToMaster
(3.1.1.2.1.2.1.6)
ibNodeLastRepTimeToMaster
(3.1.1.2.1.4)
ibHardwareType
(3.1.1.2.1.5)
ibHardwareId
(3.1.1.2.1.6)
ibSerialNumber
Infoblox MIBs
ibClusterReplicationStatusTable
This table provides information about the grid replication status.
Table 6.6 ibClusterReplicationStatusTable Objects
ibNetwork Monitor
As shown in Figure 6.4, the ibNetwork Monitor has one subtree, ibNetworkMonitorDNS, that branches out into the
following:
ibNetworkMonitorDNSActive reports on whether DNS latency monitoring is enabled. This is the only object in
this branch. When you send a query for this object, the appliance responds with either active or nonactive.
ibNetworkMonitorDNSNonAA provides information about the average latency of nonauthoritative replies to DNS
queries for 1-, 5-, 15-, and 60-minute intervals.
ibNetworkMonitorDNSAA provides information about the average latency of authoritative replies to DNS queries
for 1-, 5-, 15-, and 60-minute intervals.
Object Description
ibClusterReplicationStatusEntry A conceptual row that provides information about the grid replication status.
ibNodeIPAddress IP address of a grid member
ibNodeReplicationStatus Replication status of the grid member
ibNodeQueueFromMaster Sent queue size from master
ibNodeLastRepTimeFromMaster Last sent time from master
ibNodeQueueToMaster Receive queue size from master
ibNodeLastRepTimeToMaster Last receive time from master
Figure 6.5 ibNetworkMonitorDNSNonAA and ibNetworkMonitorDNSAA Subtrees
(3.1.1.2.1.3.1.2.1)
ibNetworkMonitorDNSNonAAT1
(3.1.1.2.1.3.1.2.1.1)
ibNetworkMonitorDNSNonAAT1AvgLatency
(3.1.1.2.1.3.1.2.1.2)
ibNetworkMonitorDNSNonAAT1Count
(3.1.1.2.1.3.1.2.2)
(3.1.1.2.1.3.1.2.2.1)
(3.1.1.2.1.3.1.2.2.2)
(3.1.1.2.1.3.1.2.3)
(3.1.1.2.1.3.1.2.3.1)
(3.1.1.2.1.3.1.2.3.2)
(3.1.1.2.1.3.1.2.4)
(3.1.1.2.1.3.1.2.4.1)
(3.1.1.2.1.3.1.2.4.2)
(3.1.1.2.1.3.1.2)
ibNetworkMonitorDNSNonAA
(3.1.1.2.1.3.1.3.1)
ibNetworkMonitorDNSAAT1
(3.1.1.2.1.3.1.3.1.1)
ibNetworkMonitorDNSAAT1AvgLatency
(3.1.1.2.1.3.1.3.1.2)
ibNetworkMonitorDNSAAT1Count
(3.1.1.2.1.3.1.3.2)
(3.1.1.2.1.3.1.3.2.1)
(3.1.1.2.1.3.1.3.2.2)
(3.1.1.2.1.3.1.3.3)
(3.1.1.2.1.3.1.3.3.1)
(3.1.1.2.1.3.1.3.3.2)
(3.1.1.2.1.3.1.3.4)
(3.1.1.2.1.3.1.3.4.1)
(3.1.1.2.1.3.1.3.4.2)
(3.1.1.2.1.3.1.3)
ibNetworkMonitorDNSAA
(3.1.1.2.1.3.1.3.5)
(3.1.1.2.1.3.1.3.5.1)
(3.1.1.2.1.3.1.3.5.2)
(3.1.1.2.1.3.1.2.5)
(3.1.1.2.1.3.1.2.5.1)
(3.1.1.2.1.3.1.2.5.2)
Infoblox MIBs
Table 6.7 describes the objects in ibNetworkMonitorDNSNonAA. You can send queries to retrieve values for these
objects.
Table 6.7 ibNetworkMonitorDNSNonAA Objects
Object Description
ibNetworkMonitorDNSNonAAT1 File that contains the objects for monitoring the average latency
of nonauthoritative replies to queries during the last minute.
ibNetworkMonitorDNSNonAAT1AvgLatency Indicates the average latency in microseconds of
nonauthoritative replies to queries during the last minute.
ibNetworkMonitorDNSNonAAT1Count Indicates the number of queries used to calculate the average
latency of nonauthoritative replies during the last minute.
of nonauthoritative replies to queries during the last five
minutes.
nonauthoritative replies to queries during the last five minutes.
latency of nonauthoritative replies during the last five minutes.
of nonauthoritative replies to queries during the last 15 minutes.
nonauthoritative replies to queries during the last 15 minutes.
latency of nonauthoritative replies during the last 15 minutes.
of nonauthoritative replies to queries during the last 60 minutes.
of nonauthoritative replies to queries during the last 1440
minutes.
Table 6.8 describes the objects in ibNetworkMonitorDNSAA. You can send queries to retrieve values for these
objects.
Table 6.8 ibNetworkMonitorDNSAA Objects
Object Description
ibNetworkMonitorDNSAAT1 File that contains the objects for monitoring the average latency
of authoritative replies to queries during the last minute.
ibNetworkMonitorDNSAAT1AvgLatency Indicates the average latency in microseconds of authoritative
replies to queries during the last minute.
ibNetworkMonitorDNSAAT1Count Indicates the number of queries used to calculate the average
latency of authoritative replies during the last minute.
of authoritative replies to queries during the last five minutes.
replies to queries during the last five minutes.
latency of authoritative replies during the last five minutes.
of authoritative replies to queries during the last 15 minutes.
replies to queries during the last 15 minutes.
latency of authoritative replies during the last 15 minutes.
Infoblox MIBs
ibDHCPOne MIB
The ibDHCPOne MIB provides information about address usage within a subnet, DHCP lease statistics, and DHCP
packet counts. Figure 6.6 illustrates the structure of the ibDHCPOne MIB. (Note that the OIDs shown in the illustration
do not include the prefix .1.3.6.1.4.1.7779.) It has three subtrees: ibDHCPSubnetTable, ibDHCPLeaseTable, and
ibDHCP Statistics.
Figure 6.6 DHCPone MIB
(3.1.1.4) ibDHCPOne MIB
(3.1.1.4.1) ibDHCPModule
(3.1.1.4.1.1)
ibDHCPSubnetTable
(3.1.1.4.1.2)
ibDHCPLeaseTable
(3.1.1.4.1.2.1)
ibDHCPLeaseEntry
(3.1.1.4.1.3)
ibDHCPStatistics
(3.1.1.4.1.2.1.1)
ibDHCPLeaseAddress
(3.1.1.4.1.2.1.2)
ibDHCPLeaseMACAddress
(3.1.1.4.1.2.1.3)
ibDHCPLeaseStart
(3.1.1.4.1.2.1.4)
ibDHCPLeaseEnd
(3.1.1.4.1.2.1.5)
ibDHCPLeaseBindState
(3.1.1.4.1.2.1.6)
ibDHCPLeaseNextBindState
(3.1.1.4.1.1.1.1)
ibDHCPSubnetNetworkAddress
(3.1.1.4.1.1.1)
ibDHCPSubnetEntry
(3.1.1.4.1.1.1.2)
ibDHCPSubnetNetworkMask
(3.1.1.4.1.1.1.3)
ibDHCPSubnetPercentUsed
(3.1.1.4.1.2.1.7)
ibDHCPLeaseClientHostName
(3.1.1.4.1.2.1.8)
ibDHCPLeaseUID
(3.1.1.4.1.3.1)
ibDhcpTotalNoOfDiscovers
(3.1.1.4.1.3.2)
ibDhcpTotalNoOfRequests
(3.1.1.4.1.3.3)
ibDhcpTotalNoOfReleases
(3.1.1.4.1.3.4)
ibDhcpTotalNoOfOffers
(3.1.1.4.1.3.5)
ibDhcpTotalNoOfAcks
(3.1.1.4.1.3.6)
ibDhcpTotalNoOfNacks
(3.1.1.4.1.3.7)
ibDhcpTotalNoOfDeclines
(3.1.1.4.1.3.8)
ibDhcpTotalNoOfInforms
(3.1.1.4.1.3.9)
ibDhcpTotalNoOthers
The ibDHCPSubnetTable provides statistical data about the DHCP operations of the appliance. It contains the
following objects:
Table 6.9 ibDHCPSubnetTable
Following is an example of the table as viewed through a MIB browser:
Figure 6.7 MIB Browser View 1
The ibDHCPLeaseTable provides statistics about the DHCP leases. It contains the following objects:
Table 6.10 ibDHCPLeaseTable
Object Description
ibDHCPSubnet Entry File that contains the objects for monitoring DHCP operations on the
appliance.
ibDHCPSubnetNetworkAddress The subnetworks, in IP address format, that have IP addresses for lease. A
subnetwork may have many address ranges for lease.
ibDHCPSubnetNetworkMask The subnet mask in dotted decimal format.
ibDHCPSubnetPercentUsed The percentage of dynamic DHCP addresses leased out at this time for each
subnet. Fixed addresses are always counted as leased for this calculation, if
the fixed addresses are within a leased address range.
Object Description
ibDHCPLeaseEntry File that contains the objects that provide information about DHCP leases.
ibDHCPLeaseAddress The IP address issued by DHCP.
ibDHCPLeaseMACAddress The MAC Address of the DHCP client.
ibDHCPLeaseStart The start time of the DHCP lease.
ibDHCPLeaseEnd The end time of the DHCP lease.
ibDHCPLeaseBindState The IP address binding state of the DHCP lease. The binding state is used by
the DHCP failover protocol and indicates, among other things, whether an IP
address is in use, has been released, or is available for allocation.
ibDHCPLeaseNextBindState Next Binding state of DHCP lease.
Infoblox MIBs
ibDHCP Statistics maintains counters for different types of packets. The counters always start with zero when you
enable DHCP. Therefore the numbers reflect the total number of packets received since DHCP was enabled on the
NIOS appliance. The ibDHCPStatistics module contains the following objects:
Table 6.11 ibDHCPStatistics
ibDHCPLeaseClientHostName Client provided host name during DHCP registration.
ibDHCPLeaseUID Client provided UID during DHCP registration. (The UID is a number that
uniquely identifies the client machine.)
Object Description
ibDhcpTotalNoOfDiscovers The number of DHCPDISCOVER messages that the appliance received. Clients
broadcast DHCPDISCOVER messages when they need an IP address and
network configuration information.
ibDhcpTotalNoOfRequests The number of DHCPREQUEST messages that the appliance received. A client
sends a DHCPREQUEST message requesting configuration information, after it
receives the DHCPOFFER message.
ibDhcpTotalNoOfReleases The number of DHCPRELEASE messages that the appliance received from its
clients. A client sends a DHCP release when it terminates its lease on an IP
address.
ibDhcpTotalNoOfOffers The number of DHCPOFFER messages that the appliance has sent to clients.
The appliance sends a DHCPOFFER message to a client. It contains an IP
address and configuration information.
ibDhcpTotalNoOfAcks The number of DHCPACK messages that the appliance sent to clients. It sends
a DHCPACK message to a client to confirm that the IP address offered is still
available.
ibDhcpTotalNoOfNacks The number of DHCPNACK messages that the appliance sent to clients. It sends
a DHCPNACK message to withdraw its offer of an IP address.
ibDhcpTotalNoOfDeclines The number of DHCPDECLINE messages that the appliance received. A client
sends a DHCPDECLINE message if it determines that an offered IP address is
already in use.
ibDhcpTotalNoOfInforms The number of DHCPINFORM messages that the appliance received. A client
sends a DHCPINFORM message when it has an IP address but needs
information about the network.
ibDhcpTotalNoOfOthers The total number of DHCP messages other than those used in negotiation, such
as DHCPFORCERENEW, DHCPKNOWN, and DHCPLEASEQUERY.
Object Description
ibDNSOne MIB
The ibDNSOne MIB provides statistical information about the DNS processes and about the views and zones in the
database. Figure 6.7 illustrates the structure of the ibDNSOne MIB. (Note that the OIDs shown in the illustration do
not include the prefix 1.3.6.1.4.1.7779.) The ibDNSOne MIB contains two subtrees, ibZoneStatisticsTable and the
ibZonePlusViewStatisticsTable.
Figure 6.8 ibDNSOne MIB
The ibZoneStatisticsTable provides statistical data about the DNS operations on the appliance. The following lists the
OIDs and the objects in the table:
Table 6.12 ibZoneStatisticsTable
Object Description
ibBindZoneName DNS Zone name.
ibBindZoneSuccess The number of successful responses since the DNS process started.
ibBindZoneReferral The number of DNS referrals since the DNS process started.
ibBindZoneNxRRset The number of DNS queries received for non-existent records.
ibBindZoneNxDomain The number of DNS queries received for non-existent domains.
(3.1.1.3) ibDNSOne MIB
(3.1.1.3.1) ibDnsModule
(3.1.1.3.1.1)
ibZoneStatisticsTable
(3.1.1.3.1.1.1)
ibZoneStatisticsEntry
(3.1.1.3.1.1.1.1)
ibBindZoneName
(3.1.1.3.1.1.1.2)
ibBindZoneSuccess
(3.1.1.3.1.1.1.3)
ibBindZoneReferral
(3.1.1.3.1.1.1.4)
ibBindZoneNxRRset
(3.1.1.3.1.1.1.5)
ibBindZoneNxDomain
(3.1.1.3.1.1.1.6)
ibBindZoneRecursion
(3.1.1.3.1.1.1.7)
ibBindZoneFailure
(3.1.1.3.1.2)
ibZonePlusViewStatisticsTable
(3.1.1.3.1.2.1)
ibZonePlusViewStatisticsEntry
(3.1.1.3.1.2.1.1)
ibZonePlusViewName
(3.1.1.3.1.2.1.2)
ibZonePlusViewSuccess
(3.1.1.3.1.2.1.3)
ibZonePlusViewReferral
(3.1.1.3.1.2.1.4)
ibZonePlusViewNxRRset
(3.1.1.3.1.2.1.5)
ibZonePlusViewNxDomain
(3.1.1.3.1.2.1.6)
ibZonePlusViewRecursion
(3.1.1.4.1.2.1.7)
ibZonePlusViewFailure
(3.1.1.4.1.2.1.8)
ibBindViewName
Infoblox MIBs
The ibZonePlusViewStatisticsTable provides statistical data about Infoblox views and their zones. The following table
lists the objects and their OIDS:
Table 6.13 ibZonePlusViewStatisticsTable
Following is an example of the table as viewed through a MIB browser:
Figure 6.9 MIB Browser View 2
ibBindZoneRecursion The number of queries received using recursion since the DNS process started.
ibBindZoneFailure The number of failed queries since the DNS process started.
Object Description
ibZonePlusViewName The zone name. The first one in the default view is the global summary
statistics. Index name for global statistics is summary.
ibZonePlusViewSuccess Number of successful responses since the DNS process started.
ibZonePlusViewReferral Number of DNS referrals
ibZonePlusViewNxRRset Number of DNS queries received for non-existent records.
ibZonePlusViewNxDomain Number of DNS queries received for non-existent domains.
ibZonePlusViewRecursion Number of DNS recursive queries received
ibZonePlusViewFailure Number of failed queries
ibBindViewName View name. This is blank for default view
Object Description
ibIPWC MIB
The ibIPWC MIB defines the objects in the WinConnect MIB module as well as the types of traps that an IPAM
WinConnect server sends. If you use the Infoblox IPAM WinConnect service, you must download the ibIPWC MIB. (For
information about IPAM WinConnect, see Chapter 22, IPAM WinConnect, on page 643.) Figure 6.10 illustrates the
structure of the IPWC MiB. The OIDs in the illustration do not include the prefix 1.3.6.4.1.25558. where 25558 is the
IANA-assigned enterprise number for Ipanto. (Note that Ipanto is the former name of WinConnect.)
The ibIPWC MIB branches out into two subtrees:
ssp: The ssp tree contains objects that provide information about the WinConnect server and its client. ssp
branches out into two subtrees, sipd and aipd. See tables 6.18 to 6.23 for information about the objects and
their definitions in the sipd and aipd trees.
traps: The traps tree provides information about the SNMP traps that the IPAM WinConnect server sends. See
Table 6.20 for a list of traps that the WinConnect server generates.
Figure 6.10 ibIPWC MIB structure
ibIPWC MIB
ipanto
(1)
ssp
(1.2)
aipd
(2)
traps
(1.2.1)
type
(1.2.2)
name
(1.1.1)
process
(1.1)
sipd
(1.1.2)
license
(1.1.3)
client
(1.1.4)
db
(1.1.5)
error
(1.1.6)
job
(1.1.7)
backup
(1.1.1.1)
port
(1.1.1.2)
sslPort
(1.1.1.3)
uid
(1.1.1.4)
suid
(1.1.2.1)
date
(1.1.2.2)
hostcount
(1.1.3.1)
ipSrc
(1.1.3.2)
user
(1.1.3.3)
agent
See Table 6.24 for
details of the traps
and descriptions.
See Table 6.21 for details
of the agent tree.
See Tables 6.22 and 6.23
for details of the db tree
and its subtrees.
Infoblox MIBs
The sipd tree contains objects that provide information about the WinConnect server and its client. Table 6.14 lists
the objects and their descriptions in the sipd tree.
Table 6.14 sipd
The aipd tree contains information about objects that provide information about the WinConnect connector.
Table 6.15 lists the objects and their descriptions in the aipd tree.
Table 6.15 aipd
Object Description
process Contains objects that provide information about the WinConnect server
process. This subtree contains four objects:
port: The server port of the WinConnect server.
sslPort: The SSL port of the WinConnect server.
uid: The WinConnect server process ID.
suid: The unique ID of the WinConnect server.
license Contains objects that provide licensing information about the WinConnect
server. This subtree contains two objects:
date: DEPRECATED.
hostCount: The number of licensed hosts.
client Contains objects that provide information about the WinConnect client. See
Table 6.16 for details.
db Contains objects that provide information about the WinConnect database.
See Table 6.18 for details.
error Contains objects that provide information about the error messages that the
WinConnect server generates. This subtree contains two objects:
description: The error description.
code: The error code.
job Contains one object:
name: The scheduled job name.
backup Contains one object:
date: The date of the last WinConnect server backup.
Object Description
type The WinConnect connector type.
name The WinConnect connector name.
The client tree under sipd contains objects that provide information about the WinConnect client. Table 6.16 lists the
objects and their descriptions in the client tree.
Table 6.16 client
The agent tree under client contains objects that provide information about the WinConnect connector. Table 6.17
lists the objects and their descriptions in the agent tree.
Table 6.17 agent
The db tree under sipd contains objects that provide information about the WinConnect database. Table 6.18 lists
the objects and their descriptions in the db tree.
Table 6.18 db
Object Description
ipSrc The IP address of the client server.
user Contains two objects:
name: The WinConnect user name.
sessionType: The user session type.
agent Contains objects that provide information about the WinConnect connector.
See Table 6.17 for details.
Object Description
type The WinConnect connector type.
name The WinConnect connector name.
service Contains three objects:
type: The managed service type.
name: The managed service name.
access: The managed service access.
Object Description
organization The organization that owns the object in the WinConnect database.
dhcp Contains objects that provide information about the IP addresses in the
database. See Table 6.19 for details.
dns Contains one object:
zone: The DNS zone. Contains one object:
name: The zone name in the WinConnect database.
subnet Contains three objects:
address: The subnet address.
mask: The subnet mask.
rate: The occupation rate of the subnet.
clockskew DEPRECATED.
Infoblox MIBs
f
The dhcp tree under db contains objects that provide information about the IP addresses in the WinConnect
database. Table 6.19 lists the objects and their descriptions in the dhcp tree.
Table 6.19 dhcp
The WinConnect server generates traps to notify the SNMP monitoring device of events. Table 6.20 lists the types of
traps that the WinConnect server sends.
Table 6.20 traps
Object Description
host Contains two objects:
activeCount: The number of active hosts in the WinConnect database.
totalCount: The total number of hosts in the WinConnect database.
pool Contains three objects:
start: The start IP address of the address pool.
end: The end IP address of the address pool.
rate: The occupation rate of the address pool.
Object Description
start WinConnect is ready to reply to client requests.
stop WinConnect cannot accept client requests or connections.
licenseInvalid DEPRECATED.
licenseDateExpired DEPRECATED.
licenseDateWarning DEPRECATED.
licenseHostExceeded The maximum number of host licenses has been reached.
licenseHostWarning 90% of the host licenses have been assigned.
clockSkewWarning DEPRECATED.
clockSkewExceeded WinConnect detected a clock skew error.
clockSkewError DEPRECATED.
dbIntegrityError WinConnect detected that the database is corrupted, or WinConnect cannot
determine the integrity of the database.
userlogin A user started a session.
userlogout A user ended a session.
userAuthFailed WinConnect failed to authenticate the user.
agentLogin The WinConnect connector connected to WinConnect.
agentAuthFailed The WinConnect connector failed to connect to WinConnect.
userAuthFailureExceeded The maximum number of user authentication has been reached.
synchroStartMaster DEPRECATED.
synchroStartSlave DEPRECATED.
sychroSuccess DEPRECATED.
synchroFailed DEPRECATED.
serviceStarted The WinConnect connector informed WinConnect that the current service
status is running.
serviceStopped The WinConnect connector informed WinConnect that the current service
status is stopped.
controlStart A user requested to start a specific service.
controlStop A user requested to stop a specific service.
controlRestart A user requested to restart a specific service.
controlReload A user requested to reload a DNS zone.
unreachable WinConnect could not contact the WinConnect connector.
poolCapacityWarning Over 90% of the IP addresses in the address pool have been assigned.
poolCapacityFull 100% of the IP addresses in the address pool have been assigned.
subnetCapacityWarning Over 90% of the subnet has been assigned.
subnetCapacityFull 100% of the subnet has been assigned.
jobErrorGeneration The command for a scheduled job failed and generated an error. Check the logs
on the WinConnect server for the error.
jobWarningGeneration A scheduled job completed with warning. Check the logs on the WinConnect
server for the warning.
jobErrorExecution A scheduled job execution failed.
discoverWarning The command for network discovery completed with a warning. Check the logs
on the WinConnect server for the warning.
restoreError The restore process completed with errors. Check the logs on the WinConnect
server for the errors.
restoreSuccess The restore process completed successfully.
backupError The backup process completed with errors. Check the logs on the WinConnect
server for the errors.
backupSuccess The backup process completed successfully.
cwServerSynchro The synchronization process with the CiscoWorks server is starting.
applySubnetTemplateSuccess WinConnect successfully applied the subnet template.
applySubnetTemplateFailure WinConnect failed to apply the subnet template.
Object Description
Configuring SNMP
Configuring SNMP
Perform the following tasks to configure SNMP on the NIOS appliance:
Enable the NIOS appliance to accept queries and define the community string that management systems must
specify when they send queries to the appliance.
Specify the management systems to which the appliance sends traps.
For a grid, you can perform these tasks at the grid level and at the member level. You can define SNMP settings for an
entire grid, and when necessary, define different SNMP settings for a member. SNMP settings for a member override
SNMP settings for a grid.
You can also set up SNMP on an independent appliance or HA pair.
Accepting SNMP Queries
You can allow specific management systems to send queries to a NIOS appliance. When you do, you must specify a
community string. The appliance accepts queries only from management systems that provide the correct community
string.
To configure a grid or an independent NIOS appliance or HA pair to accept SNMP queries:
or
From the Device perspective, click Device -> host_name -> Edit -> Device Properties.
Enable queries: Select this check box for grid members or an independent appliance or HA pair to accept
queries from SNMP management systems.
Community String: Enter a text string that the management system must send together with its queries
to the grid or the independent appliance or HA pair. A community string is similar to a password in that
the appliance accepts queries only from management systems that send the correct community string.
Note that this community string must match exactly what you enter in the management system.
Setting System Information
You can enter values for the following managed objects in MIB-II, the standard MIB defined in RFC 1213:
sysContact
sysLocation
sysName
sysDescr
After you enter these values on the appliance, administrators can send queries for these values from management
systems that are allowed to send queries to the appliance.
To enter system information:
or
Set objects: Select check box.
sysContact: Enter the name of the contact person for the appliance.
sysLocation: Enter the physical location of the appliance.
sysName: Enter the fully qualified domain name of the appliance.
sysDescr: Enter useful information about the appliance, such as the software version it is running.
Adding SNMP Trap Receivers
You can enable a NIOS appliance to send traps to specific management systems or trap receivers. It sends traps
whenever certain events occur, as described in ibTrap MIB on page 180.
To configure an SNMP trap receiver for a grid or an independent appliance or HA pair:
or
Enable traps: Select the check box to enable grid members or an independent appliance or HA pair to send
traps to specified SNMP management systems.
Community String: Enter a text string that the NIOS appliance sends to the management system
together with its traps. Note that this community string must match exactly what you enter in the
management system.
Trap Receiver Group: Type an address of an SNMP management system to which you want the SNMP
agent on grid members and independent appliances to send traps in the IP Address field, and then
click Add. (You can enter more than one trap receiver.)
To remove an IP address from the list, select the address, and then click Delete.
Configuring SNMP for a Grid Member
You can override grid-level SNMP settings for individual members. To modify the SNMP settings for a grid member:
2. In the Grid Member editor, click Monitoring, and then enter the following:
Override grid SNMP settings: Select the check box to override grid-level SNMP settings and apply
member-level settings.
Enable queries: Select the check box for the member to accept queries from SNMP management
systems. Clear the check box to disable the member from accepting SNMP queries.
Community String: Type a community stringwhich is very much like a passwordthat SNMP
management systems must send when querying the member.
Enable traps: Select the check box to enable the grid member to send traps to specified SNMP
management systems. Clear the check box to disable the member from sending SNMP traps.
Community String: Type a community stringwhich is very much like a passwordthat the grid
member must include when sending traps to the specified SNMP management systems.
Trap Receiver Group: Type the IP address of an SNMP management system to which you want the
grid member to send traps in the IP Address field, and then click Add. To remove an IP address from
the list, select the address, and then click Delete.
Set objects: Select this check box.
sysContact: Enter the name of the contact person for the appliance.
sysLocation: Enter the physical location of the appliance.
sysName: Enter the fully qualified domain name of the appliance.
sysDescr: Enter useful information about the appliance, such as the software version it is running.

Chapter 7 Changing Software and
Merging Files
You can perform software upgrades and downgrades for your NIOS appliance. You can also merge data files from
previous versions of the DNSone module to a NIOS appliance running DNSone 3.2 or later. This chapter explains how
to perform these procedures:
Upgrading NIOS Software on page 220
Downgrading Software on page 220
Reverting to the Previously Running Software Version on page 221
Backing Up and Restoring a Configuration File on page 222
Back Up and Restore Overview on page 222
Automatically Backing Up a Data File on page 223
Downloading a Backup File on page 224
Restoring a Configuration File on page 225
Loading a Configuration File on a Different Appliance on page 226
Downloading a Support Bundle on page 227
Changing Software and Merging Files
Upgrading NIOS Software
Infoblox frequently releases updated NIOS software. Contact Infoblox Support to learn what file name to use when
downloading the new upgrade file, or watch your e-mail for periodic notifications that a new software upgrade is
available. To get the latest upgrades, your local network must be capable of downloading a file from the Internet.
To upgrade an independent appliance or HA pair, see Upgrading Software on an Independent Appliance or HA Pair
on page 265. To upgrade a grid, see Upgrading NIOS Software on a Grid on page 313.
Downgrading Software
Infoblox-500, -1000, and -1200 appliances support software downgrades from DNSone 3.2r1 or later to any previous
DNSone release beginning with 3.1r1. Infoblox-550, -1050, -1550, and -1552 appliances support software
downgrades from DNSone 3.2r9-2 or later to any previous DNSone release beginning with 3.2r9-1. The downgrade
procedure is for single independent appliances only. Infoblox does not support software downgrades for grid
members, but you can revert to the last grid upgrade file (see the next section) on a grid master.
Caution: Although the downgrade process preserves license information and basic network settings, it does not
preserve data. After you complete the downgrade procedure, all data in the database is lost.
To downgrade software on a single independent appliance running NIOS 4.0 or later:
1. For an appliance running DNSone with Keystone: From the Grid perspective, click Grid -> Downgrade.
or
For an appliance running DNSone: From the Device perspective, click Device -> Downgrade.
2. Read the warning carefully, and then click OK to confirm your decision to downgrade.
3. Navigate to the downgrade image file, and then click OK.
4. Clear the Java cache on your system.
5. Close the browser, open another browser instance, and then log back in.
Reverting to the Previously Running Software Version
Reverting to the Previously Running Software Version
You can revert to the previous version of software that was running on your NIOS appliance. The NIOS appliance
stores the previous version in its backup software partition. You can see if there is a software version to which you
can revert and what that version is in the Alternate Revision column in the Upgrade Status viewer. From the Grid or
Device perspective, click View -> Upgrade Status.
Be aware that when you revert to this software, any configurations made to the currently running software are lost.
So that you can later determine what configuration changes are missing, you can back up the current data before you
revert.
To revert to a version of software running previously on a grid or on an independent appliance or HA pair:
1. From the Grid or Device perspective, click Grid or Device -> Revert.
2. Read the warning carefully, and then click OK to confirm your decision to revert.
3. Close the Java application and restart it.
Clearing the Java cache is unnecessary because JWS automatically updates its cache with the application for the
currently running version of software.
4. Log back in to the grid master, independent appliance, or independent HA pair.
Backing Up and Restoring a Configuration File
You can back up your system files locally on the appliance, or to a TFTP (Trivial File Transfer Protocol) or FTP (File
Transfer Protocol) server. The backup file is a .tar.gz file that contains the configuration settings, data set, and TFTP
files. For information about the TFTP feature, see Chapter 20, File Distribution Services, on page 605. You can also
save an existing backup file, or create and save a new one to your local management system, TFTP server, or FTP
server.
These sections describe how to use the backup and restore functions:
Back Up and Restore Overview on page 222
Automatically Backing Up a Data File on page 223
Downloading a Backup File on page 224
Restoring a Configuration File on page 225
Loading a Configuration File on a Different Appliance on page 226
Note: Infoblox highly recommends you always back up the current configuration file before upgrading, restoring, or
reverting the software on the appliance.
Back Up and Restore Overview
The NIOS appliance allows you to back up and restore the system files. You can configure the appliance to
automatically back up the files on a weekly, daily, or hourly basis. You can also restore an existing configuration file
on the appliance from which it originated, or restore a configuration file from a different appliance (referred to as a
forced restore).
Infoblox recommends that you back up the system files during off-hours to minimize any effect on network services.
By default, the automatic backup function is turned off. You must log in with a superuser account to back up and
restore files.
There are three primary ways to back up and restore a configuration file:
Back up to and restore from a local directory or the management system used to operate the appliance.
Back up to and restore from a TFTP server.
Back up to and restore from a remote server using FTP. This option requires that you have a valid user name and
password for the FTP server prior to attempting to back up or restore.
When you back up the system files locally, the appliance uses the following format to name the file:
year_month_day_time. For example, 2008_11_30_23_00 translates to November 30th, 2008 at 11:00 PM.
The appliance saves up to 20 configuration files, regardless of how often files are saved (weekly, hourly, or daily. The
size of the configuration file should be factored because the storage limit on an appliance is 5 Gb (gigabytes). If your
configuration file is 500 Mb (megabytes), then the appliance stores 10 configuration files. When uploading
configuration files on a TFTP or FTP server, you must consider the file size on that server as well.
Automatically Backing Up a Data File
Infoblox recommends that you back up your configuration files regularly, and the easiest way to accomplish this task
is to configure the appliance to back up the configuration file automatically. You can choose when and how often files
are backed up: weekly, daily, or hourly. When you automatically back up a configuration file on the appliance, the file
is named with the format: year_month_day_time. The default time for an automatic backup is 3:00 AM. Configuration
files should be backed up during the slowest period of network activity.
To automatically back up a database file on an independent appliance or grid master:
or
2. In the Grid (or Device) editor, click Scheduled Backups.
3. In the Scheduled Backups section, enter the following information:
Backup: Choose the destination of the backup file from the left drop-down list (LOCAL, TFTP, FTP) and how
often to back up the file from the right drop-down list (Weekly, Daily, Hourly). By default, a grid master
generates a backup file and saves it locally in its own storage daily at 3:00 AM.
Be aware that backing up the grid and saving it locally on an hourly basis increases the turnover of files
stored on the grid master. Backing it up hourly to a TFTP or FTP server increases the overall amount of traffic
on your network.
Weekday: (Weekly Only) Choose a day from the Weekday drop-down list, an hour from the Hours drop-down
list, and a minute from the Minutes drop-down list. The grid master then creates a backup file at that time
and day every week.
Hours [0-23]: (Weekly and Daily) Type the hour when you want the grid master to create a backup file.
Minutes [0-59]: (Weekly, Daily, Hourly) Type the minute when you want the grid master to create a backup
file.
User Name: (FTP Only) Type the user name for your FTP account.
Password: (FTP Only) Type the password for your FTP account.
Retype Password: (FTP Only) Type the password for your FTP account again to confirm its accuracy.
Backup Host: (FTP and TFTP) Type the IP address of the FTP or TFTP server where you want the grid master to
send the backup file.
Directory Path: (FTP Only) Type a directory pathfor example: /archive/backups (for Windows) or
/bin/backups (for Linux). The folder or directory you type must already exist on the specified server.
Disable schedule backups: Select this check box if you want to disable automatic backups from occurring,
but want to save the settings for future use.
Downloading a Backup File
You can save an existing backup file, or create and save a new one to your local management system, TFTP server, or
FTP server.
To backup a grid or an independent appliance or HA pair to your management system:
1. For a grid: From the Grid perspective, click Grid -> Backup -> to Local File.
or
For an independent appliance or HA pair: From the Device perspective, click Device -> Backup -> to Local File.
2. To back up the current configuration and data set, choose None, and then click OK.
To download a previously made backup file (automatically created through the scheduled backup feature),
choose the backup file name, and then click OK.
3. Navigate to the directory on your local management system where you want to save the backup file, rename the
file if you like (by default, it is named databse.tar.gz), and then click Save or OK.
To backup a grid or an independent appliance or HA pair to a TFTP server:
From the Grid perspective, click Grid -> Backup -> to TFTP Server.
or
From the Device perspective, click Device -> Backup -> to TFTP Server.
1. Enter the following in the TFTP Backup dialog box:
Existing backup files: To back up the current configuration and data set, choose None. To download a
previously made backup file (made using the scheduled backup feature), choose the backup file name.
File name on TFTP server: Type a name for the backup file. If you are downloading a previously made backup
file and want to use that name, you can leave this field empty. A NIOS appliance names backup files by
concatenating the grid name or hostname with the date and time it creates the file, using this format:
For a grid: grid_yyyy_mm_dd_hh_mm.tar.gz
For an independent appliance or HA pair: hostname_yyyy_mm_dd_hh_mm.tar.gz
IP address of TFTP Server: Type the IP address of the TFTP server.
2. To download the specified backup file to the specified TFTP server, click OK.
To backup a grid or an independent appliance or HA pair to an FTP server:
1. From the Grid perspective, click Grid -> Backup -> to FTP Server.
or
From the Device perspective, click Device -> Backup -> to FTP Server.
2. Enter the following in the FTP Backup dialog box:
Existing backup files: To back up the current configuration and data set, choose None. To download a
previously made backup file (made using the scheduled backup feature), choose the backup file name.
File name on FTP server: Type a name for the backup file. If you are downloading a previously made backup
file and want to use that name, you can leave this field empty. A NIOS appliance names backup files by
concatenating the grid name or hostname with the date and time it creates the file, using this format:
For a grid: grid_yyyy_mm_dd_hh_mm.tar.gz
For an independent appliance or HA pair: hostname_yyyy_mm_dd_hh_mm.tar.gz
IP address of FTP server: Type the IP address of the FTP server.
Username on FTP server: Type the user name for your FTP account.
Password on FTP server: Type the password for your FTP account.
Re-type Password on FTP server: Type the account password again to ensure accuracy.
3. To download the specified backup file to the specified FTP server, click OK.
Restoring a Configuration File
You can restore a configuration file from an appliance running software modules v.3.1r4 or later, or v3.2, to an
appliance running software modules v3.2.x. The procedure presented below allows you to restore a configuration file
from the same appliance it was originally backed up. To load a configuration file backed up from a different appliance,
see Loading a Configuration File on a Different Appliance on page 226.
To restore a configuration file to the same independent appliance or grid master:
1. From the Grid perspective, click Grid -> Restore Grid -> From Local File or From TFTP Server or From FTP Server or
From Grid Master.
or
From the Device perspective, click Device -> Restore Device -> From Local File or From TFTP Server or From FTP
Server or From Grid.
From Local File: Navigate to the location of the configuration file, select the file, and then click OK.
or
From TFTP Server: In the Restore Grid From TFTP dialog box, enter the following, and then click OK:
TFTP Server IP Address: Type the IP address of the TFTP server in whose root directory the backup
file is stored.
File Name: Type the name of the backup file. (Because the file must be in .tar.gz format, the file
type is included as a read-only extension of the file name.)
File Path: Type the directory path to where the backup file is stored.
or
From FTP Server: In the Restore Grid From FTP dialog box, enter the following, and then click OK:
FTP Server IP address: Type the IP address of the FTP server in whose root directory the backup file
is stored.
File Name: Type the name of the backup file. Do not include .tar.gz at the end of the file name.
User Name: Type the name of the FTP server account.
Password: Type the password of the FTP server account.
Retype Password: To ensure accuracy, type the account password again.
or
From Grid Master: Select a configuration file from the drop-down list, and then click OK.
3. When the Confirm Grid Restore message appears, click OK to load the configuration file.
After the file loads, the appliance reboots.
4. Close your current browser window or JWS (Java Web Start) application, wait a few minutes, and then reconnect
to the NIOS appliance.
Loading a Configuration File on a Different Appliance
When you force restore a NIOS appliance, you load a configuration file saved from one appliance onto a different
appliance. To restore a configuration file to the same appliance or grid master, use the Restore function explained in
Restoring a Configuration File on page 225.
To load a configuration file from one appliance onto a different appliance:
1. From the Grid perspective, click Grid -> Force Restore Grid -> From Local File or From TFTP Server or From FTP Server
or From Grid Master.
or
From the Device perspective, click Device -> Force Restore Device -> From Local File or From TFTP Server or From
FTP Server or From Grid.
3. Grid Master IP Address Option:
From Local File: In the Force Restore Grid From Local File dialog box, indicate whether you want the
appliance to keep its current grid master IP settings or to obtain its IP settings from the backup, and then
click OK.
Navigate to the location of the configuration file, select the file, and then click OK.
or
From TFTP Server: In the Force Restore Grid From TFTP dialog box, enter the following, and then click OK:
TFTP Server IP Address: Type the IP address of the TFTP server in whose root directory the backup
file is stored.
File Name: Type the name of the backup file. (Because the file must be in . t ar . gz format, the file
type is included as a read-only extension of the file name.)
Grid Master IP Address Option: Indicate whether you want the appliance to keep its current grid
master IP settings or to obtain its IP settings from the backup.
or
From FTP Server: In the Force Restore Grid From FTP dialog box, enter the following, and then click OK:
FTP Server IP address: Type the IP address of the FTP server in whose root directory the backup file
is stored.
File Name: Type the name of the backup file. Do not include .tar.gz at the end of the file name.
User Name: Type the name of the FTP server account.
Password: Type the password of the FTP server account.
Retype Password: To ensure accuracy, type the account password again.
or
From grid: In the Force Restore From Grid Master dialog box, enter the following, and then click OK:
Select a backup file from the drop-down list, and then click OK.
4. When the Confirm Grid Restore confirmation message appears, click OK to load the backup file.
After the file loads, the appliance reboots.
5. Close your current browser window or JWS (Java Web Start) application, wait a few minutes, and then reconnect
Downloading a Support Bundle
Downloading a Support Bundle
When you need assistance troubleshooting a NIOS appliance, you can log in to the appliance as a superuser,
download the support bundle of the appliance and send it to Infoblox Support for analysis. A support bundle is a
tar.gz file that contains configuration files and the appliance system files. You can download a support bundle for an
independent appliance and for each member in a grid. When you download a support bundle for an HA pair, it
includes the files of both nodes in the HA pair.
By default, the appliance includes the following files in the support bundle: core files, log files, VitalQIP files (if a
VitalQIP license is installed on the appliance). Because core files can be quite large and take a significant amount of
time to download, Infoblox recommends that you include core files in the support bundle only when requested by
Infoblox Support.
To download a support bundle:
1. From the Grid perspective, click + (for grid ) -> + (for Members ) -> grid_member -> Tools -> Download Support
Bundle.
or
From the Device perspective, click hostname -> Tools -> Download Support Bundle.
2. In the Download Support Bundle dialog box, select which files you would like to include in the support bundle,
and then click OK:
Core Files: Infoblox recommends that you include these files only when requested by Infoblox Support.
Log Files: Infoblox recommends that you always include these files in the support bundle.
QIP: If a VitalQIP license is installed on the appliance, include the VitalQIP files in the support bundle.
3. In the Save as... dialog box, navigate to where you want to save the file and change the file name. Do not change
the . t ar . gz file extension in the file name.
4. Send this file to Support in an e-mail message.

Part 2 Appliance Deployment
This section provides information about deploying and managing independent appliances and grids. It includes the
following chapters:
Chapter 8, "Deploying Independent Appliances", on page 231
Chapter 9, "Deploying a Grid", on page 267

Chapter 8 Deploying Independent
Appliances
This chapter explains how to deploy single independent appliances and independent HA pairs. Independent
appliances run NIOS without the Keystone upgrade and are deployed independently from a grid. The user guide or
quick start guide that ships with your product explains how to connect ethernet cables and power cords before
configuring a NIOS appliance as a single independent appliance and an independent HA pair. Refer to these guides
when necessary as you read this chapter. There is also cabling information for Infoblox-500, -1000, and -1200
appliances in Connecting the Ethernet Cables on page 725.
The topics in this chapter include:
Independent Deployment Overview on page 232
Deploying a Single Independent Appliance on page 233
Method 1 Using the LCD on page 234
Method 2 Using the CLI on page 234
Method 3 Using the Infoblox NIOS Startup Wizard on page 236
Method 4 Using the GUI on page 237
Configuration Example: Deploying a NIOS Appliance for External DNS on page 238
Deploying an Independent HA Pair on page 245
Method 1 Using the Infoblox NIOS Startup Wizard on page 247
Method 2 Using the GUI on page 249
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP on page 251
Verifying the Deployment on page 263
Single Independent Appliance on page 263
Independent HA Pair on page 263
Forcing an HA Failover on page 263
Infoblox Tools for Migrating Data on page 264
Upgrading Software on an Independent Appliance or HA Pair on page 265
Acquiring Software Upgrade Files on page 265
Distributing Software Upgrade Files on page 265
Running the Software Upgrade on page 265
Deploying Independent Appliances
Independent Deployment Overview
You can deploy NIOS appliances collectively in a grid or independently (in what is sometimes referred to as a
stand-alone deployment). Although grids offer many advantages for large organizations, an independent
deployment might be sufficient for smaller sites. For example, if your ISP hosts one name server to respond to
external DNS queries, it might be enough to deploy a single independent NIOS appliance as the other name server,
as shown in Figure 8.1.
Note: You cannot deploy a NIOS virtual appliance as a single, independent appliance.
Figure 8.1 Single Independent Appliance as an External DNS Server
Using primary and secondary name servers provides DNS protocol redundancy and configuring two DHCP servers as
DHCP failover peers provides DHCP protocol redundancy. However, you can only have hardware redundancy if you
deploy appliances in an HA (high availability) pair. Should the active node in an HA pair fail, the passive node
becomes active and begins serving data, as shown in Figure 8.2.
Figure 8.2 Independent HA Pair
The following sections describe the procedures for deploying independent appliances singly and in HA pairs.
ISP
Site
Internal
Network
Firewall
Servers for Public Access
Internet
Switch
domain name =
corp100.com
The primary and secondary name servers
provide DNS protocol redundancy. If one
of them cannot respond to a query for the
corp100.com domain, the other can.
A NIOS appliance is the primary DNS server
for the corp100.com domain. It answers
queries from the Internet for public-facing
servers in the DMZ network.
The ISP hosts a secondary
DNS server for the
corp100.com domain.
LAN or
LAN1 Port
DMZ
The ISP hosts a secondary
DNS server for the
corp100.com domain.
This is the same situation as that in Figure 8.1,
but the primary DNS server is an independent
HA pair to provide hardware redundancy.
ISP
Site
Firewall
Primary DNS Server
(Independent HA Pair)
Internet
Active Node
Secondary
DNS Server
If the active node fails,
the passive node
becomes active and
continues serving DNS. Internal
Network
Switch
LAN (LAN1)
and HA Ports
LAN (LAN1)
and HA Ports
Servers for Public Access
Passive Node
DMZ
Deploying a Single Independent Appliance
To deploy a single independent NIOS appliance, you cable its LAN or LAN1 port to the network and change its default
IP settings so that it can connect to its surrounding IP address space. The default LAN settings are as follows:
IP address: 192.168.1.2
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Note: On Infoblox-500, -1000, and -1200 appliances, the LAN port is labeled LAN. On Infoblox-550, -1050, -1550,
and -1552 appliances, use the port labeled LAN1. (The LAN2 port on these appliances is reserved for future
use.)
Infoblox provides the following methods for performing a basic configuration to deploy a single independent
appliance:
Method 1 Using the LCD
Requirements: Physical access to a powered up NIOS appliance
Advantage: You do not need any other equipment.
Method 2 Using the CLI
Requirements: A serial connection from your management system to the console port on the NIOS
appliance (You can also enable remote console access so that you can use the CLI over a network
connection. For information, see Enabling Remote Console Access on page 128.)
Advantage: You do not have to change the IP address of the management system to connect to the NIOS
appliance.
Method 3 Using the Infoblox NIOS Startup Wizard
Requirements: An HTTPS connection from your management system to the LAN or LAN1 port on the NIOS
appliance
Advantage: The wizard provides step-by-step guidance for changing not only IP settings for the LAN or LAN1
port, but also changing the appliance host name and admin password, setting the system clock, andif
using NTP (Network Time Protocol)enabling the NIOS appliance to be an NTP server.
Method 4 Using the GUI
Requirements: An HTTPS connection from your management system to the LAN or LAN1 port on the NIOS
appliance
Advantage: If you have logged in previously and disabled the startup wizard, you can still use the GUI to
configure the LAN network settings.
These methods are explained in the following subsections.
After you set the network settings, you can then migrate data and settings from legacy DNS and DHCP servers to the
NIOS appliances. Several tools and methods are available for migrating data and configuration settings. For a list of
the available options, see Infoblox Tools for Migrating Data on page 264.
Method 1 Using the LCD
NIOS appliances have an LCD and navigation buttons on the front panel that allow you to view system status and
license information as well as configure network settings for the LAN or LAN1 port.
Figure 8.3 Infoblox LCD and Navigation Buttons
You can deploy a single independent NIOS appliance by setting its LAN or LAN1 port IP address, netmask, and
gateway through the LCD. This is the simplest method because you do not need anything other than physical access
to the appliance to complete the initial configuration.
1. Connect the power cable from the NIOS appliance to a power source and turn on the power.
At startup, the Infoblox logo appears in the LCD on the front panel of the appliance. Then the LCD scrolls
repeatedly through a series of display screens.
2. To change the network settings for the LAN or LAN1 port, press one of the navigation buttons.
The LCD immediately goes into input mode, in which you can enter the IP address, netmask, and gateway for the
LAN or LAN1 port.
3. Use the navigation buttons to enter an IP address, netmask, and gateway address for the LAN or LAN1 port.
4. Cable the LAN or LAN1 port of the NIOS appliance to a network as described in Independent Appliance Cabling
Using the LAN or Serial Port on page 725.
Method 2 Using the CLI
The Infoblox CLI allows you to make an initial network configuration through the set net wor k command. To access
the CLI, make a direct serial connection from your management system.
Note: You can also access the CLI from a remote location using an SSHv2 client. By default, remote console access
that is, SSHv2 (Secure Shell version 2) accessis disabled. You must first enable remote console access
through the GUI or CLI, and then you can make an SSHv2 connection to the appliance.
1. Connect a console cable from the console port on your workstation to the male DB-9 console port on the NIOS
appliance.
The DB-9 pin assignments follow the EIA232 standard. You can use the RJ-45 rollover cable and two female
RJ-45-to-female DB-9 adapters that ship with the appliance, or a female DB-9-to-female DB-9 null modem cable.
Infoblox
LCD Navigation Buttons
The LCD panel is on the
front of a NIOS appliance.
Figure 8.4 Console Connection
2. Using a serial terminal emulation program such as Hilgraeve Hyperterminal
(provided with Windows

operating systems), launch a session. The connection settings are:
Bits per second: 9600
Data bits: 8
Parity: None
Stop bits: 1
Flow control: Xon/Xoff
3. Log in using the default user name and password admin and infoblox . User names and passwords are
case-sensitive.
4. To change the network settings from the default, enter the set network command. Then enter information as
prompted to change the IP address, netmask, and gateway for the LAN or LAN1 port.
Note: In the following commands, the variable ip_addr1 is the IP address of the LAN or LAN1 port and ip_addr2 is
the IP address of the gateway for the subnet on which you set the ip_addr1 address.
I nf obl ox > set network
NOTI CE: Al l HA conf i gur at i on i s per f or med f r omt he GUI . Thi s i nt er f ace i s used onl y
t o conf i gur e a st andal one node or t o j oi n a gr i d.
Ent er I P addr ess: ip_addr1
Ent er net mask: [ Def aul t : 255. 255. 255. 0] : netmask
Ent er gat eway addr ess [ Def aul t : n. n. n. 1] : ip_addr2
Become gr i d member ? ( y or n) : n
After you confirm your network settings, the Infoblox application automatically restarts.
5. Cable the LAN or LAN1 port to a network as described in Independent Appliance Cabling Using the LAN or Serial
Port on page 725.
Management
System
NIOS
appliance
Male DB-9
Console Port
Male DB-9
Console Port
RJ -45 Rollover Cable with
Two RJ -45-to-Female DB-9 Adapters
(Ships with Every Appliance)
or
Female DB-9-to-Female DB-9 Null Modem Cable
To Power
Source
When you first make an HTTPS connection to a NIOS appliance, the Infoblox NIOS Startup Wizard appears. To ease
the initial configuration process, the wizard guides you through various deployment options and basic network
settings, and presents opportunities for changing the password of the superuser admin and for setting the system
clock.
To make an HTTPS connection to the appliance, you must be able to reach its IP address from your management
system.
Note: If you have already set the IP address of the LAN or LAN1 port through the LCD or CLI so that you can reach it
over the networkand you have already cabled the appliance to the networkyou can skip the first step.
1. If you have not changed the default IP address (192.168.1.2/24) of the LAN or LAN1 port through the LCD or CLI
and the subnet to which you connect the appliance does not happen to be 192.168.1.0/24put your
management system in the 192.168.1.0/24 subnet and connect an ethernet cable between your management
system and the NIOS appliance.
2. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port. (To reach the
default IP address, enter: https://192.168.1.2)
Several certificate warnings appear during the login process. This is normal because the preloaded certificate is
self-signed (and, therefore, is not in the trusted certificate stores in your browser, Java application, and Java
Web Start application) and has the hostname www.infoblox.com, which does not match the destination IP
address you entered in step 1. To stop the warning messages from occurring each time you log in to the GUI, you
can generate a new self-signed certificate or import a third-party certificate with a common name that matches
the FQDN (fully qualified domain name) of the appliance. This is a very simple process. For information about
certificates, see Managing Certificates on page 48.
3. Click LAUNCH DEVICE MANAGER.
4. Log in to the NIOS appliance. The default login name and password are admin and infoblox. For detailed
information about logging in to the GUI, see Accessing the Infoblox GUI on page 38.
The Infoblox NIOS Startup Wizard appears. The first screen provides basic information about the wizard, and the
second screen displays license agreement information.
5. Beginning on the third screen, enter the following, where
ip_addr1 and netmask are the IP address and netmask of the LAN or LAN1 port
ip_addr2 is the IP address of the gateway for the subnet on which the LAN or LAN1 port is set
hostname is a valid domain name for the appliance
string is a single alphanumeric string (no spaces) for a password that is at least four characters long
ip_addr3 is the IP address of an NTP server:
Wizard Screen Enter or Select
Deployment Type Independent Device or HA Pair
Independent Device Deployment Type Independent Device
Network Settings IP Address: ip_addr1
Netmask: netmask
Gateway: ip_addr2
Host Name: hostname
Admin Account Password Change Admin Password: (select), string
Note: The startup wizard provides options such as not changing the default password and manually entering the
time and date. However, changing the password and using an NTP server provide increased security and
accuracy (respectively), and so these choices are presented above.
The last screen of the startup wizard states that the changed settings require the application to restart. When
you click Finish, it restarts.
6. Open a new web browser instance and make an HTTPS connection to the new IP address of the LAN or LAN1 port.
7. Log back in using the default user name (admin ) and your new password. When you log in the second time, you
access the Infoblox GUI application. For system requirements to use the GUI, see Management System
Requirements on page 38.
To deploy a single independent appliance through the GUI, make an HTTPS connection to the appliance and then
bypass the startup wizard. (The following procedure assumes that the appliance has the DNSone package installed.)
Note: The ethernet ports on the Infoblox-550, -1050, -1550, and -1552 appliances are autosensing, so you can
use either a straight-through or cross-over ethernet cable for this connection. For the Infoblox-500, -1000,
and -1200 appliances, use a cross-over ethernet cable to connect the appliance to your management
system and a straight-through ethernet cable to connect the appliance to a switch.
2. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port. To reach the
default IP address, enter: https://192.168.1.2 . For detailed information on logging in to the GUI, see Accessing
the Infoblox GUI on page 38.
4. Log in using the default user name (admin ) and password (infoblox ).
The Infoblox NIOS Startup Wizard appears.
5. To bypass the wizard, click Cancel or the Close button ().
6. From the Device perspective, click infoblox.localdomain -> Edit -> Device Properties.
7. In the Device editor, click Device Properties, and then enter the following network settings:
Host Name: Type the FQDN (fully qualified domain name) of the appliance.
(V)IP Address: Type the IP address of the LAN or LAN1 port.
Subnet Mask: Choose the netmask for the subnet to which the LAN or LAN1 port connects.
Gateway: Type the IP address of the default gateway of the subnet to which the LAN or LAN1 port connects.
Comment: Type a comment that provides some useful information about the appliance, such as its
location.
8. Click Save, and then close the management window.
9. Initiate a new management session, and log in to the appliance using its new IP address.
Time Settings Enable NTP: (select)
NTP Server List: ip_addr3 (click Add)
Time zone: (choose the time zone for the location of the
appliance)
Configuration Example: Deploying a NIOS Appliance for External DNS
In this example, you configure the NIOS appliance as the external primary DNS server for corp100.com. Its FQDN
(fully-qualified domain name) is ns1.corp100.com. The interface IP address of the LAN1 port is 10.1.5.2/24. Because
this is a private IP address, you must also configure the firewall to perform NAT (network address translation),
mapping the public IP address 1.1.1.2 to 10.1.5.2. Using its public IP address, ns1 can communicate with appliances
on the public network.
The FQDN and IP address of the external secondary DNS server are ns2.corp100.com and 2.2.2.2. The ISP hosts this
server.
The primary and secondary servers answer queries for the following public-facing servers in the DMZ:
www.corp100.com
mail.corp100.com
ftp.corp100.com
When you create the corp100.com zone on the NIOS appliance, you import zone data from the legacy DNS server at
10.1.5.3.
Figure 8.5 Example 1 Network Diagram
The NIOS appliance is the external primary DNS server for the corp100.com domain. It answers queries from
the Internet for the three public-facing servers in the DMZ network:
www.corp100.com
mail.corp100.com
ftp.corp100.com
Internet
ISP
External Secondary DNS Server
ns2: 2.2.2.2
NTP Server
3.3.3.3
The device is in the Pacific
time zone (UMT-8:00)
ftp
10.1.5.7
www
10.1.5.5
NAT on Firewall
1.1.1.2 >10.1.5.2
1.1.1.5 >10.1.5.5
1.1.1.6 >10.1.5.6
1.1.1.7 >10.1.5.7
DMZ Network
10.1.5.0/24
mail
10.1.5.6
Switch
NIOS appliance
External Primary
DNS Server
ns1: 10.1.5.2
ethernet2
10.1.5.1/24
ethernet1
1.1.1.1/24
Firewall
To Internal
Network
Legacy Primary DNS Server
ns1: 10.1.5.3
(Replaced by the NIOS appliance)
Cable the Appliance to the Network and Turn On Power
Connect an ethernet cable from the LAN1 port of the NIOS appliance to a switch in the DMZ network and turn on the
power. For information about installing and cabling the appliance, refer to the user guide or installation guide that
ships with the product.
Specify Initial Network Settings
Before you can configure the NIOS appliance through the GUI, you must be able to make a network connection to it.
The default network settings of the LAN1 port are 192.168.1.2/24 with a gateway at 192.168.1.1 (the HA and MGMT
ports do not have default network settings). To change these settings to suit your network, use either the LCD or the
console port.
In this example, you change the IP address/netmask of the LAN1 port to 10.1.5.2/24, and the gateway to 10.1.5.1.
LCD
The NIOS appliance has an LCD and navigation buttons on its front panel.
At startup, the Infoblox logo appears in the LCD on the front panel of the appliance. Then the LCD scrolls repeatedly
through a series of display screens.
1. To change the network settings from the default, press one of the navigation buttons.
The LCD immediately goes into input mode, in which you can enter the IP address, netmask, and gateway for the
LAN1 port.
2. Use the navigation buttons to enter the following information:
IP Address: 10.1.5.2
Netmask: 255.255.255.0
Gateway: 10.1.5.1
Console Port
The NIOS appliance has a male DB-9 console port on the front panel. You can log in to the appliance through this port
and specify initial network settings using the Infoblox CLI.
1. Connect a console cable from the console port of the management system to the console port of the NIOS
appliance.
2. Access the Infoblox CLI. For more information about the Infoblox CLI, refer to the Infoblox CLI Guide.
3. To change the network settings from the default, enter the set network command. Then enter information as
prompted to change the IP address, netmask, and gateway for the LAN1 port.
NOTI CE: Al l HA conf i gur at i on i s per f or med f r omt he GUI . Thi s i nt er f ace i s used onl y t o
conf i gur e a st andal one node or t o j oi n a gr i d.
Ent er I P addr ess: 10.1.5.2
Ent er net mask: [ Def aul t : 255. 255. 255. 0] :
Ent er gat eway addr ess [ Def aul t : 10. 1. 5. 1] :
Become gr i d member ? ( y or n) : n
After you confirm your network settings, the appliance automatically restarts.
Specify Appliance Settings
When you make the initial HTTPS connection to the NIOS appliance, you see the Appliance Startup Wizard, which
guides you through the basic deployment of the appliance on your network. Use the wizard to enter the following
information:
Deployment: single independent appliance
Host name: ns1.corp100.com
Password: SnD34n534
NTP (Network Time Protocol) server: 3.3.3.3; time zone: (UMT 8:00 Pacific Time (US and Canada), Tijuana
1. Open a browser window and enter https://10.1.5.2.
2. Accept the certificate when prompted.
the FQDN (fully-qualified domain name) of the appliance. This is a very simple process. For information about
4. If the browser prompts you for an application to use, see Accessing the Infoblox GUI on page 38.
5. Log in using the default user name and password admin and infoblox.
Note: User names and passwords are case-sensitive.
6. The Infoblox Appliance Startup Wizard opens with a splash screen that provides basic information about the
wizard, and then displays license agreement information. Beginning on the third screen, enter the following:
The last screen of the wizard states that the changed settings require the application to restart. When you click
Finish, the Infoblox GUI application restarts.
7. Log back in to the appliance. When you log in the second time, you access the Infoblox GUI application. For
system requirements to use the GUI, see Management System Requirements on page 38.
Deployment type Standalone
Node type Standalone appliance
Node information Host name: ns1.corp100.com
Default password Change admins password: (select), SnD34n534
Time settings Enable NTP: (select)
NTP Server: 3.3.3.3 (click Add)
Time zone: (UMT 8:00 Pacific Time (US and Canada),
Tijuana
Define a NAT Address
Because the firewall translates the public IP address 1.1.1.2 to the interface IP address 10.1.5.2, all DNS queries
originating outside the firewall use 1.1.1.2 (not 10.1.5.2) to reach the NIOS appliance. Accordingly, you must
configure the appliance to indicate to other external DNS servers that its address is 1.1.1.2.
1. From the Device perspective, click ns1.corp100.com -> Edit -> Device Properties.
2. In the Device editor, click NAT and enter the following:
Enable NAT compatibility: Select check box.
Group: None
NAT (V)IP Address: 1.1.1.2
The glue record is an A record for a name server. The appliance automatically generates the A record for
ns1.corp100.com using either the interface address or NAT address (if configured). To verify that the A record uses
the NAT address (1.1.1.2) instead of the interface address (10.1.5.2):
1. Click DNS to open the DNS perspective, and then click DNS Members -> + (for Infoblox) -> ns1.corp100.com -> Edit
-> Member DNS Properties.
2. In the Member DNS Properties editor, click General.
3. In the table labelled Possible views for member, select the default view and click Modify.
4. In the Select Member Address dialog box, select NAT IP address.
Enable Zone Transfers on the Legacy Name Server
To allow the appliance to import zone data from the legacy server at 10.1.5.3, you must configure the legacy server
to allow zone transfers to the appliance at 10.1.5.2.
Legacy BIND Server
1. Open the named.conf file using a text editor and change the allow-transfer statement as shown below:
For All Zones To set the allow-transfer statement as a global statement in the named.conf file for all zones:
opt i ons {
zone- st at i st i cs yes;
di r ect or y "/ var / named/ named_conf " ;
ver si on " " ;
r ecur si on yes;
l i st en- on { 127. 0. 0. 1; 10. 1. 5. 3; };
allow-transfer {10.1.5.2; };
t r ansf er - f or mat many- answer s;
};
For a Single Zone To set the allow-transfer statement in the named.conf file for the corp100.com zone:
zone " cor p100. com" i n {
t ype mast er ;
allow-transfer {10.1.5.2; };
not i f y yes;
};
2. After editing the named.conf file, restart DNS service for the change to take effect.
Legacy Windows 2000/2003 Server
1. Click Start -> All Programs -> Administrative Tools -> DNS.
2. Click + (for ns1) -> + (for Forward Lookup Zones) -> corp100.com.
3. Right-click corp100.com, and then select Properties -> Zone Transfers.
4. On the Zone Transfers page in the corp100.com Properties dialog box, enter the following:
5. Allow zone transfers: Select check box.
6. Only to the following servers: Select.
7. IP address: Enter 10.1.5.2, and then click Add.
8. To save the configuration change and close the corp100.com Properties dialog box, click OK.
Import Zone Data
You can import zone data from a legacy server or manually enter it. When you import both forward- and
reverse-mapping zone data, the NIOS appliance automatically creates Infoblox host records if corresponding A and
PTR records are present. You can then modify the host records to add MAC addresses. However, if you only import
forward-mapping zone data, the NIOS appliance cannot create host records from just the A records. In that case,
because you cannot later convert A records to host records, it is more efficient to create the corp100.com zone, and
define host records manually.
Infoblox host records are data models that represent IP devices within the Infoblox semantic database. The NIOS
appliance uses a host object to define A, PTR, and CNAME resource records in a single object as well as a DHCP fixed
address if you include a MAC address in the host object definition. The host object prevents costly errors because
you only maintain a single object for multiple DNS records and a DHCP fixed address. Therefore, it is advantageous
to use host records instead of separate A, PTR, and CNAME records.
Note: If you only have forward-mapping zones on your legacy servers and you want to add reverse-mapping zones
and automatically convert A records to host records in the imported forward-mapping zones and create reverse
host records in corresponding reverse-mapping zones, create the reverse-mapping zones on the NIOS
appliance and then import the forward-mapping zones data. The NIOS appliance automatically converts the
imported A records to host records in the forward-mapping zones and creates reverse host records in the
reverse-mapping zones.
You also have the option of using the Data Import Wizard for loading DNS and DHCP configurations and data. For large
data sets, this option is an efficient approach. To download the Data Import Wizard, visit www.infoblox.com/support,
log in with your support account, and then click the Data Import Wizard hyperlink in the DNSone section.
In this example, when you create the corp100.com forward-mapping zone, you import zone data for the existing
corp100.com zone from the legacy server at 10.1.5.3. When you create the 1.1.1.0/24 reverse-mapping zone, you
also import the reverse-mapping zone records from the legacy server. After the appliance has both the forward- and
reverse-mapping zone data, it converts the A and PTR records to Infoblox host records.
1. Open a browser window, and log in to the appliance at https://10.1.5.2, using the user name admin and the
password SnD34n534.
2. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> Forward Mapping
Zones -> Edit -> Add Forward Mapping Zone -> Authoritative.
3. In the Authoritative Zone Properties section of the Add Forward Authoritative Zone editor, enter the following:
Name: corp100.com
Comment: External DNS zone
4. In the Primary Server Assignment section, click Select Member to open the Select Grid Member dialog box.
5. Select ns1.corp100.com, and then click OK to close the dialog box.
6. In the Secondary Server Assignment section, click Add in the External Secondaries table to open the Zone
External Secondary Server Item dialog box.
7. Enter the following information, and then click OK to close the dialog box:
Name: ns2.corp100.com
IP Address: 2.2.2.2
Stealth: Clear check box.
9. Edit the zone that you just created as follows: in the Infoblox Views panel of the DNS perspective, click + (for
Forward Mapping Zones) -> corp100.com -> Edit -> Authoritative Zone Properties.
Note: To import zone data, you must first create a zone, save it, and then edit it.
10. In the Forward Authoritative Zone editor, click Settings and enter the following:
E-mail address: admin@corp100.com
Import zone from: Select check box, and enter 10.1.5.3 in the adjacent text field.
12. After successfully importing the zone data, click corp100.com in the Infoblox Views panel.
You can see all the imported forward-mapping zone data in the Records panel. Because you have not yet
imported the reverse-mapping zone data, most of the records appear as A records.
13. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> Reverse Mapping
Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
14. In the Authoritative Zone Properties section of the Add Reverse Authoritative Zone editor, enter the following:
Network Address: 1.1.1.0
Subnet Mask: /24 (255.255.255.0)
Comment: External DNS zone
17. In the Secondary Server Assignment section, click Add in the External Secondaries table to open the Zone
External Secondary Server dialog box.
18. Enter the following information, and then click OK to close the dialog box:
Name: ns2.corp100.com
IP Address: 2.2.2.2
Stealth: Clear check box.
20. In the Infoblox Views panel of the DNS perspective, click + (for Reverse Mapping Zones) -> 1.1.1.in-addr.arpa ->
Edit -> Authoritative Zone Properties.
21. In the Authoritative Reverse Zone editor, click Settings and enter the following:
Import zone from: Select check box, and enter 10.1.5.3 in the adjacent text field.
23. Click 1.1.1.in-addr.arpa -> View -> Records.
You can see all the imported reverse-mapping zone data in the Records panel.
24. Click corp100.com in the Forward Mapping Zones list.
Because you have now imported both the forward- and reverse-mapping zone data, most of the records appear
as host records.
25. Finally, you must remove the ns1 host record for the legacy server (value 1.1.1.3). To remove it, select ns1 (the
host record for 1.1.1.3), and then click Edit -> Remove.
Designate the New Primary on the Secondary Name Server (at the ISP Site)
In this example, the external secondary name server is maintained by an ISP, so you must contact your ISP
administrator to change the IP address of the primary (or master) name server. (If you have administrative access to
the secondary name server, you can make this change yourself.)
Because a firewall performing NAT exists between the secondary and primary name servers, specify the NAT address
1.1.1.2 for the primary name server instead of 10.1.5.2.
Secondary BIND Server
1. Open the named.conf file using a text editor and set ns1 (with NAT address 1.1.1.2) as the primary (or master)
from which ns2 receives zone transfers in the named.conf file for the corp100.com zone:
zone " cor p100. com" i n {
t ype sl ave;
masters {1.1.1.2;};
not i f y yes;
f i l e / var / named/ db. cor p100. com;
};
Secondary Windows 2000/2003 Server
2. Click + (for ns2) -> + (for Forward Lookup Zones) -> corp100.com.
3. Right-click corp100.com, and then select Properties -> General.
4. On the General page in the corp100.com Properties dialog box, enter the following:
Zone file name: corp100.com.dns
IP address: Enter 1.1.1.2, and then click Add.
In the IP Address field, select 1.1.1.3 (the NAT IP address of the legacy DNS server), and then click Remove.
5. To save the configuration change and close the corp100.com Properties dialog box, click OK.
Configure NAT and Policies on the Firewall
Change the NAT and policy settings on the firewall to allow bidirectional DNS traffic to and from ns1.corp100.com and
NTP traffic from ns1.corp100.com to the NTP server at 3.3.3.3.
For example, enter the following commands on a Juniper firewall running ScreenOS 4.x or later:
set address dmz ns1 10.1.5.2/32
set address untrust ntp_server 3.3.3.3/32
set interface ethernet1 mip 1.1.1.2 host 10.1.5.2
set policy from dmz to untrust ns1 any dns permit
set policy from untrust to dmz any mip(1.1.1.2) dns permit
set policy from dmz to untrust ns1 ntp_server ntp permit
At this point, the new DNS server can take over DNS service from the legacy server. You can remove the legacy server
and unset any firewall policies permitting traffic to and from 10.1.5.3.
Deploying an Independent HA Pair
An independent HA (high availability) pair provides hardware redundancy for the source of your network identity
services. The two nodes that form an HA pairidentified as Node 1 and Node 2are in an active/passive
configuration. The active node receives, processes, and responds to all service requests. The passive node constantly
keeps its database synchronized with that of the active node, so it can take over service if a failover occurs. (A failover
is basically the reversal of the active/passive roles of each node; that is, when a failover occurs, the previously active
node becomes passive and the previously passive node becomes active.) Events can trigger a failover or you can
deliberately force it to happen (see Forcing an HA Failover on page 263).
So that the two physical nodes can appear as a single entity on the network, they share a single VIP (virtual IP)
address and virtual MAC address. The VIP and virtual MAC addresses link to the HA port on each node. Whichever
node is currently active is the one whose HA port owns the VIP and virtual MAC addresses. If a failover occurs, these
addresses shift from the HA port of the previous active node to the HA port of the new active node (see Figure 8.6).
Figure 8.6 VIP Address and Virtual MAC Address and HA Failover
The HA ports on each node of an HA pair
share the VIP (virtual IP) address and
virtual MAC address. Because Node 1 is
currently active, it owns these addresses.
HA Port HA Port
VIP
and
Virtual MAC
Address
Node 1
Active
Node 2
Passive
bloxSYNC
The clients always make service requests
toand receive replies fromthe VIP
and virtual MAC address.
Infoblox HA Pair
Network Clients
Node 2
Active
Node 1
Passive
Encrypted VPN Tunnel
After an HA Failover
VIP
and
Virtual MAC
Address
The clients still make service requests
toand receive replies fromthe
same VIP and virtual MAC address.
After an HA failover occurs, Node 2
becomes the active node. Because Node 2
is now active, it now owns the VIP address
and virtual MAC address.
Network Clients
HA Port HA Port
The two nodes in an HA pair include a VRID (virtual router ID) in all VRRP advertisements and use it to recognize VRRP
advertisements intended just for themselves. Only another appliance on the same subnet configured to use the same
VRID responds to the announcements. The VRID must be a unique number between 1 and 255 for the subnet on
which the HA pair is located. (There is no default VRID number.) For more information, see RFC 3768, Virtual Router
Redundancy Protocol (VRRP), and also VRRP Advertisements on page 280.
Figure 8.7 VRRP Advertisements with a Unique VRID
To deploy an independent HA pair, you cable the HA and LAN (or LAN1) ports to the network and configure the IP
settings for these ports and the VIP address within the same subnet.
Note: On Infoblox-500, -1000, and -1200 appliances, the LAN port is labeled LAN . On Infoblox-550, -1050, -1550,
and -1552 appliances, use the port labeled LAN1 . (The LAN2 port is reserved for future use.)
The default LAN settings are as follows:
IP address: 192.168.1.2
Netmask: 255.255.255.0
Gateway: 192.168.1.1.
Infoblox provides two methods for configuring an HA pair:
Requirements: HTTPS connections from your management system to the ethernet ports on the two
appliances
Advantage: The startup wizard provides step-by-step guidance for configuring the network settings of the
VIP address and HA and LAN (or LAN1) ports on both nodes, for setting the host name, admin password,
and system clock, andif using NTP (Network Time Protocol)for enabling the HA pair as an NTP server.
Requirements: HTTPS connections from your management system to the ethernet ports on the two
appliances
Advantage: If you have logged in previously and disabled the startup wizard, you can still use the GUI to
configure an independent HA pair.
These methods are explained in the following subsections.
MATCH!
After you finish configuring Node 1 of the HA pair to use
VRID 10a number that is unique for this subnetit starts
listening for VRRP advertisements with that VRID. When it
does not receive any for three seconds, it becomes the
active node in the HA pair and begins multicasting VRRP
advertisements with a VRID 10 from its HA port.
Any device on that subnet that is not
configured to listen for VRRP advertisements
with VRID 10 drops the packet.
VRRP
Advertisements
Switch
Subnet
Node 1
(Active)
Node 2
(Passive)
After you finish configuring Node 2
to join the HA pair, it initiates a
connection with Node 1. The two
appliances establish a VPN tunnel
between themselves, using the HA
connection name and shared
secret to authenticate each other.
Node 2 downloads the database
from Node 1 and learns its VRID.
Node 2 then begins listening for
VRRP advertisements on its HA
port. When it receives an
advertisement from Node 1, Node
2 recognizes it and becomes the
passive node.
When you first make an HTTPS connection to the NIOS appliance, the Infoblox NIOS Startup Wizard appears. To ease
the initial configuration process, the wizard guides you through various deployment options, basic network settings,
and opportunities for changing the password of the superuser admin and for setting the system clock.
Configuring the Connecting Switch
To ensure that VRRP (Virtual Router Redundancy Protocol) works properly, configure the following settings on the
network switch to which you cable the two nodes:
Portfast: enable
Trunking: disable
Port list: disable
Port channeling: disable
Note: By default, a NIOS appliance automatically negotiates the optimal connection speed and transmission type
(full or half duplex) on the physical links between its LAN (or LAN1), HA, and MGMT ports and the ethernet
ports on the connecting switch. If the two appliances fail to auto-negotiate the optimal settings, see Modifying
Ethernet Port Settings on page 135 for steps you can take to resolve the problem.
Putting Both Nodes on the Network
1. Use one of the methods described in Deploying a Single Independent Appliance on page 233 to configure the
network settings of the LAN or LAN1 port of each node so that they are on the same subnet and you can reach
them across the network.
2. Cable the LAN (or LAN1) port and the HA port on each node to the network switch.
use either a straight-through or cross-over ethernet cable for these connections. For the Infoblox-500,
-1000, and -1200 appliances, use straight-through ethernet cables to connect an appliance to a switch.
3. Cable your management system to the network switch.
Configuring Node 1
1. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port of Node 1.
3. Log in to Node 1. For detailed information about logging in to the GUI, see Accessing the Infoblox GUI on page 38.
string1 is a text string that the two nodes use to authenticate each other when establishing a VPN tunnel for
ensuing bloxSYNC traffic. (The default grid name is Infoblox.)
string2 is a text string that both nodes use as a shared secret to authenticate each other when establishing
a VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
vip_addr and netmask are the VIP (virtual IP) address and its netmask.
ip_addr1 is the IP address of the gateway for the subnet on which the LAN or LAN1 port is set.
hostname is a valid domain name for the appliance.
ip_addr2-5 are the IP addresses of the LAN and HA ports for Nodes 1 and 2.
number is the VRID (virtual router ID). This must be a unique VRID numberfrom 1 to 255for this subnet.
string3 is a single alphanumeric string (no spaces) for a password that is at least four characters long.
ip_addr6 is the IP address of an NTP (Network Time Protocol) server.
time and date. However, changing the password and using an NTP server improve security and accuracy
(respectively), and so these choices are presented above.
The last screen of the startup wizard states that the changed settings require the appliance to restart. When you
click Finish, the appliance restarts.
Independent Device Deployment Type HA Node 1
HA Pair Settings HA Pair Name: string1
Shared Secret: string2
Node 1 Network Settings VIP Address: vip_addr
Netmask: netmask
Gateway: ip_addr1
Host Name: hostname
Node 1: LAN/LAN1 Address: ip_addr2
HA Address: ip_addr3
Virtual Router ID: number
Admin Account Password Change Admin Password: (select), string3
appliance)
Configuring Node 2
1. Open a new browser instance and make an HTTPS connection to the IP address of the LAN or LAN1 port of Node 2.
2. The Infoblox NIOS Startup Wizard opens with a splash screen that provides basic information about the wizard,
and then displays license agreement information. Beginning on the third wizard screen, enter the following to set
up Node 2 (the variables are explained in the previous section for Node 1):
The setup of the HA pair is complete. When you next make an HTTPS connection to the HA pair, use the VIP address.
To deploy an independent HA pair through the GUI, you need to make an HTTPS connection to each appliance and
then bypass the startup wizard. (The following procedure assumes that the appliance has the DNSone package
installed.)
Portfast: enable
Trunking: disable
Port list: disable
Putting Both Nodes on the Network
1. Use one of the methods described in Deploying a Single Independent Appliance on page 233 to configure the
network settings of the LAN or LAN1 port of each node so that they are on the same subnet and you can reach
them across the network.
2. Cable the LAN (or LAN1) port and the HA port on each node to a switch on the network.
Note: The ethernet ports on a NIOS appliance are autosensing, so you can use either a straight-through or
cross-over ethernet cable for these connections. For the Infoblox-500, -1000, and -1200 appliances, use
straight-through ethernet cables to connect an appliance to a switch.
3. Connect your management system to the network.
Independent Device Deployment Type HA Node 2
Node 2 Network Settings IP Address: ip_addr4
Netmask: netmask
Gateway: ip_addr1
HA Pair Properties Virtual IP Address: vip_addr
HA Pair Name: string1
Configuring Node 1
3. Log in to Node 1. For detailed information about logging in to the GUI, see Accessing the Infoblox GUI on page 38.
4. To bypass the wizard and access the Device Manager GUI, click Cancel or the Close button ().
5. From the Device perspective, click hostname -> Edit -> Device Properties.
Note: (For the DNSone with Keystone package) From the Grid perspective, click + (for Infoblox) -> + (for Members)
-> hostname -> Edit -> Member Properties.
6. In the Device editor, click Device Properties, and then enter the following network settings:
Host Name: Type the FQDN (fully qualified domain name) for the HA pair.
(V)IP Address: Type the VIP (virtual IP) address for the HA pair.
Subnet Mask: Choose the netmask for the subnet to which the VIP address connects.
Gateway: Type the IP address of the default gateway of the subnet to which the VIP address connects.
Comment: Type a comment that provides some useful information about the HA pair, such as its location.
High-availability Pair: (select)
Virtual Router ID: Enter a unique VRID numberfrom 1 to 255for the local subnet.
Note: The VIP address and the IP addresses for all the following ports must be in the same subnet.
Node #1:
LAN Address: Enter an IP address for the LAN (or LAN1) port of Node 1.
HA Address: Enter an IP address for the HA port of Node 1.
Node #2:
7. In the Device editor, click High Availability Connection, and then enter the following settings:
Name: Type a name for the HA pair. (The default name is Infoblox.)
Shared Secret: Type the shared secret that both nodes use to authenticate each other when establishing a
VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
Retype Shared Secret: Retype the shared secret you entered in the Shared Secret field.
VPN Port Number: Leave as the default number (1194), or enter a different number for the two nodes to use
when building a VPN tunnel between themselves.
8. Click Save.
The management window closes.
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
Configuring Node 2
3. Log in to Node 2.
4. To bypass the wizard, click Cancel or the Close button ().
5. From the Device perspective, click hostname -> Edit -> Join HA Pair.
Note: For the DNSone with Keystone package, from the Grid perspective, click + (for Infoblox) -> + (for Members)
-> hostname -> Edit -> Join Grid.
6. In the Join HA Pair dialog box, enter the following network settings:
Virtual IP of HA Pair: Type the VIP (virtual IP) address for the HA pair.
HA Connection Name: Type the same text string that you typed in the Name field in the High Availability
Connection section of the Device editor on Node 1. The default HA connection name is Infoblox.
Shared Secret: Type the shared secret that both nodes use to authenticate each other when establishing a
VPN tunnel for ensuing bloxSYNC traffic. The default shared secret is test.
Retype Shared Secret: Retype the shared secret you entered in the Shared Secret field.
VPN Port Number: Leave as the default number (1194), or enter a different number for the two nodes to use
when building a VPN tunnel between themselves.
7. Click Save.
The management window closes.
Configuration Example: Configuring an HA Pair for Internal DNS
and DHCP
In this example, you set up an HA pair of NIOS appliances to provide internal DNS and DHCP services. The HA pair
answers internal queries for all hosts in its domain (corp100.com). It forwards internal queries for external sites to
ns1.corp100.com at 10.1.5.2 and ns2.corp100.com at 2.2.2.2. It also uses DHCP to provide dynamic and fixed
addresses.
The HA pair consists of two appliances (nodes). The IP addresses of the VIP (virtual IP) address of the HA pair and the
HA and LAN1 ports on each node, are as follows:
The virtual router ID number for the HA pair is 150. The ID number must be unique for this network segment.
When you create the corp100.com zone on the HA pair, you import DNS data from the legacy server at 10.1.4.11.
HA Pair IP Addresses
VIP 10.1.4.10 (the address that the active node of the HA pair uses)
Node 1 Node 2
LAN1 10.1.4.6
HA 10.1.4.7
LAN1 10.1.4.8
HA 10.1.4.9
Figure 8.8 Example 2 Network Diagram
Cable Appliances to the Network and Turn On Power
Connect ethernet cables from the LAN1 and HA ports on both NIOS appliances to a switch in the Server network and
turn on the power for both appliances. For information about installing and cabling the appliance, refer to the user
guide or installation guide that ships with the product.
An HA pair of NIOS appliances provides internal DNS services. It answers internal queries for all hosts in its
domain. It forwards internal queries for external sites to ns1 and ns2. It also serves DHCP, providing both
dynamic and fixed addresses. For information on configuring the NIOS appliance external primary DNS server,
see Configuration Example: Deploying a NIOS Appliance for External DNS on page 238.
MGT Network
Dev Network
10.1.1.0/24
10.1.1.10 -
10.1.1.50
10.1.2.10 -
10.1.2.50
10.1.2.0/24
Address
Range
Address
Range
printer1
10.1.1.2
aa:aa:aa
printer2
10.1.2.2
bb:bb:bb
ethernet2
10.1.2.1/24
ethernet1
10.1.1.1/24
ethernet0
10.1.6.1/24
ethernet4
10.1.4.1/24
External Primary
DNS Server
ns1: 10.1.5.2
ethernet1
1.1.1.1/24
ethernet2
10.1.5.1/24
ethernet3
10.1.6.2/24
Firewall
Relay Agent on
e2 interface)
External Secondary
DNS Server
ns2: 2.2.2.2
www
10.1.5.5
55:55:55:55
ftp
10.1.5.7
77:77:77:77
mail
10.1.5.6
66:66:66:66
DMZ Network
10.1.5.0/24
Internet
ISP
Server Network
HA Pair Internal Primary
DNS Server
DHCP, IPAM
ns3 VIP: 10.1.4.10
10.1.4.0/24
proxyweb
10.1.4.5
11:11:11:11
proxymail
10.1.4.f
ff:ff:ff:ff
storage2
10.1.4.3
ee:ee:ee:ee
storage1
10.1.4.2
dd:dd:dd:dd
Legacy Primary DNS Server
ns3: 10.1.4.11
(Replaced by the HA Pair)
NOTE: The first six
hexadecimal characters of
all MAC addresses in the
example are 00:00:00:00.
Only the last six
hexadecimal characters are
shown here.
Specify Initial Network Settings
Before you can configure the appliances through the GUI, you must be able to make a network connection to them.
The default network settings of the LAN1 port are 192.168.1.2/24 with a gateway at 192.168.1.1 (the HA and MGMT
ports do not have default network settings). To change these settings, you can use the LCD or make a console
connection to each appliance.
Node 1
Using the LCD or console port on one of the appliances, enter the following information:
IP Address: 10.1.4.6 (for the LAN1 port)
Netmask: 255.255.255.0
Gateway: 10.1.4.1
Node 2
Using the LCD or console port on the other appliance, enter the following information:
IP Address: 10.1.4.8 (for the LAN1 port)
Netmask: 255.255.255.0
Gateway: 10.1.4.1
After you confirm your network settings, the Infoblox GUI application automatically restarts.
Specify Appliance Settings
When you make the initial HTTPS connection to a NIOS appliance, you see the Infoblox Appliance Startup Wizard,
which guides you through the basic deployment of the appliance on your network. To set up an HA pair, you must
connect to and configure each appliance individually.
Node 1
1. Open a browser window and connect to https://10.1.4.6.
Note: For details about making an HTTPS connection to a NIOS appliance, see Specify Appliance Settings on
page 240.
wizard, and then displays license agreement information. Beginning on the third wizard screen, enter or select
the following to set up node 1 of the HA pair:
Wizard Screen Enter
Deployment type Stand alone
Node type First HA node
Grid information Grid Name: Infoblox
Shared Secret: 37eeT1d
(Note: The nodes use the shared secret to form an
encrypted VPN tunnel between themselves. They
synchronize the shared database through this tunnel.)
The last screen of the wizard states that the changed settings require the application to restart. When you click
Finish, the Infoblox GUI application restarts.
Node 2
1. In the JWS (Java Web Start) login window, type 10.1.4.8 in the Hostname field.
When you enter the IP address, JWS queries the appliance at that address, checking for a login banner. The
following default Infoblox banner appears above the Hostname field: Restricted Access Login Required.
wizard, and then displays license agreement information. Beginning on the third wizard screen, enter or select
the following to set up node 2 of the HA pair:
On the last screen of the wizard, click Finish. The Infoblox GUI application terminates.
Node information Virtual IP: 10.1.4.10
Subnet Mask: 255.255.255.0
Gateway: 10.1.4.1
Host Name: ns3.corp100.com
Node 1:
LAN1 Address: 10.1.4.6
HA Address: 10.1.4.7
Node 2:
Virtual Router ID: 150
Default password New admin password: SnD34n534
Time settings Enable NTP: Select check box.
IP address: 3.3.3.3
Tijuana
Deployment type Stand alone
Node type Second HA node
Node information IP Address: 10.1.4.8
Subnet Mask: 255.255.255.0
Gateway: 10.1.4.1
Node provisioning Masters Virtual IP: 10.1.4.10
Grid Name: Infoblox
Shared Secret: 37eeT1d
Wizard Screen Enter
The setup of the HA pair is complete. From now on, when you make an HTTPS connection to the HA pair, use the VIP
address 10.1.4.10.
Enable Zone Transfers on the Legacy Name Server
To allow the NIOS appliance to import zone data from the legacy server at 10.1.4.11, you must configure the legacy
server to allow zone transfers to the appliance at 10.1.4.10.
Legacy BIND Server
1. Open the named.conf file using a text editor and change the allow-transfer statement to allow zone transfers to
the appliance at 10.1.4.10. For a sample of the required changes to the named.conf file, see Legacy BIND Server
on page 241.
Legacy Windows 2000/2003 Server
Navigate to the corp100.com Properties dialog box, and add 10.1.4.10 to the list of IP addresses to which you want
to allow zone transfers. For more detailed navigation and configuration instructions, see Legacy Windows 2000/2003
Server on page 242.
Import Zone Data
You can import zone data from a legacy server or manually enter it. When you import both forward- and
reverse-mapping zone data, the NIOS appliance automatically creates Infoblox host records if corresponding A and
PTR records are present. You can then modify the host records to add MAC addresses. However, if you only import
forward-mapping zone data, the NIOS appliance cannot create host records from just the A records. In that case,
because you cannot later convert A records to host records, it is more efficient to create the corp100.com zone, and
define host records manually.
Infoblox host records are data models that represent IP devices within the Infoblox semantic database. The NIOS
appliance uses a host object to define A, PTR, and CNAME resource records in a single object as well as a DHCP fixed
address if you include a MAC address in the host object definition. The host object prevents costly errors because
you only maintain a single object for multiple DNS records and a DHCP fixed address. Therefore, it is advantageous
to use host records instead of separate A, PTR, and CNAME records.
Note: If you only have forward-mapping zones defined on your legacy servers and you want to add reverse-mapping
zones and automatically create host records in the imported forward-mapping zones and reverse host records
in corresponding reverse-mapping zones, create the reverse-mapping zones and then import the
forward-mapping zones data. The NIOS appliance automatically converts the imported A records to host
records in the forward-mapping zones and creates the necessary reverse host records in the reverse-mapping
zones.
You also have the option of using the Data Import Wizard for loading DNS and DHCP configurations and data. For large
data sets, this option is an efficient approach. To download the Data Import Wizard, visit www.infoblox.com/support,
log in with your support account, and then click the Data Import Wizard hyperlink in the DNSone section.
In this example, when you create the corp100.com forward-mapping zone, you import zone data for the existing
corp100.com zone from the legacy server at 10.1.4.11. When you create the 1.10.in-addr.arpa reverse-mapping
zone, you also import the zone records for the existing 1.10.in-addr.arpa zone from the legacy server. After the
appliance has both the forward- and reverse-mapping zone data, it converts the A and PTR records to Infoblox host
records.
1. Open a browser window, and log in to the HA pair at https://10.1.4.10, using the user name admin and the
password SnD34n534.
2. To check that the HA pair is set up and functioning properly, from the Device perspective, click ns3.corp100.com
and check that the status indicators are all green.
3. Click DNS to open the DNS perspective, and then click Infoblox Views -> + (for Infoblox Views) -> + (for default) ->
Forward Mapping Zones -> Edit -> Add Forward Mapping Zone -> Authoritative.
4. In the Authoritative Zone Properties section of the Add Forward Authoritative Zone editor, enter the following:
Name: corp100.com
Comment: Internal DNS zone
8. In the Infoblox Views panel of the DNS perspective, click + (for Forward Mapping Zones) -> corp100.com -> Edit ->
Authoritative Zone Properties.
9. In the Forward Authoritative Zone editor, click Settings and enter the following:
Import zone from: Select this check box, and enter 10.1.4.11 in the adjacent text field.
11. After successfully importing the zone data, click corp100.com in the Infoblox Views panel.
You can see all the imported forward-mapping zone data in the Records panel. Because you have not yet
imported the reverse-mapping zone data, most of the records appear as A records.
12. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> Reverse Mapping
Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
13. In the Authoritative Zone Properties section of the Add Reverse Authoritative Zone editor, enter the following:
Subnet Mask: 255.255.0.0
Comment: Internal DNS zone
17. In the Infoblox Views panel of the DNS perspective, click + (for Reverse Mapping Zones) -> 1.1.1.in-addr.arpa ->
Edit -> Authoritative Zone Properties.
18. In the Authoritative Reverse Zone editor, click Settings and enter the following:
Import zone from: Select this check box, and enter 10.1.4.11 in the adjacent text field.
20. Click 1.1.1.in-addr.arpa -> View -> Records.
You can see all the imported reverse-mapping zone data in the Records panel.
21. Click corp100.com in the Infoblox Views panel.
Because you have now imported both the forward- and reverse-mapping zone data, most of the records appear
as host records.
22. Finally, you must remove the ns1 host record for the legacy server (value 10.1.4.11). To remove it, select ns3, and
then click Edit -> Remove.
Define Networks, Reverse-Mapping Zones, DHCP Ranges, and Infoblox Hosts
In this task, you enter data manually because the configuration is fairly simple. For large data sets, you have the
option of using the Data Import Wizard for loading DNS and DHCP configurations and data to make the process more
efficient. To download the Data Import Wizard, visit www.infoblox.com/support, log in with your support account, and
then click the Data Import Wizard hyperlink in the DNSone section.
Networks
You can create all the subnetworks individually (which in this example are 10.1.1.0/24, 10.1.2.0/24, 10.1.4.0/24,
and 10.1.5.0/24), or you can create a parent network (10.1.0.0/16) that encompasses all the subnetworks and then
use the Infoblox split network feature to create the individual subnetworks automatically. The split network feature
accomplishes this by using the IP addresses that exist in the forward-mapping zones to determine which subnets it
needs to create. This example uses the split network feature. For information about creating networks, see
Configuring a DHCP Network on page 461.
1. From the DHCP and IPAM perspective, click Networks -> Edit -> Add Network -> Network.
2. In the Network Properties section of the Add Configure Network editor, enter the following:
Netmask: /16 (255.255.0.0)
3. Click Member Assignment -> Add to open the Select Grid Members dialog box.
6. Click + (for Networks) -> 10.1.0.0/16 -> Edit -> Split Network.
Subnetworks: Move the slider to 24.
Immediately add only networks with ranges and fixed addresses: Select this check box.
The appliance immediately creates the following 24-bit subnets for the imported Infoblox hosts:
10.1.1.0/24
10.1.2.0/24
10.1.4.0/24
10.1.5.0/24
7. Click -> + (for Networks) -> + (for 10.1.0.0/16) -> 10.1.1.0/24 -> Edit -> Network Properties.
8. In the Configure Network editor, enter information in the following sections:
Network Properties
Comment: MGT
Member Assignment
Members: ns3.corp100.com
10. To modify the other networks, repeat steps #8 10 for each network and use the following information:
10.1.2.0/24 Network:
Comment: Dev
10.1.4.0/24 Network:
Comment: Server
10.1.5.0/24 Network:
Comment: DMZ
Reverse-Mapping Zones
When you create a network, the appliance automatically creates a corresponding reverse-mapping zone and
reparents the relevant resource records from the parent zone (10.1.0.0/16) to that zone. To enable DNS service for
the new zone, you need to assign ns3.corp100.com as the primary DNS server for each zone. In this example, the
appliance creates four reverse-mapping zones. You must modify each zone by assigning ns3.corp100.com as its
primary DNS server.
1. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> + (for Reverse Mapping
Zones) -> + (for 1.10.in-addr.arpa) -> 1.1.10.in-addr.arpa -> Edit -> Authoritative Zone Properties.
5. Repeat steps #14 for the 2.1.10.in-addr.arpa, 4.1.10.in-addr.arpa, and 5.1.10.in-addr.arpa reverse-mapping
zones.
DHCP Ranges
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> + (for 10.1.0.0/16) -> 10.1.1.0/24 ->
Edit -> Add DHCP Range.
2. In the DHCP Range section, enter the following:
Start Address: 10.1.1.10
End Address: 10.1.1.50
3. In the Member Assignment section, select ns3.corp100.com from the Grid Member drop-down list.
5. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> + (for 10.1.0.0/16) -> 10.1.2.0/24 ->
Edit -> Add DHCP Range.
6. In the DHCP Range section, enter the following:
Start Address: 10.1.2.10
End Address: 10.1.2.100
7. In the Member Assignment section, select ns3.corp100.com from the Grid Member drop-down list.
Infoblox Hosts
Defining both a MAC and IP address for an Infoblox host definition creates a DHCP host entrylike a fixed address
that you can manage through the host object. To add a MAC address to each host record that the appliance created
when you imported forward- and reverse-mapping zone records, you must first delete the IP address for that host,
and then add the same IP address with the MAC address.
1. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> + (for Forward Mapping
Zones) -> + (for corp100.com).
2. Double-click 10.1.1.2 to open the Host editor.
3. In the Host Record Properties section, select 10.1.1.2, and then click Remove.
4. Click Add next to the IP Address field to open the Host Address dialog box.
5. Enter the following, and then click OK to close the dialog box:
MAC Address: 00:00:00:aa:aa:aa
7. Follow steps 1 6 to modify hosts with the following information:
printer2
MAC Address: 00:00:00:bb:bb:bb
storage1
MAC Address: 00:00:00:dd:dd:dd
storage2
MAC Address: 00:00:00:ee:ee:ee
proxymail
MAC Address: 00:00:00:ff:ff:ff
proxyweb
MAC Address: 00:00:00:11:11:11
www
MAC Address: 00:00:00:55:55:55
mail
MAC Address: 00:00:00:66:66:66
ftp
MAC Address: 00:00:00:77:77:77
Define Multiple Forwarders
Because ns3.corp100.com is an internal DNS server, you configure it to forward DNS queries for external DNS name
resolution to the primary and secondary DNS serversns1.corp100.com at 10.1.5.2 and ns2.corp100.com at
2.2.2.2.
1. From the DNS perspective, click DNS Members -> Infoblox -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Forwarders, and then enter the following:
IP Address: Type 2.2.2.2, and then click Add.
IP Address: Type 10.1.5.2, and then click Add.
Use Forwarders Only: Clear the check box.
The NIOS appliance initially sends outbound queries to forwarders in the order that they appear in the Forwarders
list, starting from the top of the list. If the first forwarder does not reply, the appliance tries the second one. The
appliance keeps track of the response time of both forwarders and uses the quicker one for future queries. If the
quicker forwarder does not respond, the appliance then uses the other one.
Enable Recursion on External DNS Servers
Because the HA pair forwards outbound queries to the two external DNS servers ns1.corp100.com (10.1.5.2) and
ns2.corp100.com (2.2.2.2) for resolution, you must enable recursion on those servers. When a DNS server employs
recursion, it queries other DNS servers for a domain name until it either receives the requested data or an error that
the requested data cannot be found. It then reports the result back to the server that queriedin this case, the
internal DNS server ns3.corp100.com (10.1.4.10), which in turn reports back to the DNS client.
Infoblox Server in the DMZ Network (ns1.corp100.com, 10.1.5.2)
1. Log in to ns1.corp100.com at 10.1.5.2.
2. From the DNS perspective, click DNS Members -> Infoblox -> Edit -> Grid DNS Properties.
3. In the Grid DNS Properties editor, click Queries, and then select the Allow Recursion check box.
BIND Server at ISP Site (ns2.corp100.com, 2.2.2.2)
1. Open the named.conf file using a text editor and change the recursion and allow-recursion statements to allow
recursive queries from 1.1.1.8 (the NAT address of ns3).
opt i ons {
zone- st at i st i cs yes;
di r ect or y "/ var / named/ named_conf " ;
ver si on " ";
recursion yes;
l i st en- on { 127. 0. 0. 1; 2. 2. 2. 2; };
allow-recursion {1.1.1.8;};
t r ansf er - f or mat many- answer s;
};
Windows 2000/2003 Server at ISP Site (ns2.corp100.com, 2.2.2.2)
2. Right-click ns3, and then select Properties -> Advanced.
3. On the Advanced page in the ns3 Properties dialog box, clear the Disable recursion check box.
4. To save the configuration change and close the ns3 Properties dialog box, click OK.
Modify the Firewall and Router Configurations
Configure the firewall and router in your internal network to allow the following DHCP, DNS, and NTP traffic:
To allow messages to pass from the DHCP clients in the DMZthe web, mail, and FTP serversto ns3 in the
Server network, configure policies and DHCP relay agent settings on the firewall.
To forward DHCP messages from DHCP clients in the MGT and Dev networks to ns3 in the Server network,
configure relay agent settings on the router.
To translate the private IP address of ns3 (10.1.4.10) to the public IP address (1.1.1.8) when forwarding DNS
queries from ns3 to ns2, set a MIP (mapped IP) address on the firewall.
To allow DNS queries from ns3 to ns1 and ns2 and NTP traffic from ns3 to the NTP server, configure firewall
policies.
Firewall
For example, enter the following commands on a Juniper firewall running ScreenOS 4.x or later:
DHCP Relay Configuration
set addr ess t r ust ns3 10. 1. 4. 10/ 32
set i nt er f ace et her net 2 dhcp r el ay ser ver - name 10. 1. 4. 10
set pol i cy f r omdmz t o t r ust ns1 ns3 DHCP- Rel ay per mi t
DNS Forwarding
set i nt er f ace et her net 1 mip 1.1.1.8 host 10.1.4.10
set pol i cy f r omt r ust t o unt r ust ns3 ns2 dns per mi t
set pol i cy f r omt r ust t o dmz ns3 ns1 dns per mi t
NTP
set pol i cy f r omdmz t o unt r ust ns1 nt p_ser ver nt p per mi t
Router
For example, enter the following commands on a Cisco router running IOS for release 12.x or later:
DHCP Relay Configuration
i nt er f ace et her net 1
i p hel per - addr ess 10. 1. 4. 10
i nt er f ace et her net 2
i p hel per - addr ess 10. 1. 4. 10
Enable DHCP and Switch Service to the NIOS Appliance
With the Infoblox in place and the firewall and router configured for relaying DHCP messages, you can switch DHCP
service from the legacy DHCP server at 10.1.4.11 to the HA pair at 10.1.4.10 (VIP address).
Tip: To minimize the chance of duplicate IP address assignments during the transition from the legacy DHCP server
to the appliance, shorten all lease times to a one-hour length in advance of the DHCP server switch. Then, when
you take the legacy DHCP server offline, the DHCP clients quickly move to the new server when their lease
renewal efforts fail and they broadcast DHCPDISCOVER messages. To determine how far in advance you need to
shorten the lease length, find the longest lease time (for example, it might be two days). Then change the lease
length to one hour at a slightly greater interval of time before you plan to switch DNS service to the appliance
(for example, three days before the switch over). By changing the lease length this far in advance, you can be
sure that all DHCP leases will be one-hour leases at the time of the switch-over. If the longest lease length is
longersuch as five daysand you want to avoid the increased amount of traffic caused by more frequent lease
renewals over a six-day period, you can also employ a stepped approach: Six days before the switch-over,
change the lease lengths to one-day leases. Then two days before the switch-over, change them to one-hour
leases.
1. Open a browser window, and log in to the HA pair at https://10.1.4.10, using the user name admin and the
password SnD34n534.
2. From the DHCP and IPAM Perspective, select DHCP Members -> + (for Infoblox) -> ns3.corp100.com -> Edit ->
Member DHCP Properties.
3. In the Member DHCP Properties editor, click General Properties and select Enable DHCP Server.
The HA pair is ready to provide DHCP service to the network.
5. Take the legacy DHCP server at 10.1.4.11 offline.
When the DHCP clients are unable to renew their leases from the legacy DHCP server, they broadcast
DHCPDISCOVER messages to which the new DHCP server responds.
Manage and Monitor
Infoblox provides tools for managing IP address usage and several types of logs to view events of interest and DHCP
and DNS data. After configuring the appliance, you can use the following resources to manage and monitor IP address
usage, DNS and DHCP data, and administrator and appliance activity.
IPAM (IP Address Management)
IPAM offers the following services:
Simple IP address modification Within a single IP address-centric data set, you can modify the Infoblox host,
DHCP, and DNS settings associated with that IP address.
Address type conversion Through IPAM functionality, you can make the following conversions:
Currently active dynamic addresses -> fixed addresses, reserved addresses, or Infoblox hosts
Fixed addresses -> reserved addresses or hosts
Reserved addresses -> hosts
Device classification You can make detailed descriptions of appliances in DHCP ranges and appliances
defined as Infoblox hosts and as fixed addresses.
Three distinct views of IP address usage To monitor the usage of IP addresses on your network, you can see
the following different views:
High-level overall network view: From the DHCP and IPAM perspective, click DHCP Members -> + (for
Infoblox) -> 10.1.4.10 -> View -> DHCP Statistics.
Run-time view that allows you to zoom in and out to varying levels of detail: From the DHCP and IPAM
perspective, click Networks -> network -> View -> IP Address Management -> ip_addr -> View -> Properties.
DHCP lease history records: From the DHCP and IPAM perspective, click View -> DHCP Lease History.
Logs
The following are some useful logs:
Logs
Audit Log Contains administrator-initiated events
System Log Contains events related to hardware and software operations
DNS
DNS Cache Contains cached DNS-to-IP address mappings
DNS Configuration Contains DNS server settings for the Infoblox DNS server
Zone Statistics Contains a record of the results of all DNS queries per zone
DHCP
DHCP Configuration Contains DHCP server settings and network, DHCP range, and host settings for the
Infoblox DHCP server
DHCP Leases Contains a real-time record of DHCP leases
DHCP Lease History Contains an historical record of DHCP leases
DHCP Statistics Contains the number of currently assigned static and dynamic addresses, and the high
and low watermarks per network
Network Statistics Contains the number of static hosts, dynamic hosts, and available hosts per network
Verifying the Deployment
Verifying the Deployment
After you deploy a single independent appliance or HA pair, you can make an HTTPS connection to it, log in, and check
its status.
Single Independent Appliance
From the Device perspective, check the Status column in the Device panel.
If the Status icon is green, the appliance has a network connection and is operating properly.
If the Status icon is red, there is a problem. To determine what it is, look at the system log file for this
appliance by clicking device_name -> File -> System Log -> Node 1.
Independent HA Pair
1. Make an HTTPS connection to the VIP address of the HA pair, log in, and check the status of both nodes.
2. From the Device perspective, check the Status column in the Device panel.
If the Status icon is green, both nodes have connectivity with each other and are operating properly.
If the Status icon is yellow, the two nodes are in the process of forming an HA pair.
If the Status icon is red, the passive node is offline or there is a problem. To determine what it is, look at the
system log file for each node by clicking host_name -> File -> System Log -> Node 1 or Node 2. You can also
gather information from the Detailed Status viewer. Click host_name -> View -> Detailed Status.
You can also check the status of each node in the Information section in the Device Properties viewer:
1. From the Device perspective, click View -> Properties -> + (for Information) -> + (for Node #1) and + (for Node #2).
2. Check the value in the Status row for each node. The three status values are:
Active: The node is functioning properly as the active node in the HA pair.
Passive: The node is functioning properly as the passive node in the HA pair.
Offline: The active node cannot make a network connection to this node.
Forcing an HA Failover
If you want to change which node in an HA pair is active and which is passive, you can force a failover to occur. You
might want to do this if you need to move or perform maintenance on a currently active node. Within five seconds
after initiating a failover, the previously passive node becomes active and assumes ownership of the VIP address.
To force an HA failover:
1. Log in as a superuser.
2. From Device perspective, click ha_pair -> Edit -> Force Failover.
3. A message appears, prompting you to confirm the failover operation and noting that a forced failover causes a
temporary service disruption.
4. To proceed with the forced failover, click OK.
5. Close the management window, and then log back in.
6. To confirm that the two nodes have reversed their rolesthat is, the previously passive node is now active, and
the previously active node is now passivefrom the Device perspective, click hostname -> View -> Detailed
Status.
Infoblox Tools for Migrating Data
Typically, the next step after cabling a single independent appliance to a network and configuring its network
settingsor cabling two independent appliances to a network and configuring them as an HA pairis to import data
from legacy DNS, DHCP, and TFTP servers. Infoblox provides several tools to accomplish this:
The Infoblox Data Import Wizard is a useful tool that simplifies the importation of DNS, DHCP and IPAM (IP
address management), and TFTP settings and data into a NIOS appliance. For large data sets, this option is an
efficient approach. To download the Data Import Wizard, visit www.infoblox.com/support, log in with your
support account, and then click the Data Import Wizard hyperlink in the DNSone section. For guidance in
selecting and using the different options in the wizard, refer to the online Help that accompanies it.
You can use prewritten Infoblox Perl API scripts or write your own scripts to ease the execution of large and
repetitive operations such as importing data for large numbers of networks and zones. To download script
packs, log in to www.infoblox.com/support, and navigate to the Downloads section. Each script has a
corresponding HTML Help file. For a more general introduction to using the Infoblox API, see the Infoblox API
Reference Guide, which is available in the Technical Library section of the Infoblox Support site.
For smaller DNS data sets, you can use the zone import feature, which allows you to import data on a per-zone
basis (seeImporting Zone Data on page 359).
You can also manually enter the settings and data for network identity services. For information, see the
relevant service-specific chapters in this guide.
Upgrading Software on an Independent Appliance or HA Pair
Upgrading Software on an Independent Appliance or HA Pair
Upgrading an independent appliance or HA pair involves three steps:
Downloading the software upgrade files to a local system (Acquiring Software Upgrade Files on this page)
Distributing the software upgrade files (Distributing Software Upgrade Files on this page)
Running the software upgradewhich involves rebooting the appliances and then running the new software
(Running the Software Upgrade on page 265)
Note: You cannot upgrade directly to NIOS 4.2 from certain DNS releases, such as DNS 3.1 and 3.2, and NIOS
releases, such as 4.0r1. Refer to the release notes for the appropriate upgrade and revert paths.
Acquiring Software Upgrade Files
Infoblox frequently releases updated NIOS software. Contact Infoblox Technical Support to learn about new software
upgrades, or watch your e-mail for periodic notifications that a new software upgrade is available. After you have the
new upgrade file stored on your local network, proceed to the next section.
Distributing Software Upgrade Files
Software distribution varies depending on how appliances are deployed:
The active node of an independent HA pair distributes the software to the passive node and to itself.
A single independent appliance distributes the software to itself.
To distribute the latest software:
1. From the Device perspective, click Device -> Distribute -> Upload NIOS Software.
When you perform a distribution, the NIOS appliance uploads the file to a backup partition and unpacks the
contents, which overwrites any existing backup software that might have been there.
2. Navigate to the .bin file that you want to upload, select it, and then click Open or OK.
3. To view the file distribution status, look at the Upgrade Status panel.
From the Device perspective, click View -> Upgrade Status.
The process takes a few minutes and is complete when the Upgrade Status panel displays file distribution as
complete and all files unpacked. The new software is now staged and is ready for use.
Running the Software Upgrade
After you successfully distribute (stage) the software upgrade, you can then run it. Essentially, each appliance is going
to switch between the two software partitions on its system, activating the staged software and saving the previously
active software and database as backup.
Note: Before you upgrade the software, Infoblox recommends backing up the current configuration and database.
To run the software upgrade:
1. From the Device perspective, click Device -> Upgrade.
The upgrade process begins immediately.
Due to the nature of the upgrade sequence, HA pairs fail over during the upgrade. Therefore, be aware that the
active and passive nodes reverse roles. The GUI session terminates when the independent HA pair fails over
from Node 1 to Node 2, or when the single independent appliance reboots and goes offline.
2. Log back in and check the status of each upgraded appliance in the Detailed Status panels. From the Device
perspective, click hostname -> View -> Detailed Status.)

Chapter 9 Deploying a Grid
To deploy a grid, it is important to understand what a grid is, how to create a grid master and add members, and how
to manage the grid. This chapter explains these tasks in the following sections:
Introduction to Grids on page 269
NAT Groups on page 271
Automatic Software Version Coordination on page 274
Grid Bandwidth Considerations on page 276
Creating a Grid Master on page 278
VRRP Advertisements on page 280
Port Numbers for Grid Communication on page 281
Creating an HA Grid Master on page 282
Creating a Single Grid Master on page 284
Adding Grid Members on page 288
Adding a Single Member on page 288
Adding an HA Member on page 289
Configuration Example: Configuring a Grid on page 291
Enabling IPv6 On a Grid Member on page 304
Managing a Grid on page 308
Changing Grid Properties on page 308
Setting the MTU for VPN Tunnels on page 308
Removing a Grid Member on page 309
Promoting a Master Candidate on page 309
Replacing a Failed Grid Master on page 309
Using the Recycle Bin on page 310
Disabling the Recycle Bin on page 310
Enabling the Recycle Bin on page 311
Viewing the Recycle Bin on page 311
Emptying the Recycle Bin on page 312
Deploying a Grid
Upgrading NIOS Software on a Grid on page 313
Lite Upgrades on page 313
Uploading NIOS Software on page 314
About Upgrade Groups on page 314
Distributing Software Upgrade Files on page 315
Testing a Software Upgrade on page 319
Performing a Software Upgrade on page 320
Monitoring Distribution and Upgrade Status on page 324
Introduction to Grids
A grid is a group of two or more NIOS appliances that share sections of a common, distributed, built-in database and
which you configure and monitor through a single, secure point of access: the grid master. A grid can include Infoblox
appliances and NIOS virtual appliances. A NIOS virtual appliance is a Riverbed Steelhead appliance running the
Riverbed Services Platform on which the NIOS software is installed. You can configure Infoblox appliances as a grid
master, grid master candidate, or grid members, but you can configure NIOS virtual appliances only as grid members.
Figure 9.1 shows the basic concept of a grid and database distribution (or replication).
Figure 9.1 Grid and Partitioned Database Replication
The grid master can be either an HA master or a single master; that is, an HA (high availability) pair or a single
appliance. Similarly, a grid member can be either a single member or an HA member. The grid master communicates
with every grid member in a hub-and-spoke configuration. For an HA member, the grid master communicates with the
active node, which in turn communicates with the passive node, as shown in Figure 9.2.
Figure 9.2 Grid Communications to an HA Member
The administrator makes a secure
connection to the grid master to
configure and manage all grid
members.
and it replicates the
entire database to the
master candidate.
The grid master replicates the
section of the database that
applies to each member
Administrator
VPN Tunnel
Grid Master Master Candidate
Grid
NIOS
Virtual
Appliance
HA Member
HA Member
Database
Note: In addition to the VPN tunnel securing administrative traffic to the grid
master, all grid communications between the grid master and grid members
pass through encrypted VPN tunnels (not shown).
1
2
VPN Tunnel
Grid Master HA Member
Node 1
Active
Node 2
Passive
VPN Tunnel
The grid master communicates with
the active node of the HA member.
The active node communicates
with the passive node.
VIP
(on HA Port) VIP
(on HA Port)
LAN Port
LAN Port
Deploying a Grid
Although you can configure a NIOS virtual appliance as a grid member, you cannot configure it as an HA member.
When adding NIOS virtual appliances to a grid, you centralize the management of core network services of the virtual
appliances through the grid master. The NIOS virtual appliance supports most of the features of the Infoblox NIOS
software. However, due to limited system resources on the RSP (Riverbed Services Platforms), the NIOS virtual
appliance has the following limitations:
On a grid with a NIOS virtual appliance, the maximum storage space for HTTP, FTP and TFTP is limited to 1GB (a
grid with only Infoblox appliances provides a maximum of 2 GB for these services).
On a NIOS virtual appliance, the maximum size of core files is limited to 100 MB, and syslog and inflobox.log
files are limited to 20MB each.
The LAN interface is the only network interface available on NIOS virtual appliances. You cannot configure the
speed and transmission type (full or half duplex) of the network interface.
You can control the IP traffic capture only on the LAN port.
The NIOS virtual appliances do not support the following features:
Anycast addressing
Configuration as a DHCP lease history logging member
Configuration as a RADIUS accounting server
Dedicated MGMT port
On a NIOS virtual appliance, the shutdown command restarts the NIOS appliance instead of halting it. Infoblox
recommends that you use the Riverbed no rsp enable command to perform a shutdown.
For more information about the NIOS virtual appliances and how to install the NIOS software on a RSP, refer to the
Quick Start Guide for Installing NIOS Software on Riverbed Services Platforms.
By default, grid communications use the UDP transport with a source and destination port of 1194. This port number
is configurable, but for a port change to take effect, the HA master must fail over or the single master must reboot.
After adding an appliance or HA pair to a grid, you no longer access the Infoblox GUI on that appliance. Instead, you
access the GUI running on the grid master. Although you can create multiple administrator accounts to manage
different services on various grid members, all administrative access is through the grid master. So even if someone
has administrative privileges to a single grid member, that administrator must access the GUI running on the grid
master to manage that member.
You can access the Infoblox GUI through an HTTPS connection to one of the following IP addresses and ports on the
grid master:
The VIP address, which links to the HA port on the active node of an HA grid master
The IP address of the LAN port on a single grid master
The IP address of the MGMT port (if enabled) of the active node of an HA or single grid master. See Using the
MGMT Port on page 136.
Grid Communications
The grid master synchronizes data among all grid members using bloxSync through encrypted VPN tunnels. The
default source and destination UDP port number for VPN tunnels is 1194. You can continue using the default port
number or change it. For example, if you have multiple grids, you might want each grid to use a different port so that
you can set different firewall rules for each. Whatever port number you choose to use for the VPN tunnels in a grid, all
the tunnels in that grid use that single port number.
Before an appliance or HA pair forms a tunnel with the master, they first authenticate each other using the
Challenge-Response Authentication Mechanism (CRAM). The source and destination port number for this traffic is
2114. During the CRAM handshake, the master tells the appliance or HA pair what port number to use when building
the subsequent VPN tunnel.
Figure 9.3 VPN Tunnels within a Grid
Another type of traffic, which flows outside the tunnels, is the VRRP (Virtual Router Redundancy Protocol)
advertisements that pass between the active and passive nodes in an HA pair. The VRRP advertisements act like
heartbeats that convey the status of each node in an HA pair. If the active node fails, the passive node can become
active. The VIP (virtual IP) address for that pair then shifts from the previously active node to the currently active node.
NAT Groups
NAT groups are necessary if the grid master is behind a NAT appliance and there are members on both sides of that
NAT appliance. Any members on the same side as the master go into the same NAT group as the master and use their
interface addresses for grid communications with each other. Grid members on the other side of that NAT appliance
do not go in the same NAT group as the master and use the master's NAT address for grid communications. These
other members outside the NAT appliance canbut do not always need to bein a different NAT group. To see when
NAT groups become necessary for grid communications, compare Figure 9.4 below with Figure 9.5 and Figure 9.6 on
page 273.
LAN 10.1.1.14
(on Passive Node
of Grid Master)
LAN 10.1.1.20
(on Passive Node
of HA Member)
LAN 10.1.1.18
(on Active Node of
HA Member)
VIP 10.1.1.11
(on Active Node)
Encrypted
VPN Tunnels
Node 1 (Active)
Node 2 (Passive)
Node 1 (Active)
Node 2 (Passive)
HA Grid Master
Single Member
HA Member
HA 10.1.1.15
HA 10.1.1.13
LAN 10.1.1.16
Grid
VIP 10.1.1.22
(on Active Node)
HA 10.1.1.21
HA 10.1.1.19
Note: The default source and destination UDP
ports for all VPN tunnels in a grid is 1194.
If the grid master is a single appliance, it
communicates with the grid members
from its LAN port.
If you enable grid communications on
the MGMT port of an HA member, the
active node communicates from its
MGMT port to the grid master and the
passive node communicates from its
MGMT port to the VIP on the HA port
on the active node.
Deploying a Grid
Figure 9.4 NAT without NAT Groups
Note: A single or HA member using its MGMT port for grid communications cannot be separated from the grid master
behind a NAT appliance. For more information, see Using the MGMT Port on page 136.
Figure 9.5 Grid Master in NAT Group
Member 2
Interface 1.2.2.20
NAT
Member 3
(Master Candidate)
Interface 192.168.1.30
NAT 1.3.3.30
Member 4
Interface 10.1.0.40
NAT 1.4.4.40
Member 5
Interface 10.1.0.50
NAT 1.4.4.50
Member 1
(Grid Master)
Interface 10.1.1.10
NAT 1.1.1.10
In this case, there is no need for NAT groups. The
master (Member 1) always uses its NAT address
(1.1.1.10) when communicating with the grid members.
Also, if you ever promote Member 3 to master, it only
has to use its NAT address (1.3.3.30) to communicate
with the other grid members. Whichever appliance is
master, there is no other member behind the same NAT
appliance with which it needs to use its interface
The grid members use the addresses in bold for
grid communications through their LAN ports.
Grid
Network
Member 2
Interface 1.2.2.20
NAT
Member 3
(Master Candidate)
NAT 1.3.3.30
Member 4
Interface 10.1.0.40
NAT 1.4.4.40
Member 5
Interface 10.1.0.50
NAT 1.4.4.50
Member 1
(Grid Master)
Interface 10.1.1.10
NAT 1.1.1.10
The master (Member 1) uses its interface address
(10.1.1.10) for grid communications with Member 6 and
its NAT address (1.1.1.10) when communicating with
the other grid members. Member 6 uses its interface
address (10.1.1.60) when communicating with the
master. If Member 3 (a master candidate) ever became
the grid master, then both Members 1 and 6 would use
their NAT addresses when communicating with it.
Members 2 5 use the addresses in black bold for grid communications.
Members 1 and 6 use their interface addresses in underlined blue bold.
Grid
Member 6
Interface 10.1.1.60
NAT 1.1.1.60
NAT Group 1
Network
The same use of NAT groups that applies to a grid master also applies to master candidates. If there are no other
members behind the same NAT appliance as a master candidate, then the master candidate does not need to be in
a NAT group. It always uses its NAT address for grid communications. If another member is behind the same NAT
appliance as the master candidate, then both the candidate and that member need to be in the same NAT group so
thatif the candidate becomes masterthey can use their interface addresses to communicate with each other (see
Figure 9.6 ).
Figure 9.6 Grid Master and Master Candidate in NAT Groups
Although some members might not need to be in a NAT group, it is good practice to put all members in NAT groups in
anticipation of adding or rearranging grid members within the network. For example, in Figure 9.4 Figure 9.6,
Member 4 did not need to be in a NAT group until it became configured as a master candidate in Figure 9.6 . At that
point, because Member 5 is also behind the same NAT appliance, it became necessary to create NAT Group 2 and add
Members 4 and 5 to it. Similarly, if you add another member behind the NAT appliance in front of Member 3, then you
must create a new NAT group and add Member 3 and the new member to it. Always using NAT groups can simplify
such changes to the grid and ensure that NAT appliances never interrupt grid communications.
To create a NAT group:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties -> NAT Groups.
2. In the NAT Groups section of the Grid editor, click Add.
3. In the NAT Group dialog box, enter a name in the Group Name field and a useful comment in the Comment field,
and then click OK.
To add members to the NAT group:
1. In the Grid perspective, click + (for id_grid) -> + (for Members) -> member -> Edit -> Member Properties -> NAT.
2. In the NAT section of the Grid Member editor, enter the following:
Enable NAT compatibility: (select)
Group: From the drop-down list, select the NAT group you previously created.
Member 2
Interface 1.2.2.20
NAT
Member 3
(Master Candidate)
NAT 1.3.3.30
Member 4
Interface 10.1.0.40
NAT 1.4.4.40
Member 5
Interface 10.1.0.50
NAT 1.4.4.50
Member 1
(Grid Master)
Interface 10.1.1.10
NAT 1.1.1.10
Members 3 and 4 are master candidates. Because
Member 3 is alone behind a NAT appliance, it does not
need to be in a NAT group. It always uses its NAT
address for grid communications. However, Member 4 is
behind the same NAT appliance as Member 5, so they
are put in the same NAT group. If Member 4 ever
became the grid master, it would use its interface
address to communicate with Member 5 and its NAT
address to communicate with all other members.
Members 1 5 use the addresses in black bold for grid communications.
Members 1 and 6 use their interface addresses in underlined blue bold.
If Member 4 became master, it would use its interface address in double
underlined green bold to communicate with Member 5, and its NAT
address to communicate with all other members.
Grid
Member 6
Interface 10.1.1.60
NAT 1.1.1.60
NAT Group 1
NAT Group 2
Network
Deploying a Grid
NAT (V)IP Address: For a single grid master or member, enter the address configured on the NAT appliance
that maps to the interface address of the LAN port. A single master or member that serves DNS uses this
NAT address for grid communications andif it serves DNSfor its NS records.
For an HA grid master or member, enter the address configured on the NAT appliance that maps to its VIP
address. An HA master uses its VIP NAT address when communicating with grid members. An HA member
that serves DNS uses its VIP NAT address for its NS records. It uses its LAN port NAT address for grid
communications.
Node 1 (if HA)
NAT IP Address: Enter the address configured on the NAT appliance that maps to the interface
address of the LAN port on Node 1. When Node 1 of an HA member is active, it uses its NAT
address for grid communications.
Node 2 (if HA)
NAT IP Address: Enter the address configured on the NAT appliance that maps to the interface
address of the LAN port on Node 2. When Node 2 of an HA member is active, it uses its NAT
address for grid communications.
Automatic Software Version Coordination
When you add an appliance or HA pair to a grid as a new member, it is important that it is running the same version
of software as the other members in the grid. Infoblox provides two methods for coordinating the software version:
Manual Upgrade and Downgrade: Before adding an appliance or HA pair to a grid, you can manually upgrade or
downgrade the software on the appliance or HA pair to the version used by the rest of the grid.
Automatic Upgrade and Downgrade: The grid master automatically compares the software version of each
appliance attempting to enter a grid with that in use by the rest of grid. If the versions do not match, the grid
master downloads the correct version to the new appliance or HA pair.
Note: The grid master checks the software version every time an appliance or HA pair joins the grid. The software
version check occurs during the initial join operation and when a member goes offline and then rejoins
the grid.
Figure 9.7 Automatic Upgrade of an appliance Joining a Grid
When a single appliance attempts to join the grid for the first time, the following series of events takes place:
1. The appliance establishes an encrypted VPN tunnel with the grid master.
2. The master detects that the software version on the appliance is different from that in the rest of the grid. For
example, the appliance is running DNSone 3.2r10 software but the rest of the grid is running NIOS 4.0r1
software.
3. The grid master sends the NIOS 4.0r1 software through the tunnel to the appliance, which loads it.
4. After the upgrade is complete, the NIOS application automatically restarts.
5. After the appliance reboots, it again contacts the grid master and step 1 is repeated. Because the software
versions now match, the appliance can complete its attempt to join the grid.
When an HA pair attempts to join the grid for the first time, the following series of events takes place:
1. The active node of the HA pair establishes an encrypted VPN tunnel with the grid master.
2. The master detects that the software version on the node is different from that in the rest of the grid. For example,
the active node is running DNSone 3.2r10 software but the rest of the grid is running NIOS 4.0r1 software.
3. The grid master sends the NIOS 4.0r1 software through the tunnel to the active node, which loads it.
4. After the upgrade is complete, the NIOS application on the active node automatically restarts. This causes an HA
failover.
5. The new active node (which was previously the passive node) attempts to join the grid, repeating steps 1 4.
6. When the NIOS application on the currently active node restarts, there is another failover, and the currently
passive node becomes active again.
7. The active node again contacts the grid master and step 1 is repeated. Because the software versions now match,
it can complete its attempt to join the grid.
When an appliance with a different
version of NIOS attempts to join the
grid, the grid master sends the
software that the rest of the grid is
using to the appliance through a
tunnel.
The appliance loads the NIOS software that it
receives from the grid master, reboots, and
reestablishes a tunnel with the grid master.
Thenassuming everything else is in
orderthe appliance successfully joins the
grid.
NIOS 4.0r1
Software
Download
Appliance J oining the Grid
(DNSone 3.2r10 ->NIOS 4.0r1)
The grid master synchronizes
configuration and data changes with
grid members through VPN tunnels
HA Grid Member Single Grid Member
Grid Master
Grid
(NIOS 4.0r1)
Deploying a Grid
Grid Bandwidth Considerations
Infoblox grid technology relies upon database replication for its core functionality. When designing a grid, it is
important to consider the amount of traffic generated by this replication and the overall number of grid members.
Other communication between grid members (such as log retrieval and monitoring functions) occurs as well. All of
this traffic is securely communicated between the grid master and grid members through encrypted VPN tunnels.
One component of the traffic through the tunnels is database replication traffic. There are three types to consider:
1. Complete database replication to a master candidate Occurs when a master candidate joins or rejoins a grid.
The grid master sends the complete database to a master candidate so that it has all the data it needs if it ever
becomes promoted from member to master.
2. Partial database replication Occurs when an appliance or HA pair joins or rejoins the grid as a regular member
(which is not configured as a master candidate). The grid master sends it the section of the database that mainly
applies just to the member.
3. Ongoing database updates Occurs as changes are made to the grid configuration and data. The grid master
sends all ongoing database updates to master candidates and individual member-specific updates to regular
members.
If there are no or very few DNS dynamic updates, and no or very few DHCP lease offers and renewals issued,
then this type of replication traffic is minimal.
If there are many DDNS (dynamic DNS) updates (many per second) and/or many DHCP lease offers and
renewals (many per second), then the replication traffic is the largest component of the VPN traffic among grid
members.
Note: A grid master replicates data to single members and to the active node of HA members. The active node then
replicates the data to the passive node in the HA pair.
At a minimum, there must be 256 Kbps (kilobits per second) bandwidth between the grid master and each member,
with a maximum round-trip delay of 500 milliseconds. For ongoing database updates, the amount of data sent or
received is 15 Kb for every DDNS update, and 10 Kb for every DHCP lease -offer/renew. The baseline amount for
heartbeat and other maintenance traffic for each member is 2 Kbps. Measure the peak DNS and DHCP traffic you see
in your network to determine the bandwidth needed between the grid master and its members for this activity.
For example, you might decide to place your grid members in the locations shown in Figure 9.6 on page 273.
Figure 9.8 Grid Deployment
In this example, the grid master is optimally placed in the Data Center West. There are a total of seven members: the
HA grid master, three HA members, and three single members. If all the members are master candidates, the grid
master replicates all changes to the other six members. Assuming that the master receives 20 dynamic updates per
minute and 40 DHCP lease renews per minute, the calculation for grid bandwidth is:
Another component is the upgrade process. See Upgrading NIOS Software on a Grid on page 313 for more
information.
Bandwidth requirements, database size, and update rate determine the maximum size of the grid you can deploy.
Based on the various factors discussed above, you can determine the amount of bandwidth your grid needs. If your
calculations exceed the available bandwidth, then you might need to modify your deployment strategy, perhaps by
splitting one large grid into two or more smaller ones.
Note: This calculation does not take into account existing traffic other than DNS and DHCP services, so factor and
adjust accordingly.
For international networks, because of bandwidth and delay requirements, a geographical grouping of grid members
might be the best approach. For example, if you have a global presence, it may make the most sense to have a North
American grid, a South American grid, a European grid, and an Asia/Pacific grid.
20 DDNS updates/minute/60 secs = 0.333 DDNS updates/sec * 15 Kb = 5 Kbps *6 members = 30 Kbps
40 DHCP leases/minute/60 secs = 0.666 DHCP leases/sec * 10 Kb = 6.7 Kbps * 6 members = 40.2 Kbps
2 Kbps of grid maintenance traffic * 6 members = 12 Kbps
Total 82.2 Kbps
Network Diagram
Large Branch
West
Large Branch
Central
Data Center
West
Data Center
East
West Site
West Site East Site
East
Site
East
Site
East
Site
Deploying a Grid
Creating a Grid Master
To create a grid, you first create a grid master and then add members. Although the grid master can be a single
appliance (a single master), a more resilient design is to use an HA pair (an HA master) to provide hardware
redundancy. The basic procedure for forming two appliances into an HA master is shown in Figure 9.9.
Note: You cannot configure a NIOS virtual appliance as a grid master, a grid master candidate, or an HA pair.
Figure 9.9 Initially Configuring a Pair of Appliances as a Grid Master
After the two nodes form an HA pair, Node 2 initiates a key exchange and creates an encrypted VPN tunnel with
Node 1. The two nodes communicate between the VIP interface linked to the HA port on Node 1 and the LAN port on
Node 2. The initialization of VPN communications between the two nodes is shown in Figure 9.10 on page 279.
To Network
Connect your management
system to a switch and set its
IP address to 192.168.1.3.
Connect Node 1 to the switch, log in to its
default IP address (192.168.1.2), check
that a Keystone license is installed, and
configure the following:
VIP address, netmask, gateway
Hostname
HA and LAN addresses of Node 1
HA and LAN addresses of Node 2
VRID (virtual router ID)
NTP settings
Grid name
Shared secret
Connect Node 2 to the switch, log in to its
default IP address (192.168.1.2), check
that a Keystone license is installed, and
configure the following:
VIP address (for Node 1)
LAN address, netmask, gateway
Hostname
Grid name
Shared secret
2 4
Node 2
Management
System
Switch
Node 1
After you configure Node 1, it listens for three
seconds for VRRP advertisements containing
its VRID number. When it does not receive
any, it assumes the active role in the HA pair
and starts sending advertisements.
3
After you configure Node 2, it contacts
the VIP address on Node 1 and initiates
a key exchange using the shared secret.
The nodes then construct an encrypted
VPN tunnel to secure grid
communications.
5
Note: For more information about VRRP advertisements,
see VRRP Advertisements on page 280.
Note: Because you do not set the VRID for
Node 2, it cannot listen for VRRP
advertisements yet. It learns its VRID
after it joins the grid and downloads the
database from Node 1. Then, when
Node 2 receives an advertisement
containing its VRID from Node 1, it
assumes the passive role in the HA pair.
1
Figure 9.10 Establishing a VPN Tunnel for Grid Communications
After the nodes establish a VPN tunnel between themselves, Node 1 sends Node 2 its entire database (its
configuration settings and service data). Because the configuration contains the VRID (virtual router ID) for the HA
pair, Node 2 starts listening for VRRP advertisements containing that VRID number. Because Node 1 is already
sending such advertisements, Node 2 receives one and assumes the passive role in the HA pair.
After the initial transmission of its database, Node 1 continues to send Node 2 real-time database updates using an
Infoblox proprietary mechanism called bloxSYNC through the VPN tunnel.
Node 1 maintains the synchronization of the database throughout the gridwhich, at this point, has no other
memberssends VRRP advertisements indicating its physical and network health, andif configured to do so
provides network services. Node 2 maintains a state of readiness to assume mastership in the event of a failover. You
can see the flow of HA- and grid-related traffic from ports on the active node to ports on the passive node in
Figure 9.11. This illustration also shows the ports that you can use for management traffic and network service.
Figure 9.11 Traffic and Ports that an HA Grid Master Uses
Node 1 Node 2
Source and Destination
Port Numbers:
LAN VIP
2114 (nonconfigurable)
1194 default VPN port
number (configurable)
Key
Exchange
Tunnel Established
The two nodes authenticate each other and
perform a VPN key exchange.
The passive node establishes an encrypted
VPN tunnel with the active node.
Switch
VPN
Tunnel
Node 1 Node 2 Switch
To Network
Management
System
Active Passive
SSHv2 / CLI
VIP
HA
LAN
HA
LAN
HA Master
bloxSYNC inside
VPN Tunnel
VRRP
Advertisements
VIP is a logical
interface linking
to the HA port on
the active node
of the HA pair.
HTTPS / GUI
SSHv2 / CLI
Note: If you enable the
MGMT port, you can only
make an HTTPS connection
to the IP address of the active
node. If you try to connect to
the IP address of the passive
node, the appliance redirects
your browser to the IP
address of the active node.
SSHv2, however, behaves
differently from HTTPS. If
you enable the MGMT port
and define its network
settings for both nodes in the
HA pair, you can make an
SSHv2 connection to the IP
addresses of the LAN and
MGMT ports on both the
active and passive nodes.
Deploying a Grid
From the management system, you can manage the active node of the HA master by making an HTTPS connection to
the VIP interface and using the GUI, and by making an SSHv2 connection to the LAN port (and MGMT port, if enabled)
and using the CLI. If you enable the MGMT port on an HA pair, you can make an HTTPS connection through the MGMT
port on the active node, and you can make an SSHv2 connection through the LAN or MGMT port on the active and
passive nodes.
Note: For information about enabling and using the MGMT port, the Infoblox GUI, and SSH, see Using the MGMT Port
on page 136, Accessing the Infoblox GUI on page 38, and Enabling Remote Console Access on page 128.
VRRP Advertisements
VRRP advertisements are periodic announcements of the availability of the HA node linked to the VIP. The active node
in an HA pair sends advertisements as multicast datagrams every second. It sends them from its HA port using the
source IP address of the HA port (not from the VIP address) and the source MAC address 00:00:5e:00:01:vrrp_id . The
last two hexadecimal numbers in the source MAC address indicate the VRID (virtual router ID) number for this HA pair.
For example, if the VRID number is 143, then the source MAC address is 00:00:5e:00:01:8f (8f in hexadecimal
notation = 143 in decimal notation).
The destination MAC and IP addresses for all VRRP advertisements are 01:00:5e:00:00:12 and 224.0.0.18. Because
a VRRP advertisement is a multicast datagram that can only be sent within the immediate logical broadcast domain,
the nodes in an HA pair must be in the same subnet together.
Only an appliance configured to listen for VRRP advertisements with the same VRID number processes the
datagrams, while all other appliances ignore them. The passive node in an Infoblox HA pair listens for these on its HA
port and the active node listens on its LAN port. If the passive node does not receive three consecutive
advertisements or if it receives an advertisement with the priority set to 0 (which occurs when you manually perform
a forced failover), it changes to the active state and assumes ownership of the VIP address and virtual MAC address.
If both nodes go offline, the one that comes online first becomes the active node. If they both come online
simultaneously, or if they enter a dual-active statethat is, a condition arises in which both appliances assume an
active role and send VRRP advertisements, possibly because of network issuesthen the nodes apply the following
rules to resolve their roles:
The appliance with the numerically higher VRRP priority becomes the active node.
In NIOS, a node receives the priority value 30 when it first becomes active. If that node sends an advertisement
from its HA port but does not receive it on its own LAN port, it lowers its priority value by one to 29. If it does not
receive the next advertisement, it lowers the priority value to 28. This can continue until the priority reaches 10,
at which point the decrementation process stops. (Because the active node in an HA pair can function without
its LAN port, the decrementation process stops before the priority value reaches zero, which would cause an
appliance failover.) If the node starts receiving its own advertisements again, it starts increasing its priority
value by one for each received advertisement, stopping the incrementation process when it returns to 30.
If both nodes have the same priority, then the appliance whose HA port has a numerically higher IP address
becomes the active node. For example, if the IP address of the HA port on Node 1 is 10.1.1.80 and the IP
address of the HA port on Node 2 is 10.1.1.20, then Node 1 becomes the active node.
The basic decision tree that a NIOS appliance configured as a node in an HA node uses to determine if it is the active
or passive node is shown in Figure 9.12 on page 281.
Figure 9.12 Using VRRP Advertisements to Determine the Active Node in an HA Pair
Port Numbers for Grid Communication
If connectivity between grid members must pass through a firewall, the firewall policies must allow the initial key
exchange and subsequent VPN traffic to pass. The key exchange uses UDP with a source and destination port of 2114.
VPN traffic uses UDP with a default source and destination port of 1194.
The VPN port number is configurable. From the Grid perspective on the grid master, click id_grid -> Edit -> Grid
Properties -> Grid Properties, type a new port number in the VPN Port Number field, and then click the Save icon. After
changing the port number, you must reboot the single master or the active node of an HA master (which forces an HA
failover). From the Grid perspective, click + (for id_grid) -> + (for Members) -> master -> Edit -> Reboot.
A member and master first perform a handshake to authenticate each other and exchange encryption keys. Then they
build an encrypted VPN tunnel between themselves. The member typically initiates both of these connections. The
master only initiates a key exchange if you manually promote a member to the role of master (see Promoting a Master
Candidate on page 309). Figure 9.10 on page 279 shows the typical connection exchange and default port usage not
only between the two nodes forming an HA pair but also between a member and master when the member joins a
grid.
The member and master key exchange occurs when an appliance joins a grid, during master promotion, and when a
member reconnects to a grid after becoming disconnected. At all other times, grid-related communications occur
through encrypted VPN tunnels.
A VRRP-enabled
appliance comes online
Does an
advertisement
with its VRID
arrive within
3 secs?
Yes
No
Does
other appliance
have higher
priority?
Does
other appliance
have higher IP
address?
Become the active
node and start sending
VRRP advertisements.
Enter
passive
state
Enter
passive
state
Remain
active
Remain
active
Enter
passive
state
If another VRRP-enabled
appliance sends VRRP
advertisements with the
same VRID
Yes Yes
No No
Same
Deploying a Grid
Creating an HA Grid Master
To create a grid, you first create a grid master and then add members. Although you can define a single appliance as
a grid master, using an HA pair provides hardware redundancy for this vital component of a grid. The following
procedure explains how to put two NIOS appliances on the network and use the Infoblox NIOS Startup Wizard to
configure them as Nodes 1 and 2 to form an HA grid master. You cannot configure a NIOS virtual appliance as an HA
grid master.
To create an HA grid master using the Infoblox NIOS Startup Wizard:
Portfast: enable
Trunking: disable
Port list: disable
Putting Both Appliances on the Network
1. Connect the power cable from each NIOS appliance to a power source and turn on the power. If possible, connect
the appliances to separate power circuits. If one power circuit fails, the other might still be operative.
2. Connect ethernet cables from the LAN (or LAN1) port and the HA port on each appliance to a switch on the
network.
use either a straight-through or cross-over ethernet cable for these connections. For the Infoblox-500,
-1000, and -1200 appliances, use straight-through ethernet cables.
3. Use the LCD on one appliance or make a console connection to it, and configure the network settings of its LAN
or LAN1 port so that it is on the local subnet and you can reach it on the network.
Note: For details about using the LCD and console, see Using the LCD Panel on page 723 and Using the Serial
Console on page 723.
4. Similarly, configure the LAN or LAN1 port on the other appliance so that it is in the same subnet as the first
appliance.
5. Connect your management system to the network so that it can reach the IP addresses of the LAN or LAN1 ports.
HA Master Node 1
1. On your management system, open a browser window, and connect to https://ip_addr, where ip_addr is the
address of the LAN or LAN1 port on Node 1.
2. Click LAUNCH GRID MANAGER.
3. Log in using the default user name and password admin and infoblox. For detailed information about logging in
to the GUI, see Accessing the Infoblox GUI on page 38.
string1 is a text string that the two appliances use to authenticate each other when establishing a VPN
tunnel for ensuing bloxSYNC traffic. (The default grid name is Infoblox.)
string2 is a text string that both appliances use as a shared secret to authenticate each other when
establishing a VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
vip_addr and netmask are the VIP (virtual IP) address and its netmask.
ip_addr1 is the IP address of the gateway for the subnet on which the ports are set.
ip_addr2-5 are the IP addresses of the LAN and HA ports for Nodes 1 and 2.
number is the VRID (virtual router ID). This must be a unique VRID numberfrom 1 to 255for this subnet.
string3 is a single hexadecimal string (no spaces) for a password that is at least four characters long.
ip_addr6 is the IP address of an NTP (Network Time Protocol) server. You can enter IP addresses for multiple
NTP servers.
(respectively), and so these choices are presented here.
The last screen of the startup wizard states that the changed time settings require the application to restart.
When you click Finish, the application restarts.
5. Close the management window.
The configuration for Node 1 is complete.
Deployment Type Grid Master or Member
License Validation Check that a Keystone license is installed.
Grid Master or Member Grid Master
Single or HA Grid Master HA Grid Master; Node 1
HA Pair Settings HA Pair Name: string1
HA Pair Network Settings VIP Address: vip_addr
Netmask: netmask
Gateway: ip_addr1
Host Name: hostname
Virtual Router ID: number
appliance)
Deploying a Grid
HA Master Node 2
1. On your management system, open a new browser window, and connect to https://ip_addr, where ip_addr is the
address of the LAN or LAN1 port on Node 2.
3. Beginning on the third wizard screen, enter the following to set up Node 2 (the variables are explained in the
previous section for Node 1):
4. After completing the wizard, close the management window.
The setup of the HA master is complete. From now on, when you make an HTTPS connection to the HA pair, use
the VIP address.
Creating a Single Grid Master
Although using an HA master is ideal because of the hardware redundancy it provides, you can also use a single
appliance as the grid master. You cannot configure a NIOS virtual appliance as a grid master.
Setting up an appliance as a single grid master is very easy. If the appliance has the DNSone package with the
Keystone upgrade, it is already a grid master. You simply need to define the network settings for its LAN or LAN1 port.
The various procedures for defining the network settings for the LAN or LAN1 port of a single independent appliance
apply here as well; that is, you can use any of the following procedures to define the network settings for the LAN or
LAN1 port of the appliance that you want to make a single grid master:
LCD See Method 1 Using the LCD on page 234.
Console port Method 2 Using the CLI on page 234.
You can also use the Infoblox NIOS Startup Wizard and the Infoblox Grid Manager to create a single grid master. In
addition to providing a simple method accompanied by helpful information, the startup wizard allows you to change
the admin password and configure time settings for the appliance. Through the GUI, you can configure other settings
(although the configuration presented here covers just the basics):
Infoblox NIOS Startup Wizard See Using the Startup Wizard on page 285.
Infoblox Grid Manager See Using the Infoblox GUI on page 286.
Single or HA Grid Master HA Grid Master; Node 2
Node 2 Network Settings IP Address: ip_addr4
Netmask: netmask
Gateway: ip_addr1
Grid Properties Masters IP Address: vip_addr
Grid Name: string1
Using the Startup Wizard
To create a single grid master using the Infoblox NIOS Startup Wizard:
1. Connect the power cable from the NIOS appliance to a power source and turn on the power.
2. Connect an ethernet cable from the LAN (or LAN1) port on the appliance to a switch on the network.
and -1200 appliances, use a straight-through ethernet cable.
default IP address, enter: https://192.168.1.2 .
string1 is a text string that the grid master and appliances joining the grid use to authenticate each other
when establishing a VPN tunnel for ensuing bloxSYNC traffic. (The default grid name is Infoblox.)
string2 is a text string that the grid master and appliances joining the grid use as a shared secret to
authenticate each other when establishing a VPN tunnel for ensuing bloxSYNC traffic. (The default shared
secret is test.)
ip_addr1 and netmask are the IP address and netmask for the LAN or LAN1 port.
ip_addr2 is the IP address of the gateway for the subnet on which the LAN or LAN1 port is set.
string3 is a single alphanumeric string (no spaces) for a password that is at least four characters long.
ip_addr3 is the IP address of an NTP (Network Time Protocol) server.
Single or HA Grid Master Single Grid Master
Grid Settings Grid Name: string1
Deploying a Grid
(respectively), and so these choices are presented above.
Record and retain this information in a safe place. If you forget the shared secret, you need to contact
Infoblox Technical Support for help. When you add an appliance to the grid, you must configure it with the
same grid name, shared secret, and VPN port number that you configure on the grid master.
The last screen of the startup wizard states that the changed settings require the appliance to restart. When you
click Finish, the appliance restarts.
The setup of the single master is complete. From now on, when you make an HTTPS connection to the appliance, use
its new IP address.
Using the Infoblox GUI
To create a single grid master using the Infoblox Grid Manager GUI:
1. Connect the power cable from a NIOS appliance to a power source and turn on the power.
2. Connect ethernet cables from the LAN (or LAN1) port and the HA port on the appliance to a switch on the network.
and -1200 appliances, use a straight-through ethernet cable.
default IP address, enter: https://192.168.1.2 .
Network Settings IP Address: ip_addr1
Netmask: netmask
Gateway: ip_addr2
Host name: hostname
appliance)
7. To bypass the wizard and access the Infoblox Grid Manager GUI, click Cancel or the Close button ().
8. From the Grid perspective, click + (for Infoblox) -> + (for Members) -> infoblox.localdomain -> Edit -> Member
Properties.
9. In the Grid Member editor, click Node Properties, and then enter the following:
Member Type: Choose the type of appliance for the grid member. The default is Infoblox.
Note: You can configure a NIOS virtual appliance only as a grid member, not a grid master.
location.
10. Click Save, and then close the management window.
11. Initiate a new management session, and log in to the appliance using its new IP address.
12. From the Grid perspective, click + (for Infoblox) -> Edit -> Grid Properties.
13. In the Grid editor, click Grid Properties, and then enter the following information:
Name: Type the name of the grid. The default name is Infoblox.
Shared Secret: Type a shared secret that all appliances must use to authenticate themselves when joining
the grid. The default shared secret is test.
Retype Shared Secret: Type the shared secret again to confirm its accuracy.
VPN Port Number: Type the port number that the grid members use when communicating with the grid
master through encrypted VPN tunnels. The default port number is 1194.
After changing the port number, you must reboot the single master or the active node of an HA master
(which forces an HA failover). From the Grid perspective, click + (for id_grid) -> + (for Members) -> master ->
Edit -> Reboot. For more information, see Port Numbers for Grid Communication on page 281.
Enable Recycle Bin: Select the check box to enable the recycle bin feature. This option is supported only for
superusers. The recycle bin stores the deleted items when the user deletes grid, DNS, or DHCP
configuration items in the GUI for the grid member. Enabling the recycle bin allows you to undo the
deletions and to restore the items on the appliance at a later time. If you do not enable the recycle bin
feature, deleted items from the GUI are permanently removed from the database.
Note: Record and retain this information in a safe place. If you forget the shared secret, you need to contact
Infoblox Technical Support for help. When you add an appliance to the grid, you must configure it with the
same grid name, shared secret, and VPN port number that you configure on the grid master.
The setup of the single master is complete. From now on, when you make an HTTPS connection to the appliance,
use its new IP address.
Deploying a Grid
Adding Grid Members
You can add single appliances and HA pairs to a grid, forming single members and HA members respectively. A single
grid member can be either an Infoblox appliance or a NIOS virtual appliance. NIOS virtual appliances do not support
configuration as an HA pair, a grid master, or a grid master candidate.
You can also define an HA member on the grid master and then add two individual appliances to the grid as Node 1
and Node 2 to complete the HA member you defined on the master.
The process for adding either a single appliance or HA pair to a grid involves two steps:
1. Configuring the member on the grid master. In addition to defining the network and appliance settings for a
member, you can also configure service settings before you join the appliance or HA pair to the grid.
2. Defining the VIP or IP address of the grid master, the grid name, and the shared secret on the single appliance or
HA pair.
3. Joining the appliance or HA pair to the grid. If an appliance or HA pair cannot join the grid because of MTU
(maximum transmission unit) limitations on its network link, you can reduce the MTU that the master uses when
communicating with it. See Setting the MTU for VPN Tunnels on page 308.
Note: New members inherit all settings that you create at the grid level unless you override them at the member
level.
If you want to preserve some or all of the configuration and data on an appliance or HA pair after you join it to a grid,
you can use the merge function. For information about merging data from an appliance or HA pair to a grid, see
Backing Up and Restoring a Configuration File on page 222.
Adding a Single Member
The basic steps necessary to add a single member are as follows:
1. Define the network settings of the LAN port of the single appliance on the grid master.
2. Define the VIP or IP address of the grid master, the grid name, and the shared secret on the single appliance.
3. Initiate the join grid operation.
In addition, you can configure on the grid master the service settings such as DNS zones and records, DHCP networks
and address ranges, and so on for a member before or after you join the appliance to the grid. The basic steps for
adding a single member are presented below.
For information on how to configure a NIOS virtual appliance as a grid member, refer to the Quick Start Guide for
Installing NIOS Software on Riverbed Services Platforms.
Configuring the Single Member on the Grid Master
1. Log in to the grid master as a superuser.
2. From the Grid perspective, click id_grid -> Edit -> Add Grid Member.
3. In the Add Grid Member editor, click Node Properties, and then enter the following:
location.
4. Click the Save icon to add the single member to the grid.
Adding Grid Members
Joining an Appliance to a Grid
1. Log in to the appliance that you want to add to the grid. The appliance must be online and able to reach the grid
master.
2. From the Grid perspective, click + (for id_grid) -> + (for Members) -> hostname -> Edit -> Join Grid.
3. In the Join Grid dialog box, enter the following:
Virtual IP of Grid Master: Type the VIP address of the HA grid master or the LAN address of the single grid
master for the grid to which you want to add the appliance.
Retype Grid Shared Secret: To ensure accuracy, retype the shared secret.
Use MGMT port to join grid: If you have already enabled the MGMT port (see Grid Communications on page
139), this option becomes available. Select it to connect to the grid through the MGMT port.
4. Click OK to begin the join operation.
5. To confirm that the appliance has successfully joined the grid, log in to the grid master and from the Grid
perspective, click + (for id_grid) -> + (for Members), and check the icon in the Status column (green = the
appliance has joined the grid and is functioning properly; yellow = the appliance is in the process of joining the
grid; red = the appliance has not joined the grid). Also, select the member, and then click View -> Detailed Status.
Note: You can also use the set net wor k command to join an appliance to a grid.
Adding an HA Member
Note: You cannot add a NIOS virtual appliance as an HA member.
The basic steps necessary to add an HA member are as follows:
1. Define the network settings of the HA pair on the grid master.
2. Define the VIP or IP address of the grid master, the grid name, and the shared secret on the HA pair.
3. Initiate the join grid operation.
In addition, on the grid master you can configure the service settings such as DNS zones and records, DHCP networks
and address ranges, and so on for a member before or after you join the HA pair to the grid. The basic steps for adding
an HA member are presented below.
Note: The procedure for adding an HA pair to a grid when it uses the MGMT port of the active node for grid
communications differs slightly from that described below. See Grid Communications on page 139.
Configuring the HA Member on the Grid Master
2. From the Grid perspective, click id_grid -> Edit -> Add Grid Member.
Host Name: Type the FQDN (fully qualified domain name) for the HA member.
(V)IP Address: Type the VIP (virtual IP) address for the HA member.
Subnet Mask: Choose the netmask for the subnet to which the VIP address connects.
Gateway: Type the IP address of the default gateway of the subnet to which the VIP address connects.
Comment: Type a comment that provides some useful information about the HA member, such as its
location.
HA Pair: (select)
Deploying a Grid
Virtual Router ID: Enter a unique VRID numberfrom 1 to 255for the local subnet.
Master Candidate: Select the check box if you want to be able to promote the HA member to that of grid
master (see Promoting a Master Candidate on page 309). Clear the check box if you want the HA member to
be a regular member (that is, a member that is not and cannot be a grid master). If you want the HA member
to use the MGMT port of its active node for grid communications, it cannot be a master or master candidate.
Note: The VIP address and the IP addresses for all the following ports must be in the same subnet.
Node #1:
Node #2:
4. Click the Save icon to add the HA member to the grid.
Joining an HA Pair to a Grid
1. Log in to the HA pair that you want to add to the grid. The HA pair must be online and able to reach the grid master.
2. From the Grid perspective, click + (for id_grid) -> + (for Members) -> hostname -> Edit -> Join Grid.
3. In the Join Grid dialog box, enter the following:
Virtual IP of Grid Master: Type the VIP address of the HA grid master or the LAN address of the single grid
master for the grid to which you want to add the HA pair.
Retype Grid Shared Secret: To ensure accuracy, retype the shared secret.
Use MGMT port to join grid: If you have already enabled the MGMT port (see Grid Communications on page
139), this option becomes available. Select it to connect to the grid through the MGMT port of the active
node of the HA pair.
4. Click OK to begin the join operation.
5. To confirm that the HA pair has successfully joined the grid, log in to the grid master and from the Grid
perspective, click + (for id_grid) -> + (for Members), and check the icon in the Status column (green = the HA pair
has joined the grid and is functioning properly; yellow = the HA pair is in the process of joining the grid; red = the
HA pair has not joined the grid). Also, select the member, and then click View -> Detailed Status.
Configuration Example: Configuring a Grid
In this example, you configure seven NIOS appliances in a grid serving internal DHCP and DNS for an enterprise with
the domain name corp100.com. There are four sites: HQ and three branch offices. A hub-and-spoke VPN tunnel
system connects the sites, with HQ at the hub. The distribution and roles of the NIOS appliances at the four sites are
as follows:
HQ site (four appliances in two HA pairs):
HA grid master hidden primary DNS server
HA member secondary DNS server and DHCP server for HQ
Site 1 (two appliances in an HA pair): HA member secondary DNS server and DHCP server for Site 1
Site 2(one appliance): single member secondary DNS server and DHCP server for Site 2
Note: When adding Infoblox-1050, -1550, and -1552 appliances to an existing grid, you must first upgrade the grid
to DNSone 3.2r9 or later.
To create a grid, you first create a grid master and then add members. The process involves these three steps:
1. Configuring two appliances at HQ as the grid master. See Create the Grid Master on page 293.
2. Logging in to the grid master and defining the members that you want to add to the grid; that is, you configure
grid member settings on the grid master in anticipation of later joining those appliances to the grid. See Define
Members on the Grid Master on page 295.
3. Logging in to the individual appliances and configuring them so that they can reach the grid master over the
network and join the grid. See Join Appliances to the Grid on page 296.
After creating the grid and adding members, you use the Data Import Wizard to import DHCP and DNS data from
legacy servers. See Import DHCP Data on page 298 and Import DNS Data on page 299.
Finally, you transition DHCP and DNS service from the legacy servers to the Infoblox grid members. See Enable DHCP
and Switch Service to the Grid on page 303.
Deploying a Grid
Figure 9.13 Network Diagram
Cable All Appliances to the Network and Turn On Power
Cable the NIOS appliances to network switches. After cabling each appliance to a switch and connecting it to a power
source, turn on the power. For information about installing and cabling the appliance, refer to the user guide or
installation guide that ships with the product.
1. At HQ and Site 1, connect ethernet cables from the LAN1 and HA ports on the appliances in each HA pair to a
switch, connect the appliances to power sources, and turn on the power for each appliance.
Note: When connecting the nodes of an HA pair to a power source, connect each node to a different power
source if possible. If one power source fails, the other might still be operative.
. . .
. . .
. . .
. . .
HQ Site
Zone: corp100.com
Zone: lab.corp100.com
Zone: site1.corp100.com
Network: 10.1.1.0/24
Address Range:10.1.1.50 - 10.1.1.200
Legacy Secondary DNS Server
ns3.site1.corp100.com; 10.1.1.5 and
DHCP server 10.1.1.20
HA Grid Member
ns3.site1.corp100.com
VIP: 10.1.1.10
VRID: 111
Secondary DNS Server
DHCP Server
Single Grid Member
LAN: 10.2.1.10
DHCP Server
Network: 10.2.1.0/24
Address Range:10.2.1.50 - 10.1.1.200
Branch Office: Site 2 Branch Office: Site 1
Network: 10.0.15.0/24
Network: 10.0.1.0/24
Address Range:10.0.1.50 - 10.0.1.200
Address Range:10.0.15.50 - 10.0.15.200
HA Grid Member
ns2.corp100.com
VIP: 10.0.2.10
VRID: 210
DHCP Server
Grid Master
ns1.corp100.com
VIP: 10.0.1.10
VRID: 143
Hidden Primary
DNS Server
Legacy Hidden Primary
DNS Server
ns1.corp100.com;
10.0.1.5
Legacy Secondary
DNS Server
ns2.corp100.com; 10.0.2.5
and
NTP Server
3.3.3.3
All Infoblox
appliances are in
the Pacific time
zone
Internet
Firewalls
VPN Tunnel
2. At Site 2, connect an ethernet cable from the LAN1 port on the single appliance to a switch, connect the appliance
to a power source, and turn on the power for that appliance.
Create the Grid Master
Configure two appliances at HQ to be the two nodes that make up the HA pair forming the grid master.
Grid Master Node 1
1. By using the LCD or by making a console connection to the appliance that you want to make Node 1 of the HA pair
for the grid master, change the default network settings of its LAN1 port to the following:
Netmask: 255.255.255.0
Gateway: 10.0.1.1
2. Connect your management system to the HQ network, open a browser window, and connect to https://10.0.1.6.
The Infoblox Appliance Startup Wizard opens.
4. Enter the following to set up Node 1 of the HA pair:
When you click Finish, the Infoblox GUI application restarts. Close the browser window, leaving the JWS (Java
Web Start) login window open.
Wizard Screen Enter
Deployment type Grid master/member
License validation Check that a Keystone license is installed.
Grid type Grid master
HA node type First HA node
Grid information Grid Name: corp100
Shared Secret: Mg1kW17d
Node information Virtual IP: 10.0.1.10
Subnet Mask: 255.255.255.0
Gateway: 10.0.1.1
Node 1:
Node 2:
Default password New admin password: 1n85w2IF
Time settings Enable NTP: Select check box.
IP address: 3.3.3.3
Tijuana
Deploying a Grid
Grid Master Node 2
1. By using the LCD or by making a console connection to the appliance that you want to make Node 2 of the HA pair
for the grid master, change the default network settings of its LAN1 port to the following:
Netmask: 255.255.255.0
Gateway: 10.0.1.1
2. In the JWS login window, type 10.0.1.8 in the Hostname field.
4. When the Infoblox Appliance Startup Wizard opens, enter the following to set up Node 2 of the HA pair:
5. Confirm the configuration, and then on the last screen of the wizard, click Finish.
The HTTPS session terminates, but the JWS login window remains open.
6. In the JWS login window, type 10.0.1.10 (the VIP address for the grid master) in the Hostname field.
7. Log in using the default user name admin and the password 1n85w2IF.
8. To check the status of the two nodes forming the grid master, from the Grid perspective, click + (for corp100) ->
+ (for Members) -> 10.0.1.10. Check that the status indicators are all green in the Detailed Status panel.
During the joining process, an appliance passes through the following four phases:
1. Offline the state when a grid memberin this case, the second node of the HA pair composing the grid master
is not in contact with the active node of the master
2. Connecting the state when an appliance matching a member configuration contacts the master to join the grid
and negotiates secure communications and grid membership
3. Synchronizing the master transmits its entire database to the member
4. Running the state when a member is in contact with the master and is functioning properly
Note: Depending on the network connection speed and the amount of data that the master needs to synchronize
with the member, the process can take from several seconds to several minutes to complete.
Wizard Screen Enter
Deployment type Grid master/member
License validation Check that a Keystone license is installed.
Grid node type Grid master
HA node type Second HA node
Node information IP Address: 10.0.1.8
Subnet Mask: 255.255.255.0
Gateway: 10.0.1.1
Node provisioning Masters Virtual IP: 10.0.1.10
Grid Name: corp100
Shared Secret: Mg1kW17d
Define Members on the Grid Master
Before logging in to and configuring the individual appliances that you want to add to the grid, define them first on
the grid master.
HQ Site HA Member
1. On the grid master, open the Grid perspective, and then click corp100 -> Edit -> Add Grid Member.
(V)IP Address: 10.0.2.10
Subnet Mask: /24 (255.255.255.0)
Gateway: 10.0.2.1
Comment: HQ Site - ns2.corp100.com
HA Pair: Select check box.
Node 1:
LAN Address: 10.0.2.6
Node 2:
Site 1 HA Member
Host Name: ns3.site1.corp100.com
Subnet Mask: 255.255.255.0
Gateway: 10.1.1.1
Comment: Site 1 - ns3.site1.corp100.com
HA Pair: Select check box.
Node 1:
Node 2:
Deploying a Grid
Site 2 Single Member
Host Name: ns4.site2.corp100.com
Subnet Mask: 255.255.255.0
Gateway: 10.2.1.1
Comment: Site 2- ns4.site2.corp100.com
4. Log out from the grid master by clicking File -> Logout.
Join Appliances to the Grid
To complete the process of adding appliances to the grid, log in to and configure each individual appliance so that it
can contact the grid master.
HQ Site HA Grid Member (Node 1)
Make a console connection to the appliance that you want to make Node 1 in the HA pair, and enter the following:
NOTI CE: Al l HA conf i gur at i on i s per f or med f r omt he GUI . Thi s i nt er f ace i s used onl y
t o conf i gur e a st andal one node or t o j oi n a gr i d.
Ent er I P addr ess: 10.0.2.6
Ent er net mask [ Def aul t : 255. 255. 255. 0] :
Ent er gat eway addr ess [ Def aul t : 10. 0. 2. 1] :
Become gr i d member ? ( y or n) : y
Ent er Gr i d Mast er VI P: 10.0.1.10
Ent er Gr i d Name: corp100
Ent er Gr i d Shar ed Secr et : Mg1kW17d
New Net wor k Set t i ngs:
I P addr ess: 10. 0. 2. 6
Net mask: 255. 255. 255. 0
Gat eway addr ess: 10. 0. 2. 1
J oi n gr i d as member wi t h at t r i but es:
Gr i d Mast er VI P: 10. 0. 1. 10
Gr i d Name: cor p100
Gr i d Shar ed Secr et : Mg1kW17d
WARNI NG: J oi ni ng a gr i d wi l l r epl ace al l t he dat a on t hi s node!
I s t hi s cor r ect ? ( y or n) : y
Ar e you sur e? ( y or n) : y
The Infoblox application restarts. After restarting, the appliance contacts the grid master and joins the grid as Node 1.
HQ Site HA Member (Node 2)
Make a console connection to the appliance that you want to make Node 2 in the HA pair, and enter exactly the same
data you entered for Node 1 except that the IP address is 10.0.2.8.
After the application restarts, the appliance contacts the grid master and joins the grid as Node 2, completing the HA
member configuration for the HQ site.
Site 1 HA Grid Member (Node 1)
Make a console connection to the appliance that you want to make Node 1 in the HA pair at Site 1, and use the set
network command to configure its basic network and grid settings. Use the following data:
Netmask: 255.255.255.0
Gateway: 10.1.1.1
Grid Master VIP: 10.0.1.10
Grid Name: corp100
Grid shared secret: Mg1kW17d
The Infoblox application restarts. After restarting, the appliance contacts the grid master and joins the grid as Node 1.
Site 1 HA Grid Member (Node 2)
Make a console connection to the appliance that you want to make Node 2 in the HA pair at Site 1, and enter exactly
the same data you entered for Node 1 except that the IP address is 10.1.1.8.
After the application restarts, the appliance contacts the grid master and joins the grid as Node 2, completing the HA
member configuration for Site 1.
Site 2 Single Grid Member
Make a console connection to the appliance that you want to make Node 1 in the HA pair at Site 1, and use the set
net wor k command to configure its basic network and grid settings. Use the following data:
Netmask: 255.255.255.0
Gateway: 10.2.1.1
Grid Master VIP: 10.0.1.10
Grid name: corp100
Grid shared secret: Mg1kW17d
The Infoblox application restarts. After restarting, the appliance contacts the grid master and joins the grid.
To check the status of all the grid members, log in to the grid master at 10.0.1.10, and from the Grid perspective, click
+ (for corp100) -> + (for Members) -> 10.0.1.10. Check that the status indicators are all green in the Detailed Status
panel. As an appliance joins a grid, it passes through the following phases: Offline, Connecting, (Downloading
Release from Master), Synchronizing, and Running.)
Note: Depending on the network connection speed and the amount of data that the master needs to synchronize
with the member, the process of joining a grid can take from several seconds to several minutes to complete.
The grid setup is complete.
Deploying a Grid
Import DHCP Data
The Data Import Wizard is a software tool that you can download from the Infoblox Support site to your management
system. With it, you can import data from legacy DHCP and DNS servers to NIOS appliances. In this example, you use
it to import both DHCP and DNS data to the grid master at 10.0.1.10, which then uses the database replication
mechanism to send the imported data to other grid members. In the wizard, you also specify which grid members
serve the imported data. The wizard supports various types of DHCP formats, such as the following:
ISC DHCP
Lucent VitalQIP
Microsoft
Nortel NetID
CSV (comma-separated values); you can also import IPAM data in CSV format
In this example, all the DHCP data is in standard ISC DHCP format.
Note: Before using the Data Import Wizard, you must make an initial connection to the Infoblox GUI using JWS (Java
Web Start), which downloads to your management system the Java application files that you need to run the
wizard. Because you used JWS in Create the Grid Master on page 293, you already have the necessary files
installed.
Importing DHCP Data for HQ and Site 2
1. Save the DHCP configuration file from your legacy DHCP server at 10.0.2.20 to a local directory.
2. Visit www.infoblox.com/support , log in with your support account, and download the Data Import Wizard. The
Data Import Wizard application downloads to a container within a Java sandbox on your management system and
immediately launches, displaying the Welcome page.
3. After reading the information in the left panel, click Next.
4. Select Import to Infoblox Appliance, enter the following, and then click Next:
Hostname or IP address: 10.0.1.10
Username: admin
Password: 1n85w2IF
5. Select the following, and then click Next:
What kind of data would you like to import? DHCP/IPAM
Which legacy system are you importing from? ISC DHCP
Which appliance will be serving this data? 10.0.2.10
6. Type the path and file name of the DHCP configuration file saved from the legacy server, and then click Next.
or
Click Browse, navigate to the file, select it, click Open, and then click Next.
7. In the Global DHCP Configuration table, double-click the Value cell for the domain-name-servers row, and change
the IP addresses to 10.0.2.10.
8. When satisfied with the data, click Import.
You can view the status of the importation process and a summary report in the Data Import Wizard Log.
9. To enable DDNS updates, log in to the grid master, open the DHCP and IPAM perspective and click DHCP
Members -> corp100 -> Edit -> Grid DHCP Properties.
10. In the Grid DHCP Properties editor, click DNS Updates.
11. Select Enable dynamic DNS updates, and then click OK.
13. To check the imported DHCP configuration file, click DHCP Members -> + (for corp100) -> 10.0.2.10 -> View -> DHCP
Configuration.
14. In the DHCP configuration file, check that all the imported subnets are present, and navigate to the beginning of
the file and check that you see the ddns-updates on statement. ( If you see ddns-updates off , enable
DDNS updates for the grid as explained in steps 9-12.)
Importing DHCP Data for Site 1
1. Repeat the steps in Importing DHCP Data for HQ and Site 2, saving the DHCP configuration file from your legacy
DHCP server at 10.1.1.20, and importing it to the grid master at 10.0.1.10 for the member with IP address
10.1.1.10 to serve.
2. Check the imported DHCP configuration file by logging in to the grid master and from the DHCP and IPAM
perspective, click DHCP Members -> + (for corp100) -> 10.1.1.10 -> View -> DHCP Configuration.
Importing DHCP Data for Site 3
1. Repeat the steps in Importing DHCP Data for HQ and Site 2, saving the DHCP configuration file from your legacy
DHCP server at 10.1.1.20, and importing it to the grid master at 10.0.1.10 for the member with IP address
10.3.1.10 to serve.
2. After the importation process completes, check the imported DHCP configuration file by logging in to the grid
master and from the DHCP and IPAM perspective, click DHCP Members -> + (for corp100) -> 10.3.1.10 -> View ->
DHCP Configuration.
Import DNS Data
Using the Infoblox Data Import Wizard, import DNS data from the legacy hidden primary server at 10.0.1.5 to the new
hidden primary server at 10.0.1.10 (the grid master). There are three phases to this task:
Before Using the Wizard on page 299:
Save the named.conf file from the legacy server to a file in a local directory on your management system.
Enable the legacy server to perform zone transfers to the NIOS appliance.
Configure three name server groups for the grid, and allow the grid master/hidden primary DNS server at
10.0.1.10 to receive DDNS updates from the grid members at 10.0.2.10, 10.1.1.10, and 10.3.1.10. These
members act as secondary DNS servers and DHCP servers.
Using the Wizard on page 300: Define the source, destination, and type of DNS data in the DNS configuration
file (named.conf) that you want to import.
After Using the Wizard on page 302: Check the imported DNS configuration file.
In this example, all the DNS data is in BIND 9 format. The Data Import Wizard supports various types of DNS formats,
such as the following:
BIND 4, 8, and 9
Microsoft
Lucent VitalQIP
Nortel NetID
Before Using the Wizard
You must set up the legacy server and grid master before using the Data Import Wizard.
Legacy Server
1. Log in to the legacy name server at 10.0.1.5 and save the named.conf file, which contains all the DNS settings
that you want to import into the Infoblox name server, to a local directory on your management system.
2. On the legacy server, enable zone transfers to the NIOS appliance.
Deploying a Grid
Infoblox Grid Master DDNS Updates
1. Log in to the grid master at 10.0.1.10, open the DNS perspective and click DNS Members -> + (for corp100) ->
10.0.1.10 -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Updates and enter the following:
3. Override grid update settings: Select check box.
4. Allow dynamic updates from: Click Add.
5. In the Dynamic Updater Item dialog box, enter the following, and then click OK:
6. IP Address Option: Select this option, and enter 10.0.2.10 in the adjacent field.
7. Permission: Allow
9. Repeat steps 2 to 4 to add 10.1.1.10 and 10.2.1.10 as IP addresses from which you allow DDNS updates.
Note: When all DNS servers are members in the same grid, the members use database replication to synchronize all
their dataincluding DNS zone data. You can change the default behavior so that grid members use zone
transfers instead. In this example, grid members use database replication.
Infoblox Grid Master Name Server Groups
1. From the DNS perspective, click DNS Members -> corp100 -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Name Server Groups -> Add, to open the Grid Name Server Group dialog
box.
Name Server Group Name: HQ-Group
Grid Primary: ns1.corp100.com; Stealth: Select check box.
Grid Secondaries: Click Add -> Select Member, select ns2.corp100.com in the Select Grid Member dialog
box, and then click OK. Select Grid replication (recommended), and then click OK to close the Name Server
Group Member Secondary dialog box and return to the Grid Name Server Group dialog box.
4. Click OK to close the Grid Name Server Group dialog box.
5. Repeat steps 2 to 4 to create another group. Name it Site1-Group, and use ns1.corp100.com as the hidden
primary server, ns3.site1.corp100.com as a secondary server, and grid replication for zone updates.
6. Repeat steps 2 to 4 to create another group. Name it Site2-Group, and use ns1.corp100.com as the hidden
primary server, ns4.site2.corp100.com as a secondary server, and grid replication for zone updates.
Using the Wizard
While progressing through the Data Import Wizard, you must define the source, destination, and type of DNS data
that you want to import. You then make some simple modifications to the data and import it.
Defining the Source, Destination, and Type of DNS Data
1. Launch the Data Import Wizard.
2. After reading the information in the left panel of the welcome page, click Next.
3. Select Import to Infoblox Appliance, enter the following, and then click Next:
Hostname or IP address: 10.0.1.10
Username: admin
Password: 1n85w2IF
The Data Import Wizard Log opens in a separate window behind the wizard. Leave it open while you continue.
What kind of data would you like to import? DNS
Which legacy system are you importing from? BIND 9
Which appliance will be serving this data? 10.0.1.10
What BIND 9 DNS configuration file would you like to use? Click Browse, navigate to the named.conf file you
saved from the legacy server, select it, and then click Open.
What type of BIND 9 DNS data do you want to import? DNS zone information and DNS record data
Where is the BIND 9 DNS record data? Zone transfer(s) from a DNS server; 10.0.1.5
The wizard displays two tables of data. The upper table contains global DNS server configuration parameters.
The lower table contains zone configurations.
The Data Import Wizard Log presents a summary listing the number of views, zones, and DNS records in the
configuration file.
Modifying DNS Data
While importing data from the legacy DNS server, you cancel the importation of global configuration settings, and
apply the name server groups you created in Before Using the Wizard on page 299 to the zones you want to import.
1. In the Global DNS Configuration table, select all rows by clicking the top row and then SHIFT+clicking the bottom
row.
2. Right-click the selected rows to display the Set Import Options dialog box, select Do not import, and then click
Apply.
3. In the DNS Zones table, clear the Import check box for the default view.
4. Select corp100.com, lab.corp100.com and all the corresponding reverse-mapping zones.
Tip: You can use SHIFT+click to select multiple contiguous rows and CTRL+click to select multiple
noncontiguous rows.
5. Right-click the selected rows, and then select Set Import Options.
6. In the Set Import Options dialog box, enter the following, and then click Apply:
Set Zone Type: No change
Set Import Option: No change
Set View: default
Set Member: HQ-Group master
7. Select site1.corp100.com and all the reverse-mapping zones with 1 in the second octet in the zone name
(1.1.10.in-addr.arpa, 2.1.10.in-addr.arpa, 3.1.10.in-addr.arpa, and so on).
8. Right-click the selected rows, and select Set Import Options.
9. In the Set Import Options dialog box, make the same selections as in Step 6 , but choose Site1-Group master
from the Set Member drop-down list.
10. Similarly, select site2.corp100.com and all the reverse-mapping zones with 2in the second octet in the zone
name.
11. Right-click the selected rows, and select Set Import Options.
12. In the Set Import Options dialog box, make the same selections as in Step 6 , but choose Site2-Group master
from the Set Member drop-down list.
Deploying a Grid
Importing DNS Data
1. Click Import.
The wizard imports the global DNS parameters and zone-specific configuration settings from the named.conf
file and performs a zone transfer of the data from the legacy server.
2. Use the Data Import Wizard Log to monitor progress and review results afterward.
The log lists all the zones that the wizard imports and concludes with a total of all the successfully and
unsuccessfully imported zones.
Note: If the wizard is unable to import a zone, an error message with an explanation appears in the log.
3. To close the Data Import Wizard, click Exit. This closes the Data Import Wizard Log as well.
After Using the Wizard
After you import data, you must restart services on the grid master and delete the A records for the legacy servers
from the corp100.com zone. You can also confirm that the imported data is correct and complete by checking the DNS
configuration and the forward- and reverse-mapping zones.
1. Log in to the grid master (10.0.1.10), and then click the Restart Services icon.
Note: When importing data through the wizard rather than entering it through the GUI, the Restart Services icon
does not change to indicate you must restart service for the appliance to apply the new data. Still,
restarting service on the grid master is necessary for the imported configuration and data to take effect.
2. To remove A records for the legacy servers, from the DNS perspective, click Infoblox Views -> + (for Infoblox Views)
-> + (for default) -> + (for Forward Mapping Zones) -> corp100.com.
3. CTRL+click the following A records in the corp100.com zone, and then click Edit -> Remove Multiple:
ns1 (for 10.0.1.5)
ns2 (for 10.0.2.5)
ns3.site1.corp100 (for 10.1.1.5)
ns4.site3.corp100 (for 10.2.1.5)
4. Remove the respective A records for legacy servers from the site1.corp100 and site3.corp100 subzones.
5. To check the imported DNS configuration file, from the DNS perspective, click DNS Members -> + (for corp100) ->
10.0.1.10 -> View -> DNS Configuration.
Note: If you do not see the imported DNS configuration file, make sure you enabled DNS and restarted services.
6. Scroll through the DNS configuration log to check that each imported zone has an al l ow- updat e statement like
the following one for the 10.1.10.in-addr.arpa reverse-mapping zone:
zone " 10. 1. 10. i n- addr . ar pa" i n {
al l ow- updat e { key DHCP_UPDATER; 10. 0. 2. 10; 10. 1. 1. 10; 10. 2. 1. 10; };
};
Enable DHCP and Switch Service to the Grid
Finally, you must enable DHCP service on the three grid members at 10.0.2.10, 10.1.1.10, and 10.2.1.10, and switch
DNS and DHCP service from the legacy DNS and DHCP servers to them.
1. Log in to the grid master (10.0.1.10), from the DHCP and IPAM perspective, click DHCP Members -> + (for
corp100) -> 10.0.2.10 -> Edit -> Member DHCP Properties -> General Properties, select Enable DHCP Server , and
then click the Save icon.
2. Click 10.1.1.10 -> Edit -> Member DHCP Properties -> General Properties, select Enable DHCP Server , and then
click the Save icon.
3. Click 10.3.1.10 -> Edit -> Member DHCP Properties -> General Properties, select Enable DHCP Server , and then
click the Save and Restart Services icons.
Note: DNS service is enabled by default. To confirm that it is enabled, from the DNS perspective, click DNS
Members -> + (for corp100) -> 10.0.2.10 -> Edit -> Member DNS Properties -> General Properties, and make
sure the Enable DNS Server check box is selected.
The grid members are ready to serve DHCP and DNS, and send DDNS updates.
4. Take the legacy DHCP and DNS servers offline.
Deploying a Grid
Enabling IPv6 On a Grid Member
You can configure NIOS appliances to provide DNS services over IPv4 (Internet Protocol version 4) and IPv6 (Internet
Protocol version 6) networks. You can configure the grid member as a dual-mode name server, capable of serving DNS
data in response to both IPv4 and IPv6 queries. An IPv4 query returns an IPv4 response, while an IPv6 query returns
an IPv6 response.
Configuring a grid containing an IPv4 primary server and IPv6 secondary servers is not supported. You must make
enable IPv6 on both the primary and secondary servers within the grid to enable them to communicate with each
other. Infoblox highly recommends that you enable IPv6 on your grid appliances before configuring IPv6 secondaries,
forwarders, delegations, and subnets.
The NIOS appliance supports one IPv6 address on the grid member. Infoblox integrates IPv6 address management
into many of the same places where IPv4 addresses are entered. Data validation occurs on all IP address fields and
automatic validation is done to ensure proper entry of either an IPv4 address or an IPv6 address.
This section includes the following topics:
About IPv6 Addresses on page 304
Configuring IPv6 on a Grid Member on page 305
About IPv6 Addresses
An IPv6 address is a 128-bit number in colon hexadecimal notation. It consists of eight 16-bit groups of hexadecimal
digits separated by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
Figure 9.14 IPv6 Address Structure
When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros. You can
also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note that if there
are multiple noncontiguous groups of zeros, the double colon can only be used for one group to avoid ambiguity. The
NIOS appliance displays an IPv6 address in its shortened form, regardless of its form when it was entered. For more
information about DNS for IPv6, see RFC 3596, DNS Extensions to Support IP Version 6. For more information about
DNS management options, see Managing DNS Data on page 331.
Global Routing Prefix Subnet ID Interface ID
n bits m bits 128-n-m bits
Network Prefix Interface ID
Configuring IPv6 on a Grid Member
You can configure a grid member to support both IPv4 and IPv6 connections by configuring an IPv6 address on the
member, in addition to the standard IPv4 address.
When you enable IPv6 on a member, you can manually enter the IPv6 gateway address or enable the member to
automatically acquire the address from router advertisements. Routers periodically send router advertisements that
contain link-layer addresses and configuration parameters. A NIOS appliance that supports IPv6 can listen for router
advertisements and obtain the default gateway IP address and link MTU (maximum transmission unit). The link MTU
is the maximum packet size, in octets, that can be conveyed in one transmission unit over a link. Thus you can set
parameters on a router once and automatically propagate it to all attached hosts.
To configure the member to support IPv6:
2. From the Grid perspective, click grid -> grid_member -> Edit -> Member Properties.
3. In the Edit Grid Member editor, click Node Properties to open up that section, and then enter the following:
Enable IPv6: Select this check box to enable IPv6 support.
(V)IP Address: Type the IPv6 address for the grid member on the interface. An IPv6 address is a 128-bit
number in colon hexadecimal notation. It consists of eight 16-bit groups of hexadecimal digits separated
by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
CIDR Prefix: Choose the CIDR netmask for the subnet to which the VIP address connects. CIDR is an
alternative to subnet masking that organizes IP addresses into subnetworks. Also known as supernetting,
CIDR allows multiple subnets to be grouped together for network routing. The prefix length can range from 0
to 128, due to the larger number of bits in the IPv6 address.
Obtain router configuration automatically: Select this check box to enable the appliance to acquire the IP
address of the default gateway and the link MTU from router advertisements. When you select this check
box, you cannot enter a gateway IP address.
Gateway: Type the IPv6 address of the default gateway of the subnet to which the VIP address connects.
Comment: Type a comment that provides some useful information about the IPv6 interface.
Configuration Example: Configuring IPv6 on a Grid Member
Let us revisit the example network topology from the previous section Configuration Example: Configuring a Grid on
page 291. In the previous example, you configured seven NIOS appliances in a grid serving internal DHCP and DNS
for an enterprise with the domain name corp100.com. There were four sites: HQ and three branch offices. The
distribution and roles of the NIOS appliances at the four sites are as follows:
HQ site (four appliances in two HA pairs):
HA grid master hidden primary DNS server.
Enable this member (node 1 and node2) as a dual-mode member, supporting both IPv4 and IPv6
connections.
HA member secondary DNS server and DHCP server for HQ
Site 1 (two appliances in an HA pair): HA member secondary DNS server and DHCP server for Site 1.
Site 2(one appliance): single member secondary DNS server and DHCP server for Site 2.
For this example, let us consider only the steps required to update the HA grid master as a dual-mode appliance,
supporting both IPv4 and IPv6 connections.
Deploying a Grid
Figure 9.15 Network Diagram for IPv6 Grid Member Example

To configure the grid master to support both IPv4 and IPv6:
Node 1
1. Log in to the node 1 of the grid master as a superuser.
2. From the Grid perspective, click id_grid --> ns1.corp100.com -> Edit -> Member Properties.
Enable IPv6: Select the check box to enable IPv6.
(V)IP Address: Type the IPv6 address 2001::10.
CIDR Prefix: Choose /64 as the CIDR prefix.
. . .
. . .
. . .
. . .
HQ Site
Zone: corp100.com
Zone: lab.corp100.com
Network: 10.1.1.0/24
Address Range:10.1.1.50 - 10.1.1.200
HA Grid Member
VIP: 10.1.1.10
VRID: 111
DHCP Server
Single Grid Member
LAN: 10.2.1.10
DHCP Server
Network: 10.2.1.0/24
Address Range:10.2.1.50 - 10.1.1.200
Branch Office: Site 2 Branch Office: Site 1
Network: 10.0.15.0/24
Network: 10.0.1.0/24 (IPv4)
Network: 2001::/64 (IPv6)
Address Range:10.0.15.50 - 10.0.15.200
HA Grid Member
ns2.corp100.com
VIP: 10.0.2.10
VRID: 210
DHCP Server
Grid Master
ns1.corp100.com
VIP: 10.0.1.10 (IPv4)
Gateway: 10.0.1.1
VIP: 2001::10 (IPv6)
Gateway: 2001::1
VRID: 143
Hidden Primary
DNS Server
Legacy Hidden Primary
DNS Server
ns1.corp100.com;
10.0.1.5
Internet
Firewalls
VPN Tunnel
Gateway: Type the IPv6 gateway address 2001::1.
Comment: Type any useful comment.
Node 2
1. Log in to the node 2 of the grid master as a superuser.
2. From the Grid perspective, click id_grid --> ns1.corp100.com -> Edit -> Member Properties.
Enable IPv6: Select the check box to enable IPv6.
(V)IP Address: Type the IPv6 address 2001::11.
CIDR Prefix: Choose /64 as the CIDR prefix.
Gateway: Type the IPv6 gateway address 2001::1.
Comment: Type any useful comment.
Deploying a Grid
Managing a Grid
After you configure a grid master and add members, you might need to perform the following tasks:
Changing Grid Properties
Setting the MTU for VPN Tunnels
Removing a Grid Member
Promoting a Master Candidate on page 309
Replacing a Failed Grid Master on page 309
Changing Grid Properties
You can change a grid name, its shared secret, and the port number of the VPN tunnels that the grid uses for
communications. If you make such changes after populating a grid with members, all current members will lose grid
connectivity and you will have to rejoin them to the grid manually.
To modify the properties of a grid:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
Name: Type the name of a grid. The default name is Infoblox.
Shared Secret: Type a shared secret that all grid members use to authenticate themselves when joining the
grid. The default shared secret is test.
Retype Shared Secret: Type the shared secret again to confirm its accuracy.
VPN Port Number: Type the port number that the grid members use when communicating with the grid
master through encrypted VPN tunnels. The default port number is 1194. After changing the port number,
you must reboot the single master or the active node of an HA master (which forces an HA failover). For
more information, see Port Numbers for Grid Communication on page 281.
Enable Recycle Bin: Select the check box to enable the recycle bin feature. This option is supported only for
superusers. The recycle bin stores the deleted items when the user deletes grid, DNS, or DHCP
configuration items in the GUI for the grid member. Enabling the recycle bin allows you to undo the
deletions and to restore the items on the appliance at a later time. If you do not enable the recycle bin
feature, deleted items from the GUI are permanently removed from the database.
3. Click OK to save your changes.
4. (If necessary after changing the VPN port number) From the Grid perspective, click + (for id_grid) -> + (for
Members) -> master -> Edit -> Reboot.
Setting the MTU for VPN Tunnels
You can configure the VPN MTU (maximum transmission unit) for any appliance with a network link that does not
support the default MTU size (1500 bytes) and that cannot join a grid because of this limitation. If an appliance on
such a link attempts to establish a VPN tunnel with a grid master to join a grid, the appliance receives a PATH-MTU
error, indicating that the path MTU discovery process has failed. For information about the MTU discovery process,
see RFC 1191, Path MTU Discovery .
To avoid this problem, you can set a VPN MTU value on the grid master for any appliance that cannot link to it using
a 1500-byte MTU. When the appliance contacts the master during the key exchange handshake that occurs during
the grid-joining operation, the master sends the appliance the MTU setting to use.
To set the VPN MTU for a grid member:
1. From the Grid perspective, click + (id_grid ) -> + (for Members) -> member -> Edit -> Member Properties.
2. In the Grid Member editor, click VPN, select Set VPN MTU, and then enter a value between 600 and 1500.
3. Click the Save icon to save the VPN MTU settings for this member.
Managing a Grid
Removing a Grid Member
You might want or need to remove a member from a grid, perhaps to disable it or to make it an independent appliance
or an independent HA pair.
To remove a grid member:
2. From the Grid perspective, click + (for id_grid) -> + (for Members) -> member -> Edit -> Remove member.
Promoting a Master Candidate
To be able to promote a master candidate, you must have previously designated a grid member as a master candidate
before anything untoward happens to the current master. When adding or modifying a grid member, select the
Master Candidate check box in the Node Properties section in the Grid Member editor for that member.
To promote a master candidate, you can make a direct serial connection to the Console port on the active node of an
HA candidate or to the Console port on single candidate. You can also make a remote serial connection (using SSH
v2) to the candidate. Then enter the following Infoblox CLI command: set promote_master
Note: For information about making a serial connection, see Method 2 Using the CLI on page 234 and Using the
Serial Console on page 723.
To promote a master candidate, do the following:
1. Establish a serial connection (through a serial console or remote access using SSH) to the master candidate.
2. At the prompt, enter the command:
set promote_master
3. Log in to the Infoblox Grid Manager GUI on the new master using the VIP address for an HA master or the IP
address of the LAN or LAN1 port for a single master.
4. From the Grid perspective, click + (for id_grid) -> + (for Members) -> master .
5. Look at the IP address of the master in the IP Address column to ensure it is the member you promoted.
6. To verify the new master is operating properly, check the icon in the Status column. Also, select the master, and
then click View -> Detailed Status.
Replacing a Failed Grid Master
If a grid master goes down due to network issues or a power or system failure and there is no master candidate, you
can convert an existing member into a new grid master. This procedure assumes the current grid master is
inaccessible. Keep in mind that this is a disaster recovery procedure that is not part of normal appliance management
and maintenance. You must have an accessible grid member currently operating to perform this procedure.
To replace a grid master:
1. Determine which member you want to assume the grid master role. The following steps refer to the two nodes
which form an HA member. The active node is Node 1, and the passive node is Node 2. If you are unfamiliar with
using the Console port, see Method 2 Using the CLI on page 234 or Using the Serial Console on page 723.
2. Make a console connection to Node 2, and then enter the CLI command reset database
3. Make a console connection to Node 1, and then enter the CLI command set nogrid
These commands remove the HA pair from the grid and separate the two nodes that formed the HA pair. Node 1
becomes its own grid master. The result of this action is that this new grid master has all the service data as the
existing grid, but with all the member information removed.
4. Log in to the GUI of Node 1 using its LAN IP address. Configure the new master to be an HA pair. The VIP (virtual
IP) address of this HA pair will become the VIP address of the rebuilt grid. You do not need to use the same VIP
address of the failed grid master. Also, configure the grid name and shared secret.
Deploying a Grid
5. Using a serial console connected to Node 2, enter the set network command, and enter the network IP
address, netmask, and gateway settings. When prompted, join it to the new grid by entering the VIP address, grid
name, and shared secret that you set on Node 1.
6. Log in to the new grid master GUI using the grid master VIP. Add the remaining grid members to the new grid.
7. Set the DNS or DHCP properties as required.
8. Assign zones and networks for each member.
9. For each member in the grid, use the serial console to enter the reset database command. After logging back
in, enter set network, and enter the network IP address, netmask, and gateway settings. When prompted, join
it to the new grid by entering the VIP address, grid name, and shared secret that you set on the new grid master.
The grid is now rebuilt with a new grid master.
Using the Recycle Bin
You can use the recycle bin on the NIOS appliance to store deleted grid, DNS, and DHCP configuration items. Items
stored in the recycle bin can be restored to the active configuration on the appliance at a later time, or can be
permanently removed from the appliance database. If you do not use the recycle bin, the appliance deletes items
permanently from the database.
The recycle bin provides the capability to protect against major deletions of data. It is intended to provide a way to
restore data where the deletion of the object (such as a zone) would result in a major data loss.
This section discusses the following topics:
Disabling the Recycle Bin on page 310
Enabling the Recycle Bin on page 311
Restoring Items in the Recycle Bin on page 311
Disabling the Recycle Bin
The recycle bin is enabled by default. You can disable the recycle bin feature globally in the Grid perspective. If you
disable the recycle bin, you cannot restore nor empty the recycle bin. The recycle bin feature is enabled by default on
the NIOS appliance. If you do not have superuser privileges, a warning appears prompting you to relogin as superuser
before disabling the recycle bin.
To disable the recycle bin feature:
Enable Recycle Bin: Deselect the check box to turn off the recycle bin feature. If you do disable the recycle
bin feature, deleted items from the GUI are permanently removed and unrecoverable.
Enabling the Recycle Bin
You can enable the recycle bin feature globally in the Grid perspective. You must enable the recycle bin before
restoring and emptying the recycle bin from the ID Grid perspective or any other perspective. The recycle bin feature
is enabled by default on the NIOS appliance. If you do not have superuser privileges, a warning appears prompting
you to relogin as superuser before enabling the recycle bin.
To enable the recycle bin feature for items:
Enable Recycle Bin: Select the check box to enable the recycle bin feature. When you delete configuration
items in the GUI for the grid member, the recycle bin stores the deleted items. Enabling the recycle bin
allows you to undo the deletions and to restore the deleted items on the appliance at a later time. If you do
not enable the recycle bin feature, deleted items from the GUI are permanently removed and unrecoverable.
Viewing the Recycle Bin
You can display the Recycle Bin panel and view all deleted items stored in the recycle bin. If you view the recycle bin
panel within the Grid perspective, all items for the grid are displayed. This includes all DHCP and DNS configuration
items. By default, records are sorted by Name. To display the Recycle Bin panel and to view the deleted configuration
items stored in the recycle bin:
1. From the Grid perspective, click id_grid -> View -> Recycle Bin. The Recycle Bin panel appears.
2. Scroll through the Recycle Bin panel pages using the page arrows located on the lower-left corner of the Recycle
Bin panel. The panel page length is set by the administrator as discussed in Authenticating Administrators on
page 101. The panel displays each item with the following information:
Name: Name of the configuration item deleted.
Object Type: Type of configuration deleted.
Parent/Container: Where the item was deleted.
Admin: Who deleted the item.
Time: When the item was deleted.
Restoring Items in the Recycle Bin
You can restore any configuration items in the recycle bin displayed in the Recycle Bin panel. The restore functionality
is available only if the recycle bin is enabled, and if an item is selected in the panel. Deleted items are stored in the
recycle bin until the recycle bin is emptied.
To restore items from the Recycle Bin panel:
1. From the Grid perspective, click grid -> View -> Recycle Bin. The Recycle Bin panel appears.
2. Select the configuration item you want to restore.
3. Click Edit -> Restore Selected Object. A warning message appears prompting you to confirm that you wish to
continue with the restore.
4. Confirm that the item was restored to the active configuration. You can do this by confirming that the item does
not appear in the Recycle Bin panel any longer, and that it is reestablished in the appropriate perspective.
Deploying a Grid
Emptying the Recycle Bin
You can empty the contents of the recycle bin, permanently removing all of the items displayed in the Recycle Bin
panel from the appliance database. The empty functionality is available only if the recycle bin is enabled, and only
for superusers. To empty the recycle bin:
1. From the Grid perspective, click grid -> View -> Recycle Bin. The Recycle Bin panel appears.
2. Click Edit -> Empty Recycle Bin. A warning message appears prompting you to confirm that you wish to empty the
recycle bin.
3. Confirm that all items were removed from the Recycle Bin panel.
Upgrading NIOS Software on a Grid
Infoblox frequently releases updated NIOS software. To get the latest upgrades, your local network must be capable
of downloading a file from the Internet. After you have the new upgrade file stored on your local network, complete
the following tasks to upgrade an Infoblox independent appliance or grid.
Upload the new software to the grid master, as described in Uploading NIOS Software.
Distribute the software upgrade files, as described in Distributing Software Upgrade Files on page 315.
Optionally, test the upgrade, as described in Testing a Software Upgrade on page 319.
Perform the software upgrade, as described in Performing a Software Upgrade on page 320.
To minimize the impact of grid upgrades to your operations, you can organize members into upgrade groups and
schedule their software distribution. This is useful, for example, in a large grid spanning multiple time zones and
there are fluctuating network and downtime considerations at the various locations. You can group grid members
according to their locations or time zones, and schedule their distribution. Note that you can also schedule their
upgrade if the NIOS software upgrade is an Upgrade Lite compatible release. (See Lite Upgrades.) For information on
upgrade groups, see About Upgrade Groups on page 314.
Note: You cannot upgrade directly to NIOS 4.2 from certain DNS releases, such as DNS 3.1 and 3.2, and NIOS
releases, such as 4.0r1. Refer to the release notes for the appropriate upgrade and revert paths.
Before upgrading, Infoblox recommends that all members in the grid be connected to the network and operating
normally. If one or more members are offline when you upgrade the grid, they automatically receive the distributed
software and upgrade when they join the grid or come back online.
Caution: Do not attempt to add or remove a member from the grid, or convert an HA pair to single members or vice
versa during a distribution or upgrade.
Lite Upgrades
Whenever possible, NIOS uses the Upgrade Lite mode to speed up the upgrade process. A lite upgrade occurs only if
the format of the database and replication stream between the existing NIOS version and the upgrade version are the
same. Upgrade Lite reduces the risks associated with upgrades by not performing a database conversion and
upgrading only selected binary or configuration updates to the system.
Deploying a Grid
Uploading NIOS Software
After you download the NIOS software upgrade to your management station, upload it to the grid master, as follows:
1. From the Grid perspective, click the Grid menu item -> Upload NIOS Software.
2. Navigate to the directory where you stored the NIOS software, and then click OK.
The appliance displays the status of the upload.
After the NIOS software is successfully uploaded, the appliance displays a confirmation dialog that includes the
following information:
If the software is not upgrade lite compatible and if there is an active upgrade schedule configured, the
appliance displays a message indicating that the release cannot be scheduled for upgrade and sets the
upgrade schedule to inactive. It also provides instructions on distributing the software.
If the software is upgrade lite compatible, it indicates that the release can be scheduled for upgrade, and
provides instructions on distributing the software.
Note: When you upload the NIOS software upgrade to an HA grid master, only the active node receives the software.
The passive node does not. Therefore, if the grid master fails over before a distribution starts, you must upload
the software again. If you do not, the distribution fails because the new active node does not have the
uploaded software.
About Upgrade Groups
You can divide grid members into upgrade groups and schedule their distribution for times that are convenient for
your organization.
Note: You can schedule upgrades as well, if the software upgrade is an Upgrade Lite compatible release.
Infoblox provides two permanent upgrade groups that you cannot edit or delete:
Grid Master After you configure the grid master, it automatically becomes the only member of this group.
UnassignedThis is the default upgrade group to which NIOS automatically assigns grid members. If you do not
explicitly assign a member to an upgrade group, it remains in the Unassigned group.
The grid master distributes software upgrade files simultaneously to the members of this group after all
members of all groups have completed their distribution. The members of this group also upgrade
simultaneously, after all other grid members have upgraded as well.
Creating Upgrade Groups
When you create an upgrade group, you select the grid members for that group, and specify whether the software
distribution and upgrade occurs on all group members at the same time, or successively in the order they are listed
in the Group Members list. A grid member can belong to only one upgrade group.
Note: Infoblox recommends that you assign DHCP failover peers to separate upgrade groups, to minimize the risk of
a loss in DHCP service. For example, if DHCP failover peers are in the same upgrade group and its members
upgrade simultaneously, the upgrade causes a loss in DHCP service. Note that the appliance displays a
warning message when you create an admin group that includes DHCP failover peers.
To create an upgrade group:
1. In the Grid perspective, click the Upgrade Groups tab -> Edit -> Add Upgrade Group.
2. In the Add Upgrade Group editor, expand the Upgrade Group Properties section and enter the following:
Name: Enter a name for the upgrade group. The name can contain any alphanumeric character, spaces,
underscores, hyphens, and dashes.
Comment: Enter relevant information, such as location.
3. Expand the Group Member Assignment section and do the following:
Group Members: Click Add, select grid members to add to the group, and then click OK. Note that if you
choose to distribute and upgrade members sequentially, distribution and upgrade occur in the order in
which members are listed. You can reorder the list by selecting a member and clicking Move Up or Move
Down.
Tip: Use SHIFT+click to select multiple contiguous members and CTRL+click to select multiple noncontiguous
members.
After you add a member, the appliance adds it to the Group Members list. The first grid member in the list
determines the time zone of the group when you schedule the distribution and upgrade. Therefore the
appliance displays the time zone of the first grid member in the list. (For information about setting time
zones, see Managing Time Settings on page 117.)
Distribute to members: Specify the manner in which the grid master distributes software to the members in
the group:
Simultaneously: Select to distribute software upgrade files all at once to all group members.
Sequentially: Select to distribute software upgrade files to each member, in the order they are listed in
the Group Members list.
Upgrade Members: Specify the manner in which the group members upgrade to the new software version:
Simultaneously: Select to upgrade all members at the same time.
Sequentially: Select to upgrade members one by one, in the order they are listed in the Group Members
list.
Viewing and Managing Upgrade Groups
To view the upgrade groups of a grid, from the Grid perspective, click the Upgrade Groups tab -> + (for grid). The
appliance lists the upgrade groups you configured, as well as the Grid Master and Unassigned groups. To view the
members in each group, click + beside each group.
You can move members from one group to another and reorder the members in an upgrade group before a
distribution or upgrade starts. After a distribution starts, you can pause it and remove members from a group, as long
as their distribution has not started. The members you remove automatically join the Unassigned group. (For
information, see Pausing and Resuming Distribution on page 318.) You cannot reorder members while a distribution
or upgrade is in progress.
Distributing Software Upgrade Files
Distributing the software upgrade files involves unpacking the software files and loading the new software. When you
perform a distribution, the NIOS appliance loads the new software code into an alternate disk partition, which
overwrites any previously saved version of code already there. Therefore starting the distribution disables the
appliance from reverting to a release prior to the current version.
The time this process takes depends on the number of appliances to which the software is distributed; the more
appliances, the longer it takes. Therefore, you might want to schedule the grid distribution during times when your
network is less busy. You can schedule the distribution of any software upgrade file, even if it is not Upgrade Lite
compatible.
Scheduling a Distribution
The grid master distributes the software upgrade to each member in the grid, including itself. When you create a
distribution schedule, you schedule the distribution of the grid master as well as the upgrade groups. The grid master
distribution must always occur before the distribution of the upgrade groups. You do not schedule the distribution of
the Unassigned group because its distribution automatically occurs simultaneously on all its members after all
upgrade groups complete their distribution.
Deploying a Grid
To schedule the software distribution for a grid:
1. From the Grid perspective, click the Grid menu item -> Distribute -> Schedule Distribution.
2. In the Distribution Schedule dialog box, do the following:
Activate distribution schedule: Select this check box to enable the distribution schedule. Clear it if you are
creating a distribution schedule you plan to activate at a later date.
Distribution Start Time: Enter the grid master distribution date and time, and time zone that applies to the
time you enter. The distribution date and time must be before those of the upgrade groups.
Date: Enter the start date of the grid master distribution in MM/DD/YYYY format.
Time: Enter the start time of the grid master distribution in HH:MM:SS format.
Time Zone: Select the time zone that applies to the start time you entered. If this time zone is different
from the grid time zone, the appliance converts the time you entered to the time zone of the grid, after
you save this schedule. When you display this schedule again, it displays the time converted to the grid
time zone. (For information about setting the grid and member time zones, see Managing Time Settings
on page 117.)
For example, you specified the following time and time zone:
Time: 05:00:00
Time Zone: (UTC - 5:00) Eastern Time (US and Canada)
If the grid time zone is Pacific time, the appliance displays the time after you save the schedule, as
follows:
Time: 02:00:00
Time Zone: (UTC - 8:00) Pacific Time (US and Canada), Tijuana
Admin Local Time: Displays the grid master distribution date and start time in the time zone of the
administrator that is logged in to the appliance or the management system that is connected to the
appliance, depending on what was configured in the Administrators perspective, as explained in
Creating Local Admins on page 101.
Group Distribution Schedule: The dialog box lists the configured upgrade groups. Specify the following for
each upgrade group:
Distribute After: You can enter a distribution date and time, or specify that the distribution occurs after
that of the grid master or another upgrade group.
Date/Time: Select this option to enter the distribution start date and time.
Grid Master: Select this option to start the distribution immediately after the completion of the grid
master distribution. If you select this option, you cannot enter a date and time.
Select the upgrade group that must complete its distribution before the group you are configuring.
If you select this option, you cannot enter a date and time.
Date: Enter the distribution start date in MM/DD/YYYY format.
Time: Enter the distribution start time in HH:MM:SS format.
Time Zone: By default, the appliance displays the time zone of the first grid member in the Upgrade
Group. You can change this time zone, if you want to enter the time using a different time zone. After
you save the schedule though, the appliance converts the time you entered to the time zone of the
upgrade group, if it is different. (For information about setting the grid and member time zones, see
Managing Time Settings on page 117.) To change the default time zone of the upgrade group, change
the first group member in the Upgrade Group list, as explained in Creating Upgrade Groups on page
314.
For example, you specified the following distribution time and time zone:
Time: 05:00:00
If the time zone of the first member of the upgrade group is Pacific time, the appliance displays the time
in the member time zone (Pacific time) after you save the schedule, as follows:
Time: 02:00:00
Admin Local Time: If you entered a start date and time, this field displays them in the time zone of the
appliance, depending on what was configured in the Administrators perspective, as explained in
Creating Local Admins on page 101.
Distribute to Members: Indicates whether the distribution within the group occurs simultaneously or
sequentially. You cannot edit this field here. This was defined when you created the upgrade group.
3. Click OK to close the dialog box and save the schedule.
The appliance confirms that the schedule is saved and indicates whether the distribution schedule is active. It
also displays a warning message if an upgrade group contains members that are in the same DHCP failover
association.
Note that the appliance does not save the schedule and displays an error message if the schedule contains the
following:
Circular dependencies between upgrade groups; for example, the distribution of Group A is scheduled after
Group B, and the distribution of Group B Is scheduled after Group A.
The distribution time is in the past.
Distributing Software Immediately
As an alternative to scheduling the grid distribution, you can distribute the software upgrade throughout the grid
immediately, as follows:
1. From the Grid perspective, click the Grid menu item -> Distribute -> Distribute Now.
2. When the confirmation dialog box displays, click OK to start the distribution.
The distribution starts and if there is an active distribution schedule, the appliance changes its status to
inactive.
Software Distribution Process
The following series of events occur after a grid distribution starts:
The appliance checks if a NIOS software upgrade was uploaded.
If the upgrade files were not uploaded, distribution stops. The appliance displays an error message and if
the distribution was scheduled, the appliance deactivates the distribution schedule.
If the upgrade files were uploaded, the distribution proceeds.
A single grid master uploads the file to a backup partition and unpacks the contents, which overwrites any
existing backup software that might have been there. For an HA grid master, it is the active node that uploads
the file to a backup partition and unpacks the contents.
The grid master (or active node of the HA grid master) sends a command to all nodes that are online to copy
their database and software to a backup software partition.
For an HA grid master, the active node sends the command to the passive node as well.
The nodes performs rsync on their backup partition, retrieving only the changed files from the grid master.
After the active node of an HA member receives the software, it then distributes it to the passive node.
When the distribution successfully completes, the appliance updates the distribution status and sets the schedule,
if configured, to inactive. The new software is now staged on all member appliances and is ready for use.
Deploying a Grid
Pausing and Resuming Distribution
You can pause a distribution and do the following:
Change the start times of upgrade groups that did not start their distribution. The start times must be in the
future.
Remove members from an upgrade group, if their distribution did not start.
You cannot create new upgrade groups or add members to a group after a distribution starts.
To pause a distribution:
1. From the Grid perspective, click Grid -> Distribute -> Pause Distribution.
2. When the appliance displays a confirmation dialog box, click OK to pause the distribution.
The Upgrade Group Status indicates that the distribution was paused, as shown in Figure 9.16. For information on
the Upgrade Group Status panel, see Monitoring Distribution and Upgrade Status on page 324.
Figure 9.16 Paused Distribution
To resume a distribution:
1. From the Grid perspective, click Grid -> Distribute -> Resume Distribution.
2. When the appliance displays a dialog box confirming that you want to resume the distribution, click OK to
continue.
Members that did not complete their distribution and did not start although their schedules are past, resume
distribution.
Ending Distribution
You can stop a distribution immediately, for example, if there are offline members and you do not want to wait for
them to come back online or if you realize that you uploaded the wrong software version. When you end the
distribution, you can do the following:
If the grid master completed its distribution, you can upgrade the grid immediately. This forces members that do
not have a complete distribution to synchronize their releases with the grid master.
If the grid master does not have a valid distribution, you can restart the distribution or upload another software
upgrade.
Ending the distribution does not affect the upgrade schedule (if configured). The grid upgrade starts as scheduled,
as long as the grid master completes its distribution.
To stop a distribution:
From the Grid perspective, click Grid -> Distribute -> Stop Distribution.
Testing a Software Upgrade
After you successfully distribute the software upgrade to the grid master, you can test the upgrade on the grid master
before actually implementing it. This allows you to resolve potential data migration issues before the actual upgrade.
The length of time the upgrade test takes depends on various factors, such as the amount of data and the difference
between the current NIOS version and the software upgrade. The test does not affect NIOS services, and you can
perform other administrative tasks during the upgrade test.
To start an upgrade test:
From the Grid perspective, click the Grid menu item -> Upgrade -> Start Upgrade Test.
After you start the upgrade test, you can view its status in the Upgrade Status panel.
From the Grid perspective, click View -> Upgrade Status.
After you start the upgrade test, you can stop it at anytime. To stop an upgrade test:
From the Grid perspective, click the Grid menu item -> Upgrade -> End Upgrade Test.
Note that if an admin restarts the grid services or reboots the grid master, or if an HA failover occurs on the grid master
during the upgrade test, the appliance automatically stops the test. The appliance always resets the status of the grid
to Distributed when it stops the upgrade test.
If the appliance encounters an error during the test, it stops it and displays a message in the Upgrade Status panel
indicating that the upgrade test failed and the reason for the failure, such as a data translation error or an error during
the data import. You must then download the Support Bundle and contact Infoblox Technical Support.
After the test successfully finishes, the appliance displays a message indicating that the upgrade test was successful.
You can then perform the actual upgrade as described in Performing a Software Upgrade on page 320.
Deploying a Grid
Performing a Software Upgrade
Performing the software upgrade involves rebooting the appliances and then running the new software. Essentially,
each appliance switches between the two software partitions on its system, activating the staged software and saving
the previously active software and database as backup.
Note: Before you upgrade the software, Infoblox recommends that you back up the current configuration and
database.
When upgrading to software releases that are Upgrade Lite compatible, you can schedule the grid upgrade as
described in the next section.
Scheduling an Upgrade
When you schedule the upgrade of a grid to an Upgrade Lite compatible release, you schedule the upgrade of the grid
master as well as the upgrade groups. The grid master must always upgrade before the upgrade groups. The members
of the Unassigned group always upgrade simultaneously after all members of all groups have completed their
upgrade.
To create an upgrade schedule:
1. From the Grid perspective, click the Grid menu item -> Upgrade -> Schedule Upgrade.
2. In the Upgrade Schedule dialog box, do the following:
Activate upgrade schedule: Select this check box to enable the upgrade schedule. Clear it if you are creating
an upgrade schedule that you plan to activate at a later date.
Upgrade Start Time: Enter the grid master upgrade date and time, and time zone that applies to the start
time you entered. The date and time must be before those of the upgrade groups.
Date: Enter the start date of the grid master upgrade in MM/DD/YYYY format.
Time: Enter the start time of the grid master upgrade in HH:MM:SS format.
Time Zone: Select the time zone that applies to the start time that you entered. If this time zone is
different from the grid time zone, the appliance converts the time you entered to the time zone of the
grid, after you save this schedule. When you display this schedule again, it displays the time converted
to the grid time zone. (For information about setting the grid and member time zones, see Managing
Time Settings on page 117.)
For example, you specified the following time and time zone:
Time: 05:00:00
If the grid time zone is Pacific time, the appliance displays the time and time zone after you save the
schedule, as follows:
Time: 02:00:00
Admin Local Time: Displays the grid master upgrade date and start time in the time zone of the
appliance, depending on what was configured in the Administrators perspective. (For information, see
Creating Local Admins on page 101.)
Group Upgrade Schedule: The dialog box lists the configured upgrade groups. Specify the following for each
upgrade group:
Upgrade After: You can enter an upgrade date and time, or specify that the upgrade occurs after that of
the grid master or another upgrade group.
Date/Time: Select this option to enter the upgrade start date and time.
Grid Master: Select this option to start the upgrade immediately after the grid master upgrades. If
you select this option, you cannot enter a date and time.
Select the upgrade group that must upgrade before the group you are configuring. If you select this
option, you cannot enter a date and time.
Date: Enter the upgrade start date in MM/DD/YYYY format.
Time: Enter the upgrade start time in HH:MM:SS format.
Time Zone: By default, the appliance displays the time zone of the first grid member in the Upgrade
Group. You can change this time zone, if you want to enter the time using a different time zone. After
you save the schedule though, the appliance converts the time you entered to the time zone of the
upgrade group, if it is different. (For information about setting the grid and member time zones, see
Managing Time Settings on page 117.)
For example, you specified the following upgrade time and time zone:
Time: 05:00:00
If the time zone of the first member of the upgrade group is Pacific time, the appliance displays the time
in the member time zone after you save the schedule:
Time: 02:00:00
Admin Local Time: Displays the start date and time in the time zone of the administrator that is logged
in to the appliance or the management system that is connected to the appliance, depending on what
was configured in the Administrators perspective. (For information, see Creating Local Admins on page
101.)
Upgrade Members: Indicates whether the upgrade within the group occurs simultaneously or sequentially.
You cannot edit this field here. This was defined when you created the Upgrade Group.
3. Click OK to close the dialog box and save the schedule.
The appliance does not save the schedule and displays an error message if the schedule contains the following:
Circular dependencies between upgrade groups; for example, the upgrade of Group A is scheduled after
Group B, and the upgrade of Group B Is scheduled after Group A.
The upgrade time is in the past.
Otherwise, the appliance confirms that the schedule is saved and indicates whether the upgrade schedule is
active. It also displays a warning message if an upgrade group contains members that are in the same DHCP
failover association.
Upgrading Immediately
You cannot schedule upgrades to releases that are not Upgrade Lite compatible. The grid members must upgrade at
the same time when upgrading to these releases. For Upgrade Lite compatible releases, you can schedule the
upgrade as described in the preceding section, or upgrade the grid at the same time.
To upgrade a grid immediately:
From the Grid perspective, click Grid -> Upgrade -> Upgrade Now.
The grid upgrades immediately and if there is an active upgrade schedule, it becomes inactive.
Deploying a Grid
Upgrade Process
When an upgrade starts, the grid master checks if all grid members successfully completed the software distribution.
If they have not, the upgrade process stops. The appliance displays an error message and if it is a scheduled upgrade,
the appliance deactivates the schedule as well. Otherwise, the upgrade process continues.
Due to the nature of the upgrade sequence, HA pairs fail over during the upgrade. Therefore, be aware that the active
and passive nodes reverse roles. The order in which grid members upgrade, including when HA pairs fail over, is
shown in Figure 9.18 (for an HA grid master) and Figure 9.18 on page 323 (for a single grid master).
Figure 9.17 Upgrade Sequence for an HA Grid Master and Grid Members
3
5
4
1
2
3
3
Failover
Active
HA Grid
Member
Node 1
Grid
HA Grid
Master
Node 2
Node 1 Node 2
Passive
Active Passive
Single
Grid
Member
Node 1 (now passive) of the HA
member upgrades.
Node 1 (now passive) of the
grid master upgrades. The
passive node (Node 2) of the
HA member and the single grid
member upgrade.
The passive node (Node 2) of
the grid master upgrades.
The grid master fails over from
Node 1 to Node 2.
At this point, the grid master is
using upgraded code. The HA
grid member fail overs (because
the code on Node 1 does not
match that on the grid master,
but the code on Node 2 does).
Failover
1
2
3
5
4
Figure 9.18 Upgrade Sequence for a Single Grid Master and Grid Members
The GUI session terminates when the HA grid master fails over from Node 1 to Node 2, or when the single grid master
reboots and goes offline.
For scheduled upgrades, you can edit the start time of upgrade groups that have not yet started upgrading while an
upgrade is in progress. When the upgrade finishes, the Upgrade schedule is set to inactive.
3
1
3
4
2
1
4
2
2
Failover
Active
HA Grid
Member
Grid
Single Grid
Master
Node 1 Node 2
Passive
Single Grid
Member
Node 1 (now passive) of the
HA member upgrades.
Node 2 (passive) of the HA
member and the single
member upgrade.
Single grid master upgrades.
The HA member fails over
from Node 1 to Node 2.
Deploying a Grid
Monitoring Distribution and Upgrade Status
The Upgrade Status panel displays status and version information on the top half. The bottom half of the panel
displays status icons indicating the distribution or upgrade status, as shown in Upgrade Status PanelFigure 9.19.
Figure 9.19 Upgrade Status Panel
The appliance status icon can be one of the following colors:
Icon Color Meaning
Green The distribution or upgrade has successfully completed.
Yellow The distribution or upgrade is in progress.
Gray No distribution or upgrade is in progress.
Red The distribution or upgrade failed, or the grid member is offline because it is rebooting.
You can view the distribution and upgrade status of a grid as follows:
To view the distribution and upgrade status of each member in a grid, from the Grid, select the grid and then
click View -> Upgrade Status.
As shown in Figure 9.20, the Upgrade Status panel displays the status of each grid member.
Figure 9.20 Status of Grid Members
Deploying a Grid
To view the distribution and upgrade status of each group in the grid, as shown in Figure 9.21, from the Upgrade
Groups tab, select the grid and then click View -> Upgrade Status.
The Upgrade Status panel displays the status of each upgrade group in the grid.
Figure 9.21 Status of Upgrade Groups
To view the status of members in an upgrade group, from the Grid perspective, click the Upgrade Groups tab -> +
(for grid) -> upgrade_group -> View -> Upgrade Status.
The Upgrade Status panel displays the status of each member in the group.
Figure 9.22 Status of Upgrade Group Members
To view the status of each grid member, from the Grid perspective, click the Upgrade Groups tab -> + (for grid) ->
upgrade_group -> grid_member -> View -> Upgrade Status.
The Upgrade Status panel displays the distribution status of the member. It displays the status of each step in
the distribution process.
Figure 9.23 Status of a Grid Member
You can view the upgrade status in the same way as the distribution status. The only difference is that during an
upgrade, the GUI session terminates when the HA grid master fails over from Node 1 to Node 2, or when the single
grid master reboots and goes offline. You can log back in and view the upgrade status of the members. Note that when
members are rebooting, the status panel displays a red icon that indicates the members are not connected, as shown
in Figure 9.24.
Figure 9.24 Upgrade Status with Members Rebooting
Deploying a Grid

Part 3 Service Configuration
This section describes how to configure NIOS appliances to provide various services on your network. It includes the
following chapters:
Chapter 10, "Managing DNS Data", on page 331
Chapter 11, "Shared Records", on page 411
Chapter 12, "Configuring DNS Services", on page 423
Chapter 13, "Configuring IP Routing Options", on page 449
Chapter 14, "Managing DHCP Data", on page 459
Chapter 15, "Configuring DHCP Services", on page 483
Chapter 16, "Using Network Discovery", on page 519
Chapter 17, "Configuring DDNS Updates from DHCP", on page 537
Chapter 18, "Managing IP Data IPAM", on page 557
Chapter 19, "NAC Foundation", on page 581
Chapter 20, "File Distribution Services", on page 605
Chapter 21, "RADIUS Services", on page 613
Chapter 22, "IPAM WinConnect", on page 643
Chapter 23, "VitalQIP", on page 647

Chapter 10 Managing DNS Data
DNS (Domain Naming System) translates IP addresses to host names and back. The types of DNS servers are:
Root name servers that are in each top-level domain (com, edu, gov, and net). They determine where the
individual records are stored.
Static servers that every computer on the Internet can access.
Authoritative servers that contain the actual information about each individual domain. This information is
stored in a zone file. The root name servers query authoritative servers to determine the hostname or the IP
address.
DNS uses an efficient, reliable, distributed, and generic mapping system.
Efficientit uses caching and maps most names locally; only a few require Internet traffic.
Reliablea single machine failure does not break the system.
Distributeda set of servers operating at multiple sites together solve the mapping.
Genericit is not restricted to machine names.
The NIOS appliance uses a standard, BIND-based DNS protocol engine; it operates with any other name server that
follows the DNS RFCs (see DNS RFC Compliance on page 690). Managing DNS data includes configuring and
managing Infoblox views, zones, adding records, and managing hosts and records.
Note: Limited-access admin groups can access certain DNS resources only if their administrative permissions are
defined. For information on setting permissions for admin groups, see Managing DNS Resource Permissions
on page 83.
This chapter explains these topics and is organized as follows:
Configuring DNS Overview on page 334
DNS Configuration Checklist on page 335
Restarting Services on page 336
Using Infoblox DNS Views on page 337
Default View on page 339
Creating Views on page 339
Specifying Match Lists on page 341
Adding Zones to a View on page 342
Adding Records to a Zone on page 342
Managing Views on page 344
Configuration Example: Configuring a View on page 345
Managing DNS Data
Understanding DNS for IPv6 on page 347
IPv6 Overview on page 347
Delegating Zone Authority to Name Servers on page 349
Specifying a Primary Server on page 349
Specifying a Secondary Server on page 350
Configuring Authoritative Zones on page 353
Creating an Authoritative Forward-Mapping Zone on page 353
Creating an Authoritative Reverse-Mapping Zone on page 354
Adding an Authoritative Subzone on page 356
Creating a Root Zone on page 358
Importing Zone Data on page 359
Allowing Zone Transfers to an Appliance on page 362
Importing Data into Zones on page 362
Configuring Delegated, Forward, and Stub Zones on page 365
Configuring a Delegated Zone on page 365
Configuring a Forward Zone on page 366
Configuring Stub Zones on page 368
Using Name Server Groups on page 376
Creating Name Server Groups on page 376
Applying Name Server Groups on page 378
Managing Zones on page 379
Locking and Unlocking Zones on page 379
Removing Zones on page 380
Enabling and Disabling Zones on page 382
Specifying Host Name Restrictions on page 384
Adding Hosts on page 387
Adding Bulk Hosts on page 389
Specifying Bulk Host Name Formats on page 389
Before Defining Bulk Host Name Formats on page 389
Configuring Bulk Hosts on page 391
Adding Resource Records on page 394
Adding NS Records on page 395
Adding AAAA Records on page 395
Adding PTR Records on page 396
Adding MX Records on page 397
Adding SRV Records on page 398
Adding TXT Records on page 399
Adding CNAME Records on page 400
Adding DNAME Records on page 402
Specifying Time To Live Settings on page 407
Managing Hosts and Resource Records on page 408
Modifying, Disabling, or Removing a Host or Record on page 408
Viewing DNS Record Listings on page 409
Managing DNS Data
Configuring DNS Overview
An overview of the complete DNS configuration process is outlined in the following diagram, illustrating the required
steps for preparing a NIOS appliance for use:
Begin the initial configuration of DNS zones and resource records.
Decide on the type of
DNS zones to configure
Forward zone
Primary or secondary zone Delegated zone
Choose type of
authoritative zone
- Specify the IP address of the DNS
primary server
- Repeat this step to define other
forward zones or define other
types of zones (optional)
- Specify the IP address and the
FQDN of the DNS primary server
- Repeat this step to define other
delegated zones or define other
types of zones (optional)
- Choose the primary member
- Add resource records
- Specify the IP address and FQDN
of the external primary
- Choose the secondary members
Primary only zone
Secondary only zone
- Choose the primary member(s)
- Choose the secondary member(s)
- Specify the IP addresses and FQDN for external secondaries
- Proceed to add resource records
Primary and
secondary zone
Add resource records
- Select the zone to which you want to add records
- Choose a record zone type
- Enter the necessary data for the selected record
- Repeat these steps to add additional records (optional)
Do you want to create
more zones?
Initial configuration of DNS zones and resource records is complete
Yes
Configuring DNS Overview
DNS Configuration Checklist
Each step in the previous flowchart above is covered in the following checklist:
Table 10.1 DNS Configuration Checklist
Step For more information
Decide if you want to create a new view,
in addition to the default view.
Creating Views on page 339
Ordering Views on page 343
Managing Views on page 344
Configuration Example: Configuring a View on page 345
Decide which type of DNS zone you want
to configure
Configuring Authoritative Zones on page 353
Configure the zone
Importing Zone Data on page 359
Configure a host
Adding Bulk Hosts on page 389
Add resource records
Adding A Records on page 394
Managing DNS Data
Restarting Services
When you make changes to the services for a grid or member, you must restart services. You can make multiple
changes before restarting the service, however. This process invalidates the cache. To clear the DNS cache, from the
DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Clear Cache.
Note: Restarting services restarts both DNS and DHCP services on the selected nodes.
Restarting Services for a Grid
To restart services for a grid and all its members:
1. From the DNS perspective, click the DNS Members tab -> grid.
2. Select Restart Grid Services, and choose from the following options:
Sequentially: If you have multiple nodes in the grid, this option restarts the services on each of the nodes
according to the number of seconds you enter in the field. For example, if 10 is entered in the field, each
subsequent node restarts services 10 seconds after the previous node restarted services. You must enter
numbers, not text.
Immediately: This option restarts the services on all of the nodes in a grid immediately.
3. Click Restart Details to view the services being restarted.
4. Click Refresh to initiate the restart request. The more zones and networks that the member manages, the longer
this takes. When the term Request i ng changes to Yes, the node is ready to be restarted.
5. Click OK.
Restarting Services for a Member
To restart services for a specific member of a grid:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member.
2. Click the Restart Services icon, and select from the following options:
Restart Services: This option only restarts the services displayed in the Restart Service Status dialog box.
Force Restart Services: This option restarts all of the services managed by the member.
3. Click Restart Details to view the services being restarted on this member.
4. Click Refresh to verify the services being restarted. Only the service(s) with a Yes are restarted.
5. Click OK.
Using Infoblox DNS Views
Infoblox views provide the ability to serve one version of DNS data to one set of clients and another version to another
set of clients. With Infoblox views, the NIOS appliance can provide a different answer to the same DNS query,
depending on the source of the query.
In Figure 10.1, the appliance has two views: an internal view that contains private IP addresses and an external view
that contains public IP addresses. The appliance receives queries from both internal and external clients. When it
receives a query from Client A (an internal client) the appliance accesses the internal view and responds with the
private IP address of the site. When it receives a query from Client B (an external client) the appliance accesses the
external view and responds with the public IP address of the requested site.
Figure 10.1 Internal and External Views
You can configure both forward and reverse mapping zones in views and provide DNS services, such as name
resolution, zone transfers and dynamic DNS updates. For information about these services, see Configuring DNS
Services on page 424.
You can provide multiple views of a given zone with a different set of records in each view. In Figure 10.2, both views
contain the corp100.com zone and the sales.corp100.com zone. The finance.corp100.com zone is only in the internal
view, and only internal users are allowed access records in that zone. Resource records can also exist in multiple
zones. In the Figure 10.2 example, the A records for serv1.sales.corp100.com and serv2.sales.corp100.com are in
the sales.corp100.com zones in both views.
Figure 10.2 Zone Data in Each View
A-1 A-2
A-3
B-1
B-2 B-3
Client A, an internal client, sends a
request for sales.corp100.com.
The appliance retrieves the
answer from the internal view.
The appliance responds
with 10.1.1.5.
Internal View
External View
The appliance retrieves the
answer from the external view.
The appliance responds
with 1.1.1.5.
Client B, an external client, sends
a request for sales.corp100.com.
corp100.com zone
10.1.1.5 sales.corp100.com
corp100.com zone
1.1.1.5 sales.corp100.com
Client B
Client A
MX rmail.corp100.com
NS dnsoneA.corp100.com
A host1.corp100.com
A host2.corp100.com
External View
corp100.com Internal View
corp100.com
sales.corp100.com
sales.corp100.com
finance.corp100.com
MX email.corp100.com
A web1.corp100.com
A web2.corp100.com
A serv1.sales.corp100.com
A printer.sales.corp100.com
A host1.sales.corp100.com
A host2.sales.corp100.com
A web3.sales.corp100.com
A ftp.sales.corp100.com
A server.finance.corp100.com
A printer.finance.corp100.com
A fin1.finance.corp100.com
A fin2.finance.corp100.com
Managing DNS Data
You can control which clients access a view by through the use of a match list specifying IP addresses and/or TSIG
(transaction signature) keys. When the NIOS appliance receives a request from a client, it tries to match the source IP
address and/or TSIG key with its match list when determining which view, if any, the client can access. After the
appliance determines that a client can access a view, it checks the zone level settings to determine if it can provide
the service the client is requesting.
For information on TSIG keys or defining zone transfer settings, see Enabling Zone Transfers on page 426. For more
information on match lists, see Specifying Match Lists on page 341. For information on defining query settings, refer
to Specifying DNS Queries on page 428.
Figure 10.3 illustrates how the NIOS appliance resolves a query for a domain name in a zone of a view. In the example,
the internal view is listed before the external view. Therefore, when the appliance receives a query, it checks the
match list of the internal view first. When it does not find the source address in the match list of the internal view, it
checks the match list of the external view. The match list of the external view allows all IP addresses.
Next, the NIOS appliance checks the zone level settings to determine if it is allowed to resolve queries from the client
for domain names in that zone. After the appliance determines it is allowed to respond to queries from this client, it
resolves the query and sends back the response to the client.
Figure 10.3 Query Resolution
When you create more than one view, as shown in Figure 10.3, the order of the views is important. View order
determines the order in which the NIOS appliance checks the match lists. In Figure 10.3, the internal view is listed
before the external view. If the views were reversed, no hosts would receive DNS replies from the internal view
because the match list of the external view allows replies to clients with any IP address. For information on how to
order views, see Ordering Views on page 343.
In a grid, each grid member can host its own set of views. A grid member can serve as the primary or secondary server
for multiple views of a particular zone. For information about specifying primary and secondary servers, see
Configuring DNS Zone Services on page 434.
1
2
3
4
5
Client sends a query for
web1.corp100.com.
Client
The appliance
sends the answer
back to the client.
NIOS appliance checks if
the host IP address is
allowed in the match list of
the internal view. It does
not find the client address
in the match list
Internal View
External View
Match List
NIOS
Appliance
Match
Any
Match List
NIOS appliance checks if the
host IP address is allowed in
the match list of the external
view. The match list allows all
IP addresses.
NIOS appliance checks if it can respond to queries for
domain names in the corp100.com zone from this client.
It determines that it can. The appliance then looks for the
requested domain name in the corp100.com zone.
corp100.com
finance.corp100.com
cs.corp100.com
corp100.com
cs.corp100.com
Default View
The NIOS appliance provides one default view, with the ability to create multiple custom views. When you upgrade or
migrate from a name server, or an earlier version of software that does not support views, the appliance places all
the zones defined in the older release in the default view. You can then create additional views and organize the
zones in each view.
Note: Creating a network causes the appliance to create a reverse zone in the default view, if that reverse zone does
not exist in any other view. For information about creating a network, see Configuring a DHCP Network on page
461
The default view allows all IP addresses access, and has the same recursion setting as its associated member host.
You can rename the default view and modify its settings, but you cannot remove it.
Creating Views
You can create up to 255 views. This section decribes the process for creating and configuring new views.
If you have multiple views, you can order the views, as described in Ordering Views on page 343.
Once created, you can modify the view by:
Specifying Match Lists on page 341
Adding Zones to a View

on page 342
Adding Records to a Zone

on page 342
Configuring a View
When you configure a view, specify the following:
A match list specifying the hosts allowed access to the view
If you do not specify a match list, the appliance allows all hosts to access the view. For more information, see
Specifying Match Lists on page 341. Members of a grid cannot access each others view unless explicitly
allowed. To allow a primary server of a zone to receive dynamic DNS updates from grid members, you must add
the members to the match list when you configure a view.
Whether or not recursive queries are allowed

When a name server is authoritative for the zones in a view, you can disable recursion since your name server
should be able to respond to the queries without having to query other servers. If you allow recursion in a view,
you can use the match client list to provide the security that queries are only allowed from specified IP
addresses.
Note: This setting overrides the recursion setting at the grid and member levels.
For Match Clients, you specify IP addresses and network addresses allowed or denied access to the view. If you do
not make these specifications, the NIOS appliance allows all IP addresses access. You must also specify the IP
address of the management system you are using to connect to the appliance. For additional information, see
Specifying Match Lists on page 341.
For Match TSIG Clients, you specify the TSIG keys the NIOS appliance tries to match to determine whether or not a
host presenting a TSIG key is allowed access to the view. For additional information, see Defining the Match TSIG List
for an Existing View on page 341.
For Match Members, you must add the members to the Match Client List to allow a primary server of a zone to receive
dynamic DNS updates from grid members. Members in a grid cannot access each others view unless you explicitly
allow them.
Managing DNS Data
To configure a new view:
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Edit -> Add Infoblox View.
2. In the Add Infoblox View editor, click Infoblox View Properties, and specify the following:
Name: Enter the name of the view. It can be up to 64 characters long and can contain any combination of
printable characters.
Comment: Enter notes regarding the view.
Disable this view: Select this check box to disable this view.
Override member recursive query settings: Select this check box to override grid and member recursive
query settings with the settings specified for this view. If the query is recursive and the recursion option is
enabled, the appliance queries other servers for the DNS data it needs.
Allow recursion: Select this check box to enable recursion within the view. This setting overrides the
recursion setting at the grid and member levels.
3. To specify a Match Client list or Match TSIG clients, click Match Clients and do the following:
For Match Clients: Click Add, specify the following information, and then click OK:
IP Address: Enter an IP address for the match client.
Network: Enter a network IP address for the match client, and select a CIDR from the drop-down
list, which contains CIDR values from /1 to /32 for IPv4 addresses and /1 to /128 for IPv6
addresses.
Any: Select to allow or deny the local appliance to send zone transfers to any IP address.
Allow: Select to allow a match with the specified destination.
Deny: Select to deny a match with the specified destination.
Optionally, you can:
Modify client properties: Select the member from the list and click Modify.
Remove client: Select the member from the list and click Remove.
Move a client up the list: Select the member and click Move up. The member moves up the list
incrementally with each click of the button.
Move a client down the list: Select the member and click Move down. The member moves down the list
For Match TSIG Clients: Click Add, specify the following information, and then click OK.
Key name: Enter a meaningful name for the key, such as a zone name or the name of the remote
name server with which the local server authenticates zone transfer requests and replies. This
name must match the name of the same TSIG key on other name servers that use it to authenticate
zone transfers +with the local server.
Key: To use an existing TSIG key, type or paste the key in the Key field.
Generate: Click to create a new key.
Use DNS One 2.x TSIG: Select check box when the other name server is a NIOS appliance running
DNS One 2.x code.
Modify a TSIG key: Select the member from the list and click Modify.
Remove a TSIG key: Select the member from the list and click Remove.
Move a TSIG key up the list: Select the member and click Move up. The member moves up the list
Move a TSIG key down the list: Select the member and click Move down. The member moves down the
list incrementally with each click of the button.
Under Match Members, specify the following:
Match all grid members: Select check box to include all grid members in the address match list.
To include specific members only, select each member and click Add.
Optionally, you can select a member from the list and click Remove.
4. Click OK.
Specifying Match Lists
When you configure a view, you can create match lists to specify source IP addresses and TSIG keys that are allowed
or denied access to the view. The NIOS appliance determines which hosts can access a view by matching the source
IP address or TSIG key with its match lists of IP addresses and TSIG keys. After the appliance determines a host can
access a view, it checks the zone level settings to determine whether it can provide the service the host is requesting
for that zone. If you do not configure a match client list or a match TSIG list, all appliances are allowed access to the
view.
To add a match client list or match TSIG list to a new view, see Creating Views on page 339. The following tasks walk
you through modifying a view to add a match client list or match TSIG list.
Defining a Match Client List for an Existing View
To add a Match Client list to an existing view:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View editor, click Match Clients.
3. Click Add, and specify the following information:
IP Address: Enter an IP address for the match client.
Network: Enter a network IP address for the match client, and select a CIDR from the drop-down list, which
contains CIDR values from /1 to /32 for IPv4 addresses and /1 to /128 for IPv6 addresses.
Allow: Select to allow a match with the specified destination.
Deny: Select to deny a match with the specified destination.
Modify zone member properties: Select the member from the list and click Modify.
Remove a zone member: Select the member from the list and click Remove.
Move a zone member up the list: Select the member and click Move up. The member moves up the list
Move a zone member down the list: Select the member and click Move down. The member moves down the
list incrementally with each click of the button.
4. Click OK.
Defining the Match TSIG List for an Existing View
When an appliance tries to access a view with a TSIG key, the NIOS appliance tries to match the TSIG key with the TSIG
keys in this list. It allows an appliance to access the view only if the TSIG key that the appliance presents matches a
key on its list of allowed keys.
To add a Match TSIG list to an existing view:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View Properties editor, click Match Clients.
Managing DNS Data
3. In the Match TSIG Clients section, click Add, and specify the following information:
Key name: Enter a meaningful name for the key, such as a zone name or the name of the remote name
server with which the local server authenticates zone transfer requests and replies. This name must match
the name of the same TSIG key on other name servers that use it to authenticate zone transfers with the
local server.
Use DNS One 2.x TSIG: Select check box when the other name server is a NIOS appliance running DNS One
2.x code.
Modify a TSIG key: Select the member from the list and click Modify.
Move a TSIG key down the list: Select the member and click Move down. The member moves down the list
4. Click OK.
Adding Zones to a View
You can add both forward mapping or reverse mapping zones to a view.
To add a zone to a view:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Add Forward
Mapping Zone, Add IPv4 Reverse-Mapping Zone, or Add IPv6 Reverse-Mapping Zone, and select from the
following:
Authoritative: Delegates the NIOS appliance as an authoritative primary or secondary name server for the
zone.
Forward: Configures the NIOS appliance to forward queries for the zone to another name server that can
resolve the queries.
Stub: Configures the NIOS appliance to receive changes automatically to delegation information for a zone
for which another name server is authoritative.
2. Configure the zone. For information about configuring each type of zone, see Configuring Authoritative Zones on
page 353 and Creating an Authoritative Reverse-Mapping Zone on page 354.
Adding Records to a Zone
After adding a zone to a view, you can add hosts and records to the zone. For information about adding hosts, see
Adding Hosts on page 387. For information about adding records, see Adding Resource Records on page 394.
Copying Zone Records
Different views of the same zone may have a number of records in common. If this is the case, you can copy zone
records between views and zones.
Note: You cannot copy records that the NIOS appliance automatically creates, such as NS records and glue A records.
In addition, you cannot copy a host record that has a MAC address configured because the appliance does not
allow duplicate fixed addresses.
To copy zone records between views:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Copy
Zone Records.
2. In the Copy Zone Records dialog box, select the view and zone from the list, and then select a Copy Record Policy:
Copy All records: Copies all the zone records, including those records not created on the NIOS appliance,
such as HINFO records.
Copy only the following record types: Allows you to select the types of records to copy by clicking the
appropriate check boxes.
3. Click OK.
Ordering Views
The NIOS appliance can order the views automatically, or you can order the views manually. If you choose to have the
appliance automatically update the order of the views, it does so after each of the following events:
Adding a view to a member.
Removing a view from a member.
Changing the address match list of a view hosted by the member.
The NIOS appliance orders views based on the Match Client list for each view. If you decide to order the views
manually, the appliance displays a warning message after each of the previously listed events.
Note: Only superusers can change the order of the views.
To change the order of the views:
1. From the DNS perspective, click DNS Members-> + (for grid) -> grid_member -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Views.
3. Select one of the following:
Automatically order the views: Click this to automatically order views after adding a new view, removing a
view, or changing the match client list.
View Ordering: Select a view, and then click Move Up or Move Down to change its location in the list.
Understanding Views and IPv6 Addresses
NIOS appliances with both IPv4 and IPv6 enabled can contain both types of addresses in the match client lists. When
you enable IPv6 on the appliance, the ordering for DNS views in the GUI may be affected. Views are ordered and
sorted automatically based on match client lists. Views with IPv6 enabled are sorted as follows:
If the match client lists of all views contain IPv4 addresses onlyThe appliance orders views based on IPv4
addresses.
If the match client lists of all views contain IPv6 addresses onlyThe appliance orders views based on IPv6
addresses.
If the match client list of one view have IPv6 addresses and all other views have IPv4 addressesThe appliance
orders views based on IPv4 addresses, and the IPv6 address is given lowest priority in the ordering.
If the match client list of one view have IPv4 addresses and all other views have IPv6 addressesThe appliance
orders views based on IPv6 addresses, and the IPv4 address is given lowest priority in the ordering.
If the match client lists of one view have both IPv4 and IPv6 addressesThe appliance orders views based on
both IPv4 and IPv6 addresses, but more priority is given to the IPv4 addresses in the ordering.
Managing DNS Data
Managing Views
You can add, modify, disable, or remove any custom view. You can also modify and disable the default view, however,
under no circumstances can it be removed.
Modifying a View
To modify a view:
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View editor, modify the necessary properties. For a description of the fields, see Configuring a
View on page 339.
Disabling Views
Use this feature to temporarily block access to a view. Disabling a view excludes it from the named.conf file.
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> IB View Properties.
2. In the IB View editor, click IB View Properties.
3. Click Disable this view. A check mark appears to show the view is disabled.
Removing Views
You can remove all views, except the default view. When you remove a view, the NIOS appliance removes the forward
and reverse mappings of all the zones defined in the view.
To remove a view:
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Remove view.
2. Click Yes to confirm the delete request.
Managing Empty Recursive Views
When you create a view other than the default view, add a zone to it, and assign the zone to a grid member, the new
view and its zone appears in the member DNS configuration file.
If you enable recursion for a view and delete all zones in the view or unassign all zones under the view from the
member, the view still appears in the member DNS configuration file. Such a view is called an empty recursive view
because it does not contain any zones; it only serves recursive queries.
If you disable recursion for a view and delete all zones in the view or unassign all zones under the view from the
member, then the system removes the view from the member DNS configuration file.
You can delete or retain an empty recursive view from the DNS configuration file as follows:
1. From the Grid perspective, select + (for Members) -> + (for member_name) -> DNS -> Edit -> Service
Properties.
The Member DNS Properties editor appears.
2. Click General.
3. In the Possible views for members section, select the view that you want to change and click Modify.
The Select Member Address dialog box appears.
4. Deselect the Attach Empty Recursive View option and click OK.
Note: To retain an empty recursive view in the DNS configuration file, select the Attach Empty Recursive View option.
5. Click the Save and Restart icons.
Configuration Example: Configuring a View
In Figure 10.4, Member-A is a member of a grid. It is the primary name server for the corp100.com zone in the internal
view. It allows the IP address 11.0.0.1 and the 10.2.2.0/24 subnet access to DNS zone data in the internal view. At
the zone level, it allows transfers to an external secondary server, Infoblox-B, with an IP address of 11.0.0.1.
Infoblox-B is a secondary server for the corp100.com zone. The process follows these steps:
1. Creating an Internal View on Member-A
2. Adding a Zone to a View, a corp100.com zone to the internal view
3. Copying Records Between Views, from the corp100.com zone in the default view to the corp100.com zone
in the internal view
4. Verifying the Configuration
Figure 10.4 Configuring a View
Creating an Internal View
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Edit -> Add Infoblox View.
2. In the Add Infoblox View editor, click Infoblox View Properties.
3. Specify the following:
Name: internal
Comment: internal view
4. Click Match Clients, and in the Match Clients section, click Add.
5. Do the following for IP addresses 10.2.2.0/24:
Click Network.
Enter 10.2.2.0 in the IP address text field and select /24 in the CIDR drop-down menu.
Click Allow in the Permission section.
Click OK.
You will have 25 allowed client addresses in the Match Clients list when you are done.
zone corp100.com {
type slave;
masters {10.0.0.1; };
Master
Member-A 10.0.0.1
Primary Name Server
for corp100.com
Grid
View internal {
match clients {11.0.0.1; 10.2.2.0/24; };
zone corp100.com {
type master;
allow-query {10.2.2.0/24; };
allow-transfer {11.0.0.1; //auto added
Infoblox-B 11.0.0.1
External Secondary Name
Server for corp100.com
Managing DNS Data
Adding a Zone to a View
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
2. Click Authoritative Zone Properties, and enter the following in the Name field: corp100.com
3. Click Primary Server Assignment, click Select member.
4. Select the grid member displayed in the Select Grid Member dialog box and click OK.
5. Click Secondary Server Assignment, and in the Grid Secondaries section click Add.
6. Enter the following information, and then click OK:
Name: Member A
7. Click Secondary Server Assignment, and in the External Secondaries section click Add.
8. Enter the following information, and then click OK:
Name: InfobloxB
9. Click Queries, click Override member zone query settings, and then click Add.
10. In the Zone Query Access Item dialog, click Network, enter the following information, and then click OK:
Subnet mask (drop-down list): /8
This allows queries that the appliance answers from its internal view.
Copying Records Between Views
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for internal) -> + (for
Forward-Mapping Zones) -> zone -> Edit Copy Zone Records.
2. In the Copy Zone Records dialog, click Select Source.
3. In the Select Source Zone dialog, select default view -> Forward-Mapping Zones -> corp100.com.
4. In the Copy record policy section, select Copy all records, and then click OK.
The records from corp100.com in the default view are copied to corp100.com in the internal view.
Verifying the Configuration
1. In the DNS perspective, click DNS Members-> grid -> corp100_grid -> view -> DNS Configuration.
2. In the DNS Config File viewer, scroll through the contents of the file.
Verify that the internal view section is similar to the configuration file shown in Figure 10.4.
Understanding DNS for IPv6
Understanding DNS for IPv6
The NIOS appliance supports IPv6 (Internet Protocol version 6) addresses for the DNS services described in the
chapter. The following section discusses these topics:
IPv6 Overview on page 347
Configuring DNS for IPv6 Addressing on page 348
Configuring DNS for IPv6 Addressing on page 348
IPv6 Overview
The NIOS appliance supports both IPv4 and IPv6 versions of the Internet Protocol. This means that you can configure
DNS services to accommodate queries and responses for IPv4 addresses as well as IPv6 addresses. The appliance
utilizes authoritative forward-mapping zones containing AAAA records mapping host names to IPv6 addresses, as
well as authoritative reverse-mapping zones with PTR records mapping IPv6 addresses to host names.
Infoblox integrates IPv6 address management into many of the same places where IPv4 addresses are entered. Data
validation occurs on all IP fields and automatic validation is done to ensure proper entry of either an IPv4 address or
an IPv6 address.
Address Structures
IPv4 uses a 32-bit, 4-octet (each octet separated by decimals) addressing structure to designate sources and
destinations within a network. Since there are 32 bits that make up the address, IPv4 can support up to 4 billion
unique addresses.
An IPv6 address is a 128-bit number in colon hexadecimal notation. It consists of eight groups of four hexadecimal
digits separated by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef). Since there are 128 bits that
make up the address, IPv6 can support up to 3.4x10
38
unique addresses. The increase in the number of unique IPv6
addresses is one of the biggest advantages of an IPv6 implementation.
Figure 10.5 IPv6 Address Structure
The IPv6 address structure consists of the following:
Global Routing PrefixGlobal routing prefix is a (typically hierarchically-structured) value assigned to a site.
Subnet IDSubnet ID is an identifier of a link within the site.
Interface iDInterface Identifier. This portion of the address identifies the interface on the subnet. This is
equivalent to the host identifier for IPv4 addresses.
When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros. You can
also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note that if there
are multiple noncontiguous groups of zeros, the double colon can only be used for one group to avoid ambiguity. The
NIOS appliance displays an IPv6 address in its shortened form, regardless of its form when it was entered.
Global Routing Prefix Subnet ID Interface ID
n bits m bits 128-n-m bits
Network Prefix Interface ID
Managing DNS Data
The NIOS appliance supports the following DNS functions for IPv6:
AAAA recordsYou can import, serve queries, display, add, delete, and modify AAAA records on the appliance.
An AAAA record is equivalent to an IPv4 A record, relying upon a forward-mapping zone to map a hostname to
an IPv6 address. A single forward-mapping zone can map names to both IPv4 and IPv6 addresses. The
appliance autogenerates AAAA records for any of its interfaces that have IPv6 addresses.
ip6.arpa A specific domain for IPv6 is used for DNS reverse lookups called ip6.arpa. This domain maps an
IPv6 address to a hostname. When you specify an IPv6 network, the appliance automatically creates the
appropriate zone under ip6.arpa.
PTR recordsImport, serve queries, display, add, delete, and modify PTR records within an ip6.arpa reverse
zone. The PTR record returns a domain name corresponding to an IPv6 address contained in the ip6.arpa zone.
The appliance does not autogenerate PTR records; the user must configure PTR records manually.
DDNSThe appliance supports AAAA and PTR records for DDNS (Dynamic DNS).
For more information about DNS for IPv6, see RFC 3596, DNS Extensions to Support IP Version 6.
The NIOS appliance supports dual-mode IP implementation. DNS services can run on both IPv4 transport and IPv6
transport, implemented by configuring both an IPv4 address and an IPv6 address on the LAN (HA) interface for a grid
member. For information about configuring IPv6 on a grid member, see Enabling IPv6 On a Grid Member on page 304.
Configuring DNS for IPv6 Addressing
Configuring the appliance to manage DNS services for IPv6 connections are similar to configuring DNS services for
IPv4 connections. For simplicity, the IPv6 procedures are located in the same location as the corresponding
procedures for IPv4 in this chapter. In most cases, the key difference within the procedure involves selecting an IPv6
mapping zone instead of an IPv4 mapping zone. You can configure the following tasks:
Table 10.2 IPv6 DNS Configuration Checklist
Create primary or secondary name
servers and specify an IPv6 root server
Decide which type of IPv6 zone you want
to configure
Configure the IPv6 zone Importing Data into Zones on page 362
Applying Name Server Groups on page 378
Locking and Unlocking Zones on page 379
Removing Zones on page 380
Deleting Multiple Zones on page 382
Delegating Zone Authority to Name Servers
For information on configuring an IPv6 address on a grid member, see Enabling IPv6 On a Grid Member on page 304.
Forward-mapping zones answer name-to-address queries, and reverse-mapping zones answer address-to-name
queries. When you create an authoritative forward-mapping zone or reverse-mapping zone, you must define one or
more name servers as a primary server for that zone. A primary server contains editable zone data, which that server
can send to other (secondary) servers through zone transfers. You can also create one or more secondary name
servers for a zone. A secondary server for a zone receives read-only zone data from the primary server.
Note: The primary/secondary relationship between name servers is also called master/slave. You can enter,
modify, and remove zone data on the primary (or master) server, which can then send new and modified data
in a read-only form to the secondary (or slave) server. Both primary and secondary name servers are
authoritative for the zone data they serve. The distinction between them is how they get their zone data.
If a zone is part of an internal DNS structure for a private network, the inclusion of a secondary DNS server is optional,
though highly recommended. If a zone is part of an external DNS structure for a public network such as the Internet,
then a secondary server in a different subnet from the primary server is required. This requirement provides an
additional safeguard against localized network failures causing both primary and secondary name servers for a zone
to become inaccessible.
Specifying a Primary Server
Although a zone typically has just one primary name server, you can specify up to ten independent servers for a single
zone. When the primary server is a grid member, however, then only that member can be the primary server. The
ability to specify several primary servers allows you to enter the various IP addresses of a single multihomed server
and to specify multiple individual servers to provide appliance resiliency in case one becomes inaccessible.
A primary server can be in stealth mode, which means that its NS record is not published among the zone data, and
it does not respond to queries from resolvers and other name servers. Such a server is also called a hidden primary.
A hidden primary provides data to its secondary servers, which in turn respond to DNS queries using this data. One
of several advantages of this approach is that you can take the primary server offline for administrative or
maintenance reasons without causing a disruption to DNS service (within the expiration interval set for the validity
of its zone datathe default is 30 days).
To specify a primary server for a zone:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit ->
2. In the Authoritative Zone editor, click Primary Server Assignment.
Configure IPv6 resource records Adding AAAA Records on page 395
Modifying, Disabling, or Removing a Host or Record on page
408
Managing DNS Data
3. Choose from the following options:
Use External Primaries: Click this check box if the appliance is in a grid and you want to specify a primary
server outside the grid (external to the grid). Then click Add (if the appliance is not already deployed
independently from a grid), enter the following information, and click OK.
Name: Type a resolvable domain name for the external primary server.
IP Address: Type the IP address of the external primary server.
Use TSIG: To authenticate zone transfers between the local appliance and the external primary
server using a TSIG (transaction signature), select check box. Infoblox TSIGs use HMAC-MD5
hashes. These are keyed one-way hashes for message authentication codes using the Message
Digest 5 algorithm. For details, see RFC 1321, The MD5 Message-Digest Algorithm, and RFC 2104,
HMAC: Keyed-Hashing for Message Authentication.
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as
that of the TSIG key on the external primary server.
Key: Type or paste a previously generated key. This key must also be present on the external
primary server. You can generate a TSIG key, or obtain the TSIG key name and key from the external
name server, either by accessing the appliance yourself or by requesting the appliance
administrator to deliver them to you through some out-of-band mechanism. Then type or
copy-and-paste the name and key into the appropriate fields.
Use DNS One 2.x TSIG: If you want to use TSIG authentication and the external primary name server
is a NIOS appliance running DNS One 2.x code, select check box. The local appliance generates the
required TSIG key for authenticating DNS messages to and from appliances running DNS One 2.x
code. If the external primary name server is not running DNS One 2.x, clear check box.
Stealth: Click this check box to hide the grid external primary server from DNS queries. The NIOS
appliance does not create an NS record for the grid external primary server in the zone data.
Grid Primary Name: Click Select Member, choose a grid member from the list to be the primary name server,
and then click OK.
Stealth: Click this check box to hide the NS record for the primary name server from DNS queries. The NIOS
appliance does not create an NS record for the primary name server in the zone data. Select the check box again
to display the NS record for the primary name server in responses to queries.
4. Proceed to Specifying a Secondary Server. If you select a grid member (instead of external primaries) and assign
it as the primary server, then this step is optional.
Note: On the appliance you configure as a secondary server for a zone, you must associate a TSIG key for each
primary server to which the secondary server requests zone transfers. On the appliance you configure as a
primary server for a zone, you can set a TSIG key at the grid, member, or zone level. Because the secondary
server requests zone transfers, it must send a specific key in its requests to the primary server. Because the
primary server responds to the requests, it can have a set of TSIG keys from which it can draw when
responding. As long as the primary server can find the same TSIG key that the secondary sends it, it can verify
the authenticity of the requests it receives and authenticate the responses it sends.
Specifying a Secondary Server
A secondary name server is as authoritative for a zone as a primary server. Like a primary server, a secondary server
answers queries from resolvers and other name servers. The main difference between a secondary and primary server
is that a secondary server receives all its data from a primary server, or possibly from another secondary server that
forwards zone data it receives. The zone data passes from a primary to a secondary server (and possibly from that
secondary server on to another secondary server). This process is called a zone transfer.
The advantage of using primary and secondary name servers is that you enter and maintain zone data in one place
on the primary server. The data is then distributed to the one or more secondary servers.
To specify a secondary server for a zone:
2. In the Authoritative Zone editor, click Secondary Server Assignment.
3. Choose one of the following options:
Grid Secondaries: Selects the local appliance as the secondary server (or if the appliance is deployed in a
grid and you want to make a different member the secondary server). See Adding Grid Secondaries on page
351.
External Secondaries: Select this check box if the appliance is in a grid and you want to specify a secondary
server outside the grid (external to the grid), or if the appliance is deployed independently from a grid.
See Specifying External Secondaries on page 351.
Adding Grid Secondaries
In the Grid Secondaries section click Add, enter the following, and then click OK:
Grid Member Name: Click Select Member, choose a grid member from the list, and then click OK.
Stealth: Select this check box to hide the NS record for the secondary name server from DNS queries. The NIOS
appliance does not create an NS record for this name server in the zone data. Select the check box again to
display the NS record for the secondary name server in responses to queries. A secondary server in stealth
mode is also known as a hidden secondary.
For example, you can configure a hidden secondary when a secondary server is at a branch office with a slow
connection to the rest of corporate network. Configure local hosts at the branch office to send DNS queries to
the secondary server, but keep it hidden from other name servers on the rest of the network so that they do not
send it queries. Instead, they use a primary server located in a different part of the network that has faster
connection speeds.
Lead Secondary: When a primary server is external to a grid whose members are secondary servers, you can
select this check box to designate one member as a lead secondary. The primary server sends zone transfers to
the lead secondary, which distributes the zone data to the other secondary servers in the grid using zone
transfers (not the grid data replication mechanism). After you designate a grid member as a lead secondary for a
zone, you do not have to configure members to use the lead secondary server. All other grid members acting as
secondary servers for the zone automatically use the lead secondary to get zone data. Using a lead secondary
simplifies the addition, modification, and removal of other secondary servers in the grid. As long as the lead
secondary remains unchanged, you need not update intervening firewall policies or the external primary server
whenever you make changes to non-lead secondary grid members. This approach also reduces the amount of
traffic between primary and secondary servers.
Note: The Lead Secondary option only becomes available after you specify the primary name server as external.
Updates zones using grid replication (recommended): Select this checkbox to use grid replication to move zone
data from the primary to secondary servers.
Specifying External Secondaries
In the External Secondaries section click Add, enter the following, and then click OK:
Name: Enter a resolvable domain name for the external secondary server.
IP Address: Enter the IP address of the external secondary server.
Use TSIG: To authenticate zone transfers between the local appliance and the external secondary server using a
TSIG (transaction signature), select check box. Infoblox TSIGs use HMAC-MD5 hashes. These are keyed one-way
hashes for message authentication codes using the Message Digest 5 algorithm. For details, see RFC 1321, The
MD5 Message-Digest Algorithm, and RFC 2104, HMAC: Keyed-Hashing for Message Authentication.
Managing DNS Data
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as that of the
TSIG key for this zone on the external secondary server.
Key: Type or paste a previously generated key. On the external secondary server, this key must also be present
and associated with this zone. You can generate a TSIG key, or you can obtain the TSIG key name and key from
the external name server, either by accessing the appliance yourself or by requesting the appliance
administrator to deliver them to you through some out-of-band mechanism. Then, type or copy-and-paste the
name and key into the appropriate fields.
Use DNS One 2.x TSIG: Select this check box to use TSIG authentication and the external secondary name server
is a NIOS appliance running DNS One 2.x code. The local appliance generates the required TSIG key for
authenticating DNS messages to and from appliances running DNS One 2.x code. If the external secondary
server is not running DNS One 2.x, clear check box.
Stealth: Click this check box to hide the NS record for the secondary name server from DNS queries. The NIOS
appliance does not create an NS record for the secondary name server in the zone data. Select the check box
again to display the NS record for the secondary name server in responses to queries.
Note: On the appliance you configure as a secondary server for a zone, you must associate a TSIG key for each
primary server to which the secondary server requests zone transfers. On the appliance you configure as a
primary server for a zone, you can set a TSIG key at the grid, member, or zone level. Because the secondary
server requests zone transfers, it must send a specific key in its requests to the primary server. Because the
primary server responds to the requests, it can have a set of TSIG keys from which it can draw when
responding. As long as the primary server can find the same TSIG key that the secondary sends it, it can verify
the authenticity of the requests it receives and authenticate the responses it sends. Use NTP to synchronize
the time on both name servers that use TSIG-authenticated zone transfers.
Configuring Authoritative Zones
An authoritative zone is a zone for which the local (primary or secondary) server references its own data when
responding to queries. The local server is authoritative for the data in this zone and responds to queries for this data
without referencing another server.
There are two types of authoritative zones:
Forward-mapping An authoritative forward-mapping zone is an area of domain name space for which one or
more name servers have the responsibility to respond authoritatively to name-to-address queries.
Reverse-mapping A reverse-mapping zone is an area of network space for which one or more name servers
have the responsibility to respond to address-to-name queries.
When you add an authoritative forward-mapping zone and delegate responsibility for the zone to a primary name
server whose host name belongs to the name space of the zone, the NIOS appliance automatically generates an NS
(name server) record and an A (address) record for the name server. This type of A record is called a glue record
because it glues the NS record to the IP address (in the A record) of the name server.
The following sections explain how to create authoritative forward-mapping zones, reverse-mapping zones,
subzones, and a custom root zone:
Creating an Authoritative Forward-Mapping Zone
An authoritative forward-mapping zone is an area of domain name space for which one or more name servers have
the responsibility to respond authoritatively to name-to-address queries.
Note: A single forward-mapping zone can map names to both IPv4 and IPv6 addresses.
To create an authoritative forward-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
2. In the Add Forward Authoritative Zone editor, click Authoritative Zone Properties and specify the following:
Name: Enter the domain name for the zone. Omit the trailing period ( . ) that signifies the root zone.
Comment: Enter a descriptive comment about the zone.
Disable this zone: Click this check box to temporarily disable this zone.
Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
NS group: Select a name server from the drop-down menu.
3. Configure the following zone settings:
Specifying TTL Settings for a Zone on page 434
Allowing Zone Transfers for a Zone on page 436
Allowing Query Access for a Zone on page 437
Supporting Active Directory on page 438
Enabling the DNS Server to Receive Updates on page 552
Managing DNS Data
Creating an Authoritative Reverse-Mapping Zone
An authoritative reverse-mapping zone is an area of network space for which one or more name serversprimary and
secondaryhave the responsibility to respond to address-to-name queries. Infoblox supports reverse-mapping
zones for both IPv4 and IPv6 addresses.
Note: When you add an IPv4 reverse-mapping zone, the appliance automatically generates an in-addr.arpa space for
the network address that you specify. When you add an IPv6 reverse-mapping zone, the appliance
automatically generates an ip6.arpa space.
IPv4 Reverse-Mapping Zone
To add an IPv4 reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> IPv4
Reverse-Mapping Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, click Authoritative Zone Properties.
3. Specify the following zone information:
Network Address: Enter the IPv4 address for the address space for which you want to define the
reverse-mapping zone. An IPv4 address is a 32-bit number in dotted decimal notation. It consists of four
8-bit groups of decimal digits separated by decimal points (example: 192.168.1.2).
Subnet Mask: Select a netmask from the drop-down list to define the size of the subnet.
RFC 2317 Prefix: To use an RFC 2317 prefix, the netmask must be greater than 24 bits; 25- to 31-bit
netmask (255.255.255.128 255.255.255.252). For information, see Enabling an RFC 2317 Prefix.
NS Group: Select a group from the drop-down menu, to apply a previously defined name server group to
provide the primary and secondary name servers for this zone.
4. Configure the following zone settings as appropriate:
Specifying TTL Settings on page 424
IPv6 Reverse-Mapping Zone
To add an IPv6 reverse-mapping zone:
3. Enter the following zone information:
IPv6 Network Address: Enter the 128-bit IPv6 address for the address space for which you want to define
the reverse-mapping zone. The format of an IPv6 address is eight groups of up to four hexadecimal digits,
each group separated by a colon. Example: 2006:0000:0123:4567:89ab:cdef:0000:0123.
Note: When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros.
You can also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note
that if there are multiple noncontiguous groups of zeros, the double colon can only be used for one group
to avoid ambiguity. The NIOS appliance displays an IPv6 address in its shortened form, regardless of its
form when it was entered.
Network Prefix: Choose the network prefix that defines the IPv6 network address space.
provide the primary and secondary name servers for this zone.
4. Configure the following zone settings as appropriate:
Enabling an RFC 2317 Prefix
RFC 2317, Classless IN-ADDR.ARPA delegation is an IETF (Internet Engineering Task Force) document that describes a
method of delegating parts of the DNS IPv4 reverse-mapping tree that correspond to subnets smaller than 24 bits in
size (from 25 to 31 bits). The DNS IPv4 reverse-mapping tree has nodes broken at octet boundaries of IP addresses,
which correspond to the old classful network masks. So, IPv4 reverse-mapping zones (and delegation points) fall on
/8, /16, or /24 boundaries.
With the proliferation of CIDR (Classless Inter-Domain Routing) support for routing, ISPs no longer assign entire Class
C networks to customers that only need a handful of IPv4 addresses. In general, IPv4 address assignments no longer
fall on nice, classful boundaries. For DNS, a problem comes into play when an ISP gives a customer an address range
that is smaller than a Class C, but the customer also wants to be delegated the DNS reverse-mapping zone.
The NIOS appliance handles mapping a 24-bit network. If the ISP gives you, for example, a subnet with a 25-bit mask,
then you only have half of the Class C address range. If you configure your DNS server to be authoritative for the zone
corresponding to a 24-bit subnet, the DNS server cannot resolve half of the possible reverse-mapping records in the
zone. RFC 2317 defines an approach, considered a best practice, which addresses this issue.
Managing DNS Data
Note: Before enabling RFC 2317 support for zones, disable forwarders for the zone, especially when any sort of
delegation (including RFC 2317) is being used. If you do not, reverse lookups may fail. For more information,
contact Infoblox Support for the Tech Note on RFC 2317 delegation.
To enable RFC 2317 support:
3. Specify the following information:
Network Address: Enter the network IP Address for the address space for which you want to define the
reverse-mapping zone, and select a Subnet mask from the drop-down menu.
RFC 2317 Prefix: Enter a prefix in the text field. Prefixes can be alphanumeric characters, without blank
spaces.
provide the primary and secondary name servers for this zone. This option is for authoritative zones only.
4. For other zone configuration options, see Creating an Authoritative Reverse-Mapping Zone on page 354.
Adding an Authoritative Subzone
After creating a zone you can add more zones at the same level, or add subordinate zones (subzones). The subzones
can be authoritative, delegated, forward, or stub. For simplicity, the zones created in this section are authoritative (as
are all zones by default). For information about configuring the other zone types, see Configuring Delegated, Forward,
and Stub Zones on page 365.
You create an authoritative zone when you delegate authority for all the resource records of a particular domain to
one or more name servers. You create a subzone when you delegate authority for all the resource records of a
subdomain to name servers. The name servers can be the same as, or different from, the name servers that serve
resource records for the parent domain.
The distinction between domains and zones is that domains provide a logical structure to the DNS name space while
zones provide an administrative structure. The difference between domains and subdomains and zones and
subzones is that the terms subdomains and subzones reference their relationship to a parent domain or zone. With
the exception of the root domain and root zone, all domains are subdomains and all zones are subzones.
You can organize a domain based on logical divisions such as type (.com, .gov, .edu; or sales, eng, sup) or location
(.uk, .jp, .us; or hq, east, west). Figure 10.6 on page 357 shows one way to organize the external (public) name space
and the internal (private) name space for a corporation with the domain name corp100.com. The external name space
follows standard DNS conventions. Internally, you create an individual subdomain and corresponding subzone for
each department.
Figure 10.6 Domains and Subdomains, and Forward-Mapping Zones and Subzones
Note: Throughout this documentation, the trailing dot indicating the root zone is not shown, although its presence
is assumed.
For example, if you add subzones named engineering, hr, marketing, sales, and support subzones to a parent zone
named infoblox.com, the zone structure would be similar to the following illustration.
To add an authoritative subzone:
1. From the DNS perspective, click Infoblox Views -> view -> Forward-Mapping Zones -> zone -> Edit -> Add Forward
Mapping Zone -> Authoritative.
2. In the Add Authoritative Forward Zone editor, click Authoritative Zone Properties.
3. Enter a name for the zone.
com
.
corp100
sales eng sup
sales.corp100.com. eng.corp100.com. sup.corp100.com.
. =root domain
The DNS name space is logically
structured into domains and subdomains.
The DNS name space is administratively
structured into zones and subzones.
domain corp100
(subdomain of com)
top-level domain com
(subdomain of . )
sales, eng, and sup (subdomains of corp100 )
name server for
corp100.com ,
sales.corp100.com ,
and
eng.corp100.com
name server for
sup.corp100.com
com name server
. (root) name server
Subzones
Managing DNS Data
4. Define primary and secondary name servers. For more information, see Specifying a Primary Server on page 349
and Specifying a Secondary Server on page 350.
5. Repeat steps 1 through 4 to add other subzones under the same parent zone.
Note: To learn how to modify, remove, or disable a zone, refer to Managing Zones on page 379.
Creating a Root Zone
The NIOS appliance allows you to create an internal root zone for your organization. When the appliance receives a
query for DNS data that is not in its cache or authoritative data, it can query an internal root server after querying any
specified forwarders.
If the appliance does not receive a response from the forwarders, it sends the query to the specified internal root
name server. If you do not specify an internal root server and the appliance can access the Internet, it queries the
Internet root servers. For information on root name server, see Specifying Root Name Servers on page 430.
To create an internal root zone, enter a period (.) in the Name field. You must specify a host for the root zoneeither
a grid member or a DNS server that is external to the grid. Once created, the root zone automatically becomes the
parent of all the zones under the root zone.
To create a root zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
Zones -> Edit -> Add Forward-Mapping Zone -> Authoritative.
2. In the Add Authoritative Forward Zone editor, click Authoritative Zone Properties. Enter a period (.) in the Name
field, and enter a Comment to uniquely identify the zone.
3. Click Primary Server Assignment, and then click Select Member.
4. Select a grid member from the list (to be the primary name server), and then click OK.
If you have not yet added members to this grid, see Adding an HA Member on page 289 or Adding a Single
Member on page 288.
To specify an external primary name server, see Specifying a Primary Server on page 349.
Importing Zone Data
Importing Zone Data
Importing zone information alleviates having to manually enter data through the Infoblox GUI. You can import data
from existing name servers that run DNS implementations, as well as from NIOS appliances running 3.1r4 version
software or later. You can import existing zone data in the following ways:
Create a new zone
Modify an existing zone
The appliance imports the data through a zone transfer, so the name server you retrieve existing zone data from must
be authoritative for the zone data being imported. You must also configure the name server to allow zone transfers
to the IP address of the appliance to which the data will be imported. You can only import one zone (and its subzones)
at a time.
For the remainder of this section, the name server that stores the existing zone data (which is imported) is referred
to as the source name server (regardless of whether it is a third-party server or another NIOS appliance). The
appliance that receives the zone data is referred to as the destination appliance. The following illustration shows the
import zone data process.
Figure 10.7 Importing Zone Data Process
The source name server must allow zone transfers to the destination appliance. For this to happen, you must modify
the allow-transfer substatement to include the IP address of the destination appliance prior to importing the data.
This section does not address how to change BIND substatements, but does explain how to configure zone transfers
on a NIOS appliance running v3.1 software or later.
2
3
4
1
The source DNS server sends the
specified zone(s) data listed in the
zone file to the appliance.
The appliance sends a request to
import the specified zone data from
the source DNS server at 1.1.1.5.
Use the management system to
allow zone transfers on the source
DNS server to the NIOS appliance
IP address (10.1.1.5)
Management
System
(10.1.1.3)
Log in to the appliance and
specify the IP address of the
source DNS server when you
create or modify a zone.
Source DNS
Server
(1.1.1.5)
NIOS
Appliance
(10.1.1.5)
zone data
Login
Managing DNS Data
Zone data can be imported to both independent and grid deployed appliances. If the destination appliance(s)
consists of an HA pair (like a grid master) using the VIP (virtual IP) address shared by the HA pair. For an independent
appliance, use the IP address.
If the source server uses BIND views, and the destination appliance is running v3.2 software (with Infoblox views),
enter the IP or VIP of the destination appliance(s) in the Import Zone From field to add the imported zone to the
appropriate view. Otherwise, the appliance imports all zones to the default view.
Importing Data into a New Zone
When you create a new zone and import zone data, the zone you import retains all records except for the NS (and A
records matching that NS record) and SOA records. The NS and SOA records are auto-created when a destination
appliance is specified as the primary or secondary name server for the new zone. If the imported zone has extra NS
records, they are rewritten to specify the source server as an external secondary. For more information on how specific
zones and records are imported, see Table 10.2 on page 337.
The appliance only imports subzones directly under the zone being imported, and creates a delegated NS record for
those subzones (to the source name server). No other subzone records or second-level subzones are imported.
Figure 10.8 illustrates the process for adding records to a new zone.
Figure 10.8 Importing Zone Records
1.1.1.5
4
2
1
3

corp100.com

Authoritative
NS Record
ns1.corp100.com
A Record
10.34.22.088
Host Record
10.34.22.123
hq.corp100.com
Secondary
NS Record ns2.corp100.com

corp100.com

Authoritative
NS Record
Auto-created by z
A Record
10.34.22.088
Host Record
10.34.22.123
hq.corp100.com
Delegated

10.1.1.5
10.1.1.3
Appliance requests zone transfer
for corp100.com data...
...and the server sends back all
zone data for corp100.com (if the
source server allows transfers to
the IP address of the appliance).
Appliance imports the existing A,
CNAME, DNAME, SRV, TXT, MX,
PTR, host, and bulk host records
for corp100.com, but creates the
destination server NS and SOA records.
All subzone data under corp100.com,
like hq.corp100.com, are added as
delegated zones. Subzone records are
not imported.
Source
Name Server
corp100.com
zone data
Destination
Appliance
Management
System
Create a new
corp100.com zone
in GUI.
Enter the IP address of the source
server (1.1.1.5) where the
corp100.com zone data is stored.
Importing Zone Data
Importing Data into an Existing Zone
When you modify an existing zone on the destination appliance by importing zone data from a source server, the GUI
only retains the NS and SOA records automatically created when the zone was originally added. All DNS records on
the destination appliance, as well as host and bulk host records, for a zone are deleted and replaced by the imported
records of the same type. If there are no replicas, the destination appliance records are retained. If the imported zone
has extra NS records, those records change to designate the source server as an external secondary. For more
information on how specific zones and records are imported, refer to Table 10.2 on page 337.
The appliance imports first-level subzones, but delegates the subzones of the imported zone to the source name
server. The first-level subzone records are not imported. Second-level subzones, meaning subzones under another
subzone, are not imported. Figure 10.9 illustrates the process of zone data being added to an existing zone.
Figure 10.9 Importing Zone Data

corp200.com

Authoritative
NS Record old1.corp100.c
A Record 10.34.20.45
hq.corp200.com
Forwarder
sv.hq.corp200.com
Stub

1.1.1.5
4
2
1
3

corp200.com

Authoritative
NS Record ns1.corp100.com
A Record 10.34.20.45
hq.corp200.com
Delegated
IT.corp200.com
Secondary
10.1.1.5
10.1.1.3 Appliance requests zone transfer
for corp200.com data...
2nd-level and subsequent subzones
and their records are not imported.
Appliance replaces existing zone
data for corp200.com on the
appliance with the imported zone
data, but retains the destination
server NS and SOA records.
All subzone data under corp200.com,
like hq.corp200.com, are added as
delegated zones. Only first level
subzones are imported, but not their
records. All existing subzones that
are not duplicates of imported
subzones, like it.corp200.com,
remain as they originally were.
corp200.com
zone data
Destination
Appliance
Management
System
Source
Name Server
...and the server sends back all
zone data for corp200.com (if the
source server allows transfers to
the IP address of the appliance).
Modify the
corp200.com zone
in the GUI.
Enter the IP address of the
source server (1.1.1.5) where the
corp200.com zone data is stored.
Managing DNS Data
Allowing Zone Transfers to an Appliance
This section explains how to allow zone transfers to a NIOS appliance. If the source name server uses a BIND
implementation, refer to the OReilly
DNS and BIND (or other industry reference) book for information on how to
change the al l ow- t r ansf er substatements for the source name server.
Allowing Zone Transfers and Queries
Specifying zone transfers and queries allows the destination appliance access to the zone data being imported. This
procedure must be performed before attempting to import zone data to a destination appliance.
You can specify whether zone transfers are allowed to a single address or a network. The difference between the two
is simple: use an IP address to designate a single system, use the network option for a range of addresses on a
network.
To allow zone transfers and queries, perform the following steps on the source appliance:
1. From the DNS perspective, click the DNS Members tab -> + (for grid) -> member -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Zone Transfers.
3. Click the Override grid zone transfer settings check box.
4. Click Add and in the IP Address Option section do the following:
IP Address: Select and enter a system IP address.
Network: Select and enter a network IP Address and select a CIDR from the drop-down menu.
Any: Select this option to allow or deny zone transfers for any IP address.
5. Under Permission, select one of the following:
Allow: Select to allow zone transfers.
Deny: Select to restrict permissions for zone transfers.
6. Click OK.
Importing Data into Zones
After you create a new authoritative zone, you can import data from another server. When you import zone data into
an existing zone, the local appliance retains only the NS and SOA resource records for the zone and replaces all other
recordsA, PTR, MX, TXT, SRV, CNAME, DNAME, host, and bulk host. The local appliance also retains subzones and
records in the subzones that exist locally.
Note: When the local server successfully imports the zone data, a Confirmation message appears. If the local server
cannot import the zone data, an Error message appears, recommending that you verify the correctness of the
IP address of the remote server and zone information.
To import data into a zone:
2. In the Authoritative Zone Properties editor, click Settings.
3. Click the Import Zone from check box, and specify the following:
The IP address of the name server from which you want to import data.
Optional: Click the Automatically create Infoblox host records from A records check box.
Restoring Zone Data
How Specific Zones and Records Are Imported
The following table explains how a NIOS appliance imports each type of zone and record.
Table 10.3 The Resource Records and Subzones
If you import data directly from an authoritative zone or subzone, the destination server imports the resource records
for the imported zone. If you import data from a zone that contains an authoritative subzone, the destination server
imports the subzoneand redefines it as a delegated zonebut does not import the resource records for the
subzone. To import such records, change the imported subzone type from delegated to authoritative on the
destination server, and directly import the records for the zone.
Restoring Zone Data
After you import or delete a zone, if you want the original zone back, you can restore it using the Recycle Bin.
When you import a zone for the first time, the NIOS appliance saves the zone and its resource records as a single
object in the recycle bin. It keeps the subzones with the zone. See Restoring Zone Data After a Zone Import Example
on page 364.
When you reimport data into a zone, the software saves the zones, its resource records, and the delegated subzones
created by the previous import operation in the recycle bin. It keeps the subzones (not created during the zone
import) with the zone. See Restoring Zone Data After a Zone Reimport Example on page 364
If the zone import succeeds, the system adds resource records from the source to the target zone. It also adds
delegated subzones for the source subzones. If the zone import fails, the system does not create records and
delegated subzones. In either case, you can retrieve the original zone and its subzones from the recycle bin as
follows:
1. Delete the zone using the steps described in the section Removing Zones on page 380.
2. Select Remove zone only to remove the zone and its resource records. The NIOS appliance reparents all subzones
to the parent zone of the zone that you remove. Do not select Also remove all subzones.
Automatically created AD (Active Directory) subzones are an exception. Even if you select Remove zone only, the
NIOS appliance still removes AD subzones.
3. From the DNS perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
4. Select the zone you want to restore.
5. Click Edit -> Restore Selected Object. A warning message appears.
6. Click Yes.
The zone is restored back to its original state. The resource records are reparented back under it.
If the source name
server for
the imported
authoritative
zone is a:
then the destination name server imports the following:
authoritative
zone resource
records
authoritative, forward, or
delegated subzones redefined
as delegated subzones
stub subzone
subzone
resource
records
primary server,
secondary server,
Managing DNS Data
Restoring Zone Data After a Zone Import Example
In the example shown in Figure 10.10:
1. You import data from a source zone with subzones Sub x and Sub y into zone B with subzones Sub B1 and Sub
B2.
The appliance stores zone B and its resource records in the recycle bin.
To retrieve zone B after the import:
2. Delete subzone B using the Remove zone only option.
The appliance reparents subzones Sub B1 and Sub B2 to the Zone A, which is the zone above Zone B.
3. After the import, you can restore zone B from the recycle bin. The appliance reparents the subzones Sub B1 and
Sub B2 back to zone B.
Figure 10.10 Restoring Zones After a Zone Import
Restoring Zone Data After a Zone Reimport Example
In the example shown in Figure 10.11:
1. You reimport data from the source zone with subzones Sub x and Sub y into zone B with subzones Sub B1 and
Sub B2.
To retrieve zone B after the import:
2. Delete the delegated subzones x and y and then remove subzone B using the Remove zone only option.
The appliance stores zone B and its resource records and the previously-imported subzones Sub x and Sub y (as
delegated subzones) in the recycle bin. It reparents subzones Sub B1 and Sub B2 to the zone above zone B
(Zone A).
3. After the import, you can restore zone B and the subzones Sub x and Sub y from the recycle bin. The appliance
reparents the subzones Sub B1 and Sub B2 back to zone B.
1
2
3
Source Zone B
Zone B
Zone B
Zone A
You import
subzones x and y
to Zone B
To restore Zone B
after the import,
delete Zone B and
select the Remove
Zone only option.
Sub B1
Sub B2 Sub y
Sub x
Zone A
The appliance
reparents the
subzones B1 and B2
Restore Zone B
from the recycle bin.
The appliance
reparents subzones
B1 and B2 back to
Zone B.
The appliance saves
Zone B and its
resource records in the
recycle bin.
Configuring Delegated, Forward, and Stub Zones
Figure 10.11 Restoring Zones After a Zone Reimport
In addition to authoritative zones, the NIOS appliance allows you to configure delegated, forward, and stub zones. A
delegated zone is a zone managed by (delegated to) someone else, who owns the authority for the zone. A forward
zone is where queries are sent before being forwarded to primary name servers. A stub zone contains records that
identify the authoritative name servers in another zone. This section covers the following topics:
Configuring a Delegated Zone
Instead of a local name server, remote name servers (which the local server knows) maintain delegated zone data.
When the local name server receives a query for a delegated zone, it either responds with the NS record for the
delegated zone server (if recursion is disabled on the local server) or it queries the delegated zone server on behalf
of the resolver (if recursion is enabled).
For example, there is a remote office with their own name servers, and you want them to manage their own local data.
On the name server at the main corporate office, define the remote office zone as delegated, and then specify the
remote office name servers as authorities for the zone.
You can delegate a zone to one or more remote name servers, which are typically the authoritative primary and
secondary servers for the zone. If recursion is enabled on the local name server, it queries multiple delegated name
servers using a round-robin technique.
1
2
3
Source Zone B
Zone B
Zone A Zone A
Sub x
Sub y
Sub x
Sub y
Sub x
Sub y
Sub B1
Sub B2
Zone B
You import
subzones x and y
into Zone B.
To restore Zone B after
the import, delete the
delegated subzones x
and y under Zone B
and then remove Zone
B by selecting the
Remove Zone only
option.
The appliance
reparents the
subzones B1 and
B2 to Zone A.
The appliance saves
Zone B and the subzones
x and y from the previous
import (as delegated
zones) in the recycle bin.
Restore Zone B and
subzones x and y from
the recycle bin. The
appliance reparents its
subzones B1 and B2
back to Zone B.
Managing DNS Data
To create a delegated zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> + (for Forward-Mapping Zones, IPv4
Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add Forward Mapping Zone ->
Delegated.
2. In the Add Forward Mapping Delegated Zone editor, click Delegated Zone Properties.
3. Specify the following information:
Name: Enter the domain name of the delegated zone.
Note: You do not need to enter an FQDN (fully qualified domain name). The NIOS appliance appends the
delegated zone name to the name of its parent zone.
Comment: Enter a suitable comment.
4. Click Delegated Servers.
5. In the Delegated Servers editor, click Add, specify the following information, and then click OK:
Server Name: Enter the name of a remote name server to which you want the local server to redirect queries
for data for the zone.
Server Address: Enter the IP address of the delegated server.
6. Optional: Repeat the previous step to define multiple delegated servers.
You can define multiple delegated servers, such as the primary and secondary servers that serve DNS data for
that zone.
For information about modifying, removing, or disabling zones, refer to Managing Zones on page 379.
Configuring a Forward Zone
When you want to forward queries for data in a particular zone, define the zone as a forward zone and specify a name
server that can resolve queries for the zone. For example, define a forward zone so that the NIOS appliance forwards
queries about a partners internal site to a name server, which the partner hosts, configured just for other partners to
access.
Note: The use of a forward zone is different from that of a forwarder. (A forwarder is a name server that performs
recursive lookups on behalf of the name servers that forward queries to it. For more information, see Using
Forwarders with a Grid on page 432.) A NIOS appliance forwards queries to the name server of a forward zone
because the name server can resolve queries for the zone. A NIOS appliance forwards queries to a forwarder
regardless of zones.
To configure a forward zone for a forward-mapping zone:
Forward-Mapping Zones) -> zone -> Edit -> Add Forward-Mapping Zone -> Forward.
2. Enter the following information:
Forward Zone Properties
Name: Enter the domain name for which you want the NIOS appliance to forward queries.
Comment: Enter a descriptive comment.
Forwarders
For Forwarders, click Add, specify the following information, and then click OK.
Forwarder Name: Enter a domain name for the server to which you want the NIOS appliance to forward
queries for the specified domain name.
Forwarder Address: Enter the IP address of the server to which you want the NIOS appliance to forward
queries.
In the Forwarding Servers section, click Add, select the NIOS appliance from which you want to forward
queries, and then click OK. For an independent deployment, select the local appliance (it is the only
choice). For a grid, you can select one or more grid members.
To configure a forward zone for an IPv4 reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for IPv4
Reverse-Mapping Zones) -> zone -> Edit -> Add IPv4 Reverse-Mapping Zone -> Forward.
Network Address: Enter the 32-bit IPv4 address for which you want the NIOS appliance to forward queries.
Subnet Mask: Choose the subnet mask that defines the IPv4 network address space.
RFC 2317 Prefix: Use this field when the subnet mask is greater than 24 bits; for a mask between 25 and 31
bits. Enter a prefix, such as the name of the allocated address block. The prefix can be alphanumeric
characters, without blank spaces; for example: 128/26 , 128-189 , or sub-B . For more information, see
Enabling an RFC 2317 Prefix.
others from making conflicting changes.
Forwarders
For Forwarders, click Add, specify the following information, and then click OK:
Forwarder Name: Enter a domain name for the DNS server to which you want the NIOS appliance to
forward queries.
queries.
In the Forwarding Servers section, click Add, select the NIOS appliance that you want to forward queries for
the defined address space, and then click OK. For an independent deployment, select the local appliance
(it is the only choice). For a grid, you can select one or more grid members to forward queries.
To configure a forward zone for an IPv6 reverse-mapping zone:
Reverse-Mapping Zones) -> zone -> Edit -> Add IPv6 Reverse-Mapping Zone -> Forward.
IPv6 Network Address: Enter the 128-bit IPv6 address for which you want the NIOS appliance to forward all
queries. The format of an IPv6 address is eight groups of up to four hexadecimal digits, each group
separated by a colon. Example: 2006:0000:0123:4567:89ab:cdef:0000:0123.
Managing DNS Data
Forwarders
For Forwarders, click Add, specify the following information, and then click OK.
For Forwarders, click Add, specify the following information, and then click OK:
Forwarder Name: Enter a domain name for the DNS server to which you want the NIOS appliance to
forward queries.
queries.
In the Forwarding Servers section, click Add, select the NIOS appliance that you want to forward queries for
the defined address space, and then click OK. For an independent deployment, select the local appliance
(it is the only choice). For a grid, you can select one or more grid members to forward queries.
Configuring Stub Zones
A stub zone contains records that identify the authoritative name servers in the zone. It does not contain resource
records for resolving IP addresses to hosts in the zone. Instead, it contains the following records:
SOA (Start of Authority) record of the zone
NS (name server) records at the apex of the stub zone
A (Address) records that map the name servers to their IP addresses
Stub zones, like secondary zones, obtain their records from other name servers. Their records are read only;
therefore, administrators do not manually add, remove, or modify the records.
Stub zone records are also periodically refreshed, just like secondary zone records. However, secondary name
servers contain a complete copy of the zone data on the primary server. Therefore, zone transfers from a primary
server to a secondary server, or between secondary servers, can increase CPU usage and consume excessive
bandwidth. A name server hosting a stub zone maintains a much smaller set of records; therefore, updates are less
CPU intensive and consume less bandwidth.
When a name server hosting a stub zone receives a query for a domain name that it determines is in the stub zone,
the name server uses the records in the stub zone to locate the correct name server to query, eliminating the need to
query the root server.
Figure 10.12 and Figure 10.13 illustrate how the NIOS appliance resolves a query for a domain name for which it is
not authoritative. Figure 10.12 illustrates how the appliance resolves a query when it does not have a stub zone.
Figure 10.13 illustrates how the appliance resolves the query with a stub zone.
In Figure 10.12, a client sends a query for ftp.sales.corp200.com to the NIOS appliance. When the appliance receives
the request from the client, it checks if it has the data to resolve the query. If the appliance does not have the data,
it tries to locate the authoritative name server for the requested domain name. It sends nonrecursive queries to a root
name server and to the closest known name servers until it learns the correct authoritative name server to query.
Figure 10.12 Processing a Query without a Stub Zone
3
4
5
6
7
2 1
The appliance
responds to the
client with the
requested data
Client sends a query
for ftp.sales.corp200
.com to the NIOS
appliance.
The appliance sends a query
to a corp200.com server...
The appliance
determines it
does not have
the record to
resolve the
query.
The appliance sends a
query to a root server.
...which responds with a referral
to the .com servers.
NIOS appliance
Resource
Records
The appliance sends a query to
a sales.corp200.com server.
The appliance sends a query to
a .com server...
...which responds with a referral
to the corp200.com servers.
...which responds with a
referral to the
sales.corp200.com servers.
The sales.corp200.com server
checks its resource records
and responds with the
requested data.
Client
. (root)
.com
corp200.com
sales.corp200.com
Managing DNS Data
In Figure 10.13, when the NIOS appliance receives the request for the domain name in corp200.com, it determines it
does not have the resource records to resolve the query. It does, however, have a list of the authoritative name
servers in the stub zone, corp200.com. The appliance then sends a query directly to the name server in corp200.com.
Figure 10.13 Processing a Query with a Stub Zone
3
4
2 1
5 The appliance
responds to the
client with the
requested data.
Client sends query for
ftp.sales.corp200.com
The appliance send a query
directly to a corp200.com server...
The appliance
has a
corp200.com
stub zone.
NIOS Appliance
The appliance send a query to a
sales.corp200.com server.
... which respond with a referral to
the sales.corp200.com servers.
The sales.corp200.com
server checks its resource
records and responds with
the requested data.
Resource
Records
. (root)
corp200.com
sales.corp200.com
.com
Stub Zone
Configuration
Client
Stub zones facilitate name resolution and alleviate name server traffic in your network. For example, the client in the
previous examples is in corp100.com. The corp100.com and corp200.com zones are partners, and send all their
communications through a VPN tunnel, as shown in Figure 10.14 on page 371. The firewall protecting corp100.com
is configured to send all messages for the 10.2.2.0/24 network through the VPN tunnel. Infoblox_A hosts the stub
zone for corp200.com. Therefore, when the host in corp100.com sends a query for ftp.sales.corp200.com, Infoblox_A
obtains the IP address of Infoblox_B (10.2.2.7) from its stub zone records and sends the query to the firewall
protecting corp100.com.
Because the destination of the query is in the 10.2.2.0/24 network, the firewall (configured to encrypt all traffic to
the network) sends the request through a VPN tunnel to Infoblox_B. Infoblox_B resolves the query and sends back
the response through the VPN tunnel. All name server traffic went through the VPN tunnel to the internal servers,
bypassing the root servers and external name servers.
Figure 10.14 Stub Zone Configuration
In parent-child zone configurations, using stub zones also eases the administration of name servers in both zones.
For example, as shown in Figure 10.14, sales.corp200.com is a child zone of corp200.com. On the corp200.com
name servers, you can create either a delegated zone or a stub zone for sales.corp200.com.
When you create a delegated zone, you must first specify the name servers in the delegated zone and manually
maintain information about these name servers. For example, if the administrator in sales.corp200.com changes the
IP address of a name server or adds a new name server, the sales.corp100.com administrator must inform the
corp200.com administrator to make the corresponding changes in the delegated zone records.
If, instead, you create a stub zone for sales.corp200.com, you set up the stub zone records once, and updates are
then done automatically. The name servers in corp200.com that are hosting a stub zone for sales.corp200.com
automatically obtain updates of the authoritative name servers in the child zone.
In addition, a name server that hosts a stub zone can cache the responses it receives. Therefore, when it receives a
request for the same resource record, it can respond without querying another name server.
Creating Stub Zones
When you create a stub zone on the NIOS appliance, you specify the following:
The grid member that is hosting the stub zone
You can specify multiple appliances if you want the stub zones on multiple name servers. If you do, the
appliances store identical records about the stub zone.
The IP address of the primary server(s) that the NIOS appliance can query in the stub zone
The primary server can be a grid member or an external primary server. If you specify multiple primary servers,
the appliance queries the primary servers, starting with the first server on the list.
The primary server and the name server hosting the stub zone can belong to the same grid, as long as the
authoritative zone and the stub zone are in different Infoblox views. You cannot configure one zone as both
authoritative and stub in the same view.
Infoblox_A
10.1.1.3
Infoblox_B
10.2.2.7
Host
corp100.com corp200.com
sales.corp200.com
Managing DNS Data
After you create a stub zone, the NIOS appliance does the following:
1. It sends a query to the primary server for the SOA (Start of Authority) record of the stub zone.
The primary server returns the SOA record.
2. Then, it sends a query for the NS (name server) records in the zone.
The primary server returns the NS records and the A (address) records of the name servers. (These A records are
also called glue records.)
If the primary server is a NIOS appliance, you might have to manually create the A record and add it to the stub
zone. A NIOS appliance that is the primary server for a zone always creates an NS record, but does not always
create an A record.
The appliance automatically creates an A record when its host name belongs to the name space of the
zone. For example, if the zone is corp100.com and the primary server host name is server1.corp100.com,
the appliance automatically creates the NS and A records and sends these records when it is queried by the
stub zone name server.
The appliance does not automatically create an A record when its host name is in a name space that is
different from the zone. For example, if the zone is corp200.com and the primary server host name is
server1.corp100.com, then the appliance creates the NS record only and sends it when it is queried by the
stub zone name server. In this case, you must manually create the A record and add it to the zone by
navigating to the DNS perspective and clicking the Infoblox Views tab -> + (for Infoblox Views) -> + (for view )
-> + (for Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> A Record.
Maintaining Stub Zones
The NIOS appliance maintains the stub zone records and updates them based on the values in the SOA record as
follows:
The refresh interval indicates when the appliance sends a discrete query to the primary name server in the stub
zone. The appliance learns about any changes in the stub zone and updates the NS and A records in the stub
zone accordingly.
If the update fails, the retry interval indicates when the appliance resends a discrete query.
If the query continues to fail, the expiry value indicates when the appliance stops using the zone data.
Adding Stub Zones
To add a stub zone, you must identify the appliance that hosts the stub zone, and provide the IP address of the
primary server. You can configure a stub zone for forward mapping or reverse mapping zones.
To add a stub zone:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add
Forward-Mapping Zone, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones -> Stub.
2. In the Add Stub Zone editor, click Stub Zone Properties and enter the following information:
Name: Enter the name for the stub zone.
Comment: Enter a useful comment, such as the admin to contact for the stub zone.
3. Click Stub Server Assignment.
4. In the Stub Members section, click Add.
5. In the Stub Zone Member Server Item dialog select the grid member(s) hosting the stub zone, and then click OK.
6. In the Stub Primaries section, click Add.
7. In the Stub Primary Item dialog, enter the Name and IP Address of the primary server in the stub zone, and then
click OK.
If the primary server is a grid member, you must enter the host name and IP address of the grid member. The
NIOS appliance does not validate these entries. Therefore, if you change the IP address of a grid member listed
here, you must update the grid member information in this list as well.
You can specify multiple primary servers for redundancy. If the primary server is a NIOS appliance, the appliance
must have the Minimal Response feature disabled so it can propagate the data to the stub server. For
information about the Minimal Response feature, see Specifying Minimal Response Returns on page 432.
8. Optional: Click the Disable Forwarding check box to indicate that the name servers hosting the stub zone should
not forward queries that end with the domain name of the stub zone to any configured forwarders.
Viewing SOA Records
The timer values in the SOA record determine when the stub zone records are updated. A zone contains one SOA
record that accounts for the following properties for the zone:
Name of the primary DNS serverThe domain name for the primary DNS server for the zone. The zone should
contain a matching NS record.
E-mail address of the responsible personThe e-mail address of the person responsible for maintaining the
zone.
Serial numberThe number used by secondary DNS servers to check if the zone has changed. If the serial
number is higher than what the secondary server currently has, a zone transfer is initiated. This number is
automatically increased when changes are made to the zone or its record.
Refresh intervalThe time lapse between checks the secondary server makes for changes to the zone.
Retry intervalThe time lapse after which the secondary server checks for changes if the first refresh fails.
Expire intervalThe time period the zone remains valid after a successful refresh.
Minimum TTLThe default TTL for new records created within the zone.
To view zone SOA record values:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Authoritative
Zone Properties.
2. In the Forward Authoritative Zone editor, click Settings.
3. Click Override grid settings, and specify the following:
Refresh every: The interval at which the NIOS appliance sends a discrete query to the primary name server
in the stub zone.
Retry every: The interval at which the appliance retries sending a discrete query to the primary name server.
Expires after: Specifies when the appliance should stop using the zone data if it is unable to refresh the
data.
Default TTL: Specifies how long a name server can cache the record.
Negative TTL: Specifies how long a name server caches negative responses from the name servers that are
authoritative for the zone.
Set primary for SOA: Enter the primary server for the zone.
Increment serial number by: Click this check box and enter an incremental value in the text box that
appears. The Serial number option is disabled (grayed out) when this check box is selected.
Serial numbers: Enter serial numbers for the zone data file.
Email Address: Enter the e-mail address of the contact for the zone.
Import zone data from: To import data from another zone, click this check box and specify the following:
Enter the FQDN (fully qualified domain name) of a zone from which you want to import data.
Optional: Click the Automatic reverse mapping during import check box.
Disable forwarding: Click this check box to disable the forwarding function.
Managing DNS Data
Configuration Example: Configuring a Stub Zone in a Grid
This example illustrates how to configure a stub zone and assign it to a grid member. Figure 10.15, shows the items
you are configuring. You configure a grid, Corp100, with a single grid master and grid member. The grid member,
member1.corp100.com, is the primary name server for the corp100.com zone in the internal view. The grid master,
gm-corp100.com, hosts the stub zone for corp100.com in the external view. Thus, when the grid master, receives a
query for the corp100.com zone, it sends it directly to member1.corp100.com, the primary name server for the zone.
Figure 10.15 DNS Members Configuration
In this example, you configure the following:
1. Turn off minimal responses on member1.corp100.com, the primary name server for the corp100.com zone. See
Disable Minimal Responses.
2. Create the internal and external views. See Create the Views.
3. Create the corp100.com authoritative zone and stub zone. See Create the Zones.
Disable Minimal Responses
After you create the grid, turn off minimal responses for member1.corp100.com. Disabling minimal responses
ensures that member1.corp100.com propagates the required data to the server hosting the stub zone.
1. In the DNS perspective, click DNS Members -> + for Corp100 -> member1.corp100.com -> Edit -> Member DNS
Properties.
2. In the Member DNS Properties editor, expand the General section.
3. Clear the Return minimal responses check box.
Create the Views
Create the internal and external views. To create each view:
1. In the DNS perspective, click the Infoblox Views tab -> Infoblox Views > Edit > Add Infoblox View.
2. In the IB View editor, enter the name of the view. In this example, enter either External or Internal.
3. In the Match members section, click Match all grid members to allow queries from grid members.
Stub zone in the
external view.
Authoritative zone in
the internal view.
Grid member is the
primary name server.
Grid master hosts
the stub zone.
Create the Zones
Create the corp100.com zone in the internal view and assign member1.corp100.com as the grid primary server:
1. In the DNS perspective, click the Infoblox Views tab -> + for Infoblox Views -> + for internal view ->
Forward-Mapping Zones -> Edit -> Add Forward-Mapping Zone -> Authoritative.
2. In the Forward Authoritative Zone editor, do the following:
In the Authoritative Zone Properties section, enter the zone name, corp100.com.
In the Primary Server Assignment section, select member1.corp100.com as the grid primary server.
After you create the zone, you can view the NS and A records which were automatically created. Select the zone and
click View -> Records. The following figure displays the NS and A records for corp100.com:
Figure 10.16 Authoritative Zone
Create the stub zone, corp100.com, in the external view, assign gm-corp100.com as the stub member and
member1.corp100.com as the stub primary server.
1. In the DNS perspective, click the Infoblox Views tab -> + for Infoblox Views -> + for internal view ->
Forward-Mapping Zones -> Edit -> Add Forward-Mapping Zone -> Stub.
2. In the Stub Zone editor, do the following:
Expand the Stub Zone Properties section, and enter the name of the stub zone, corp100.com.
Expand the Stub Server Assignment section, and do the following:
Click Add for Stub Members. In the Stub Zone Member Server Item dialog box, select gm-corp100.com
and click OK.
Click Add for Stub Primaries. In the Stub Primary Item dialog box, enter the following for the primary
name server, and click OK:
Name: member1.corp100.com
Address: 10.35.0.222
After you create the stub zone, the server hosting the stub zone, gm-corp100.com, sends queries to the primary
server, member1.corp100.com, for the SOA and NS records. member1.corp100.com then returns its NS records and
A (address) records. The following figure displays the NS and A records in the stub zone.
Figure 10.17 Stub Zone
Managing DNS Data
Using Name Server Groups
A name server group is a collection of one primary DNS server and one or more secondary DNS servers. Grouping a
commonly used set of primary and secondary DNS servers together simplifies zone creation by enabling you to
specify a single name server group instead of specifying multiple name servers individually.
Note: Only superusers can create and manage name server groups.
Creating Name Server Groups
To create a name server group:
1. From the DNS perspective, click the DNS Members tab -> member -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Name Server Groups.
3. In the Name Server Groups section, click Add, enter the following information, and then click OK:
Name Server Group Name: Type a name that provides a meaningful reference for this set of servers.
Grid Primary: To create a name server group for a grid with the primary name server as a member of the grid,
click Select Member, choose the member from the Select Grid Member dialog list, and then click OK.
Stealth: To hide the NS record for the primary name server from DNS queries, select this check box. The
NIOS appliance does not create an NS record for the primary name server in the zone data. To display the
NS record for the primary name server in responses to queries, clear the check box.
Use external primaries: If you are not using a grid or you want the primary name server to be an appliance
outside a grid, select Use external primaries, click Add, specify the following information, and click OK:
Name: Type the FQDN (fully qualified domain name) of the primary name server.
IP Address: Type the IP address of the name server. If the external primary name server is behind a NAT
appliance, use the NAT address, not its interface address.
Use TSIG: To authenticate zone transfers using a TSIG (transaction signature), select check box.
Infoblox TSIGs use HMAC-MD5 hashes. These are keyed one-way hashes for message authentication
codes using the Message Digest 5 algorithm. For details, see RFC 1321, The MD5 Message-Digest
Algorithm, and RFC 2104, HMAC: Keyed-Hashing for Message Authentication.
that of the TSIG key on other DNS appliances with which you intend to send and receive
TSIG-authenticated messages
Key: Type or paste a previously generated key. This key must be present on other DNS appliances
with which you intend to send and receive TSIG-authenticated messages.
You can generate a TSIG key in the TSIG Key dialog box (accessed from the Zone Transfers section), or
you can obtain the TSIG key name and key from the external name server, either by accessing the
appliance yourself or by requesting the appliance administrator to deliver them to you through some
out-of-band mechanism. Then type or copy-and-paste the name and key into these fields.
To send DNS messages without TSIG authentication, clear the Use TSIG check box.
Use DNS One 2.x TSIG: If you want to use TSIG authentication and the external primary name server is
running DNS One 2.x code, select check box. The NIOS appliance generates the required TSIG key to
use when authenticating DNS messages to and from appliances running DNS One 2.x code. If the
external primary name server is not running DNS One 2.x, clear the check box.
Stealth: To hide the NS record for the primary name server from DNS queries, select this check box. The
NIOS appliance does not create an NS record for the primary name server in the zone data. To display
the NS record for the primary name server in responses to queries, clear the check box.
Grid Secondaries: If you are creating a name server group for a grid and you want to use a grid member as a
secondary name server, click Add, enter the following information in the Name Server Group Member
Secondary dialog box, and click OK.
Using Name Server Groups
Click Select member, select a member from the list in the Select Grid Member dialog box, and click OK.
Stealth: To hide the NS record for the secondary name server from DNS queries, select this check box.
The NIOS appliance does not create an NS record for the secondary name server in the zone data. To
display the NS record for the secondary name server in responses to queries, clear the check box.
Lead Secondary: Select if the primary name server is outside the grid, and you want the chosen
secondary name server to forward zone transfers it receives from the primary to other secondary name
servers, which can be either inside the grid or outside it.
Update zones usingSelect one of the following options:
Grid replication (recommended): Select this check box if the primary and secondary servers are
grid members and they use database replication for zone updates.
DNS zone transfers: Select this check box if the primary and secondary servers use zone transfers
for zone updates.
External Secondaries: If you are not using a grid or you want to add a secondary name server that is not part
of a grid, click Add, specify the following, and then click OK:
Name: Type the FQDN (Fully Qualified Domain Name) of the secondary name server.
IP Address: Type in the IP Address for the secondary name server.
Use TSIG: To authenticate zone transfers using a TSIG (transaction signature), select this check box.
Infoblox TSIGs use HMAC-MD5 hashes. These are keyed one-way hashes for message authentication
codes using the Message Digest 5 algorithm. For details, see RFC 1321, The MD5 Message-Digest
Algorithm, and RFC 2104, HMAC: Keyed-Hashing for Message Authentication.
that of the TSIG key on other DNS appliances with which you intend to send and receive
TSIG-authenticated messages.
Key: Type or paste a previously generated key. This key must be present on other DNS servers with
which you intend to send and receive TSIG-authenticated messages.
You can generate a TSIG key in the TSIG Key dialog box (accessed from the Zone Transfers section), or
you can obtain the TSIG key name and key from the external name server, either by accessing the
appliance yourself or by requesting the appliance administrator to deliver them to you through some
out-of-band mechanism; then type or copy-and-paste the name and key into these fields.
To send DNS messages without TSIG authentication, clear the Use TSIG check box.
Use DNS One 2.x TSIG: If you want to use TSIG authentication and the external secondary name server
is running DNS One 2.x code, select this check box. The NIOS appliance generates the required TSIG
key to use when authenticating DNS messages to and from appliances running DNS One 2.x code. If the
external primary name server is not running DNS One 2.x, clear the check box.
Stealth: Click this check box to hide the NS record for the secondary name server from DNS queries. The
NIOS appliance does not create an NS record for the secondary name server in the zone data. To
display the NS record for the secondary name server in responses to queries, clear check box.
4. Click the Save icon to apply the new name server group configuration. A newly created name server group
appears in the Default Name Server Group drop-down list (in the Grid DNS Properties editor) only after you save
the configuration.
5. From the Default Name Server Group drop-down menu, select a name server group to be the default.
Managing DNS Data
Applying Name Server Groups
To specify a name server group when creating a forward-mapping zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> Forward-Mapping Zones -> Edit -> Add Forward
Mapping Zone -> Authoritative.
2. In the Add Forward Authoritative Zone editor, specify the following:
Name: Enter the name of the forward-mapping zone.
Comment: Enter a meaningful comment.
NS Group: Select the group of name servers that you want to serve DNS for this zone.
To specify a name server group when creating an IPv4 reverse-mapping zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> IPv4 Reverse-Mapping Zones -> Edit -> Add IPv4
Reverse-Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, specify the following:
Network Address: Enter the 32-bit IPv4 address for the reverse-mapping zone.
Subnet Mask: Choose the subnet mask that defines the IPv4 network address space.
RFC 2317 Prefix: Use this field when the subnet mask is greater than 24 bits; for a mask between 25 and 31
bits. Enter a prefix, such as the name of the allocated address block. The prefix can be alphanumeric
characters, without blank spaces; for example: 128/26 , 128-189 , or sub-B . For more information, see
Enabling an RFC 2317 Prefix.
NS Group: From the drop-down list, select the previously defined name server group that you want to serve
DNS for this zone.
To specify a name server group when creating an IPv6 reverse-mapping zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> IPv6 Reverse-Mapping Zones -> Edit -> Add IPv6
Reverse-Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, specify the following:
IPv6 Network Address: Enter the 128-bit IPv6 address for the reverse-mapping zone.
NS Group: Select the previously defined name server group that you want to serve DNS for this zone.
Note: If you apply a name server group to at least one zone or specify it as the default group, you cannot rename or
remove it. To rename or remove a group, you must first disassociate it from all zones and unassign it as the
default group.
Managing Zones
Managing Zones
The following sections describe how to edit, delete, enable, disable, lock, and unlock zones after you create them.
Locking and Unlocking Zones
Modifying Zones
Removing Zones
Locking and Unlocking Zones
Administrators can lock a zone before changing its properties or records so that other administrators cannot make
conflicting changes. Administrators can select a zone, lock it, make changes, and then unlock it.
If you lock a zone and other administrators try to make changes to it, then the system displays a warning message
that the zone is locked by admin_name.
You can perform dynamic updates through mechanisms such as DDNS and nsupdate on a locked zone. The system
can also add auto-generated records such as glue A records and NS records to a locked zone. Locks on a zone do not
impact its child zones.
To lock a zone:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) zone -> Edit -> Lock
Zone.
You can also lock a zone using the zone editor as follows:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit
Properties.
2. In the Edit Zone Properties dialog box, select the check box Lock this zone.
A lock icon appears on the left panel next to the zone.
Only a superuser or the administrator who locked the zone can unlock it. Locks do not expire; you must manually
unlock a locked zone.
To unlock a zone:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) zone -> Edit ->
Unlock Zone.
You can also unlock a zone using the zone editor as follows:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit
Properties.
2. In the Edit Zone Properties dialog box, deselect the check box Lock this zone.
A lock icon on the left panel next to the zone disappears indicating that the zone is unlocked.
Managing DNS Data
Modifying Zones
The NIOS appliance allows you to modify existing zone settings. The one item you cannot change is the name.
To change the zone settings:
1. From the DNS perspective, click Infoblox Views -> view -> Forward Mapping Zone or Reverse Mapping Zone -> zone
-> Edit -> Authoritative Zone Properties.
2. Click Settings, and make the necessary changes.
3. Make other changes, as necessary. For more information, see Configuring Delegated, Forward, and Stub Zones
on page 365.
Removing Zones
When you remove a zone, the NIOS appliance removes the zone from the database, along with all resource records
in the zone. If a zone has subzones, you can choose to remove them and their resource records or reparent them
to the parent zone of the one you are removing. These two options are shown in Figure 10.18.
Figure 10.18 Removing or Reparenting Subzones
If you choose to reparent the subzones, be aware of the following caveats and possible effects of the reparenting:
You cannot remove a zone and reparent its subzones if at least one of the subzones is a delegated zone. You
must first remove any delegated subzones, and then you can remove the zone and reparent its subzones.
If there are AD (Active Directory) subzones (_msdcs, _sites, _tcp, _udp, domaindnszones, foresetdnszones) and
you opt to remove the parent zone only, the NIOS appliance reparents all subzones except the AD subzones,
which it removes regardless of the removal option you specify.
The subzone reparenting option is unavailable when you select multiple zones for removal.
When you remove a zone and reparent its subzones, any subzone that inherited its admin access settings from
its previous parent zone (as opposed to having specific access settings for the subzone) now receive their
settings from its new parent zone, which might be different. See Figure 10.19.
Zone B
Subzone C
Zone B
Subzone C
Remove Zone B and remove its subzones. reparent its subzones. or
The NIOS appliance removes zone B,
subzone C, and all their resource
records.
The NIOS appliance removes zone B and
its resource records. It reparents subzone
C to zone A. It creates a new NS record in
zone A for subzone C and possibly
changes admin privileges for subzone C.
Zone A Zone A Zone A
Zone B
Subzone C
Managing Zones
Figure 10.19 Changed Admin Access Settings after Reparenting Subzones
Note: Instead of removing a zone, you can also disable it. For more information, refer to Enabling and Disabling
Zones on page 382.
To remove a zone:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Remove zone.
2. In the Confirm Delete Request dialog, enter the following:
Remove Zone: Select the check box to confirm the removal of the zone.
Note: Because of the potentially large loss of data that can occur when you remove a zone, by default the
Infoblox appliance requires a double confirmation of its removal. To change the default behavior so that
a zone removal does not require you to confirm its removal twice, in the DNS perspective click the DNS
Members tab -> grid -> Edit -> Grid DNS Properties -> General, clear the Enable double confirm for zone
deletion check box, and then click the Save icon.
Also remove all subzones: Select to remove the selected zone all its subzones and all the resource records
of the selected zone and its subzones.
Remove zone only: Select to remove the zone and its resource records. The Infoblox appliance reparents all
subzones to the parent zone of the zone that you remove. Automatically created AD (Active Directory)
subzones are an exception. Even if you select Remove zone only, the Infoblox appliance still removes AD
subzones.
3. Click OK.
Zone B
Deny
Subzone C
Inherits Deny
If you remove Zone B and reparent its subzones
Zone A
Read/Write
Zone A
Read/Write
Zone B
Deny
Subzone C
Inherits
Read/Write
the admin access settings for subzone C change because the privileges for its new parent
zone (zone A) are different from those of its previous parent zone (zone B).
Before you remove zone B, subzone C inherits a Deny admin access setting from zone B.
After the removal, subzone C inherits Read/Write access from its new parent zone, zone A.
Note that if you set a specific Deny admin access privilege for subzone C before removing its
parent zone (zone B), subzone C retains its specified Deny setting.
Managing DNS Data
Deleting Multiple Zones
Instead of deleting zones individually, you can select multiple zones and delete the entire selected group.
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones).
2. Select the zones you want to remove in one of the following ways:
Select a contiguous set of zones, holding down the SHIFT key and clicking the zones.
Select noncontiguous zones, holding down the CTRL key and clicking the zones.
Note: You cannot remove the first reverse mapping zone. If the first reverse mapping zone is one of your
selections, the Remove menu option is grayed out and unavailable.
3. Click Edit -> Remove Multiple.
A removal confirmation message appears.
4. To confirm the removal of the selected zones, select Remove all the selected items, and click OK.
Enabling and Disabling Zones
The NIOS appliance allows you to disable and enable existing zones, providing a viable option for removing them
from the database. This feature is especially helpful when you have to move or repair the server for a particular zone.
When you disable a zone, a red square appears next to the network listing in the tree view.
To disable a zone:
2. In the Forward (or Reverse) Authoritative Zone editor, click Disable. A check mark appears.
You can use the recycle bin feature on the NIOS appliance to store deleted DNS configurations. Items contained in
the recycle bin can be restored to active configuration at a later time, or can be permanently removed from the
appliance database. If you do not use the recycle bin, the appliance deletes items permanently from the database.
The recycle bin is enabled by default on the NIOS appliance.
You can use the recycle bin to restore DNS views and zones. NIOS does not support restoring deleted DNS resource
records.
You can display the Recycle Bin panel and view all deleted items stored in the recycle bin. From the DNS perspective,
all deleted DNS items are shown if you have superuser privilege. If you are not a superuser, only the items deleted by
you are shown. By default, records are sorted by Name. To display the Recycle Bin panel and to view the deleted items
for DNS stored in the recycle bin:
3. Click Edit -> Restore Selected Object.
A warning message appears.
4. Click Yes.
The item is restored to its original location in the GUI; it does not appear in the Recycle Bin panel any longer.
You can empty the recycle bin, permanently removing all of the items displayed in the Recycle Bin panel from the
appliance database. The empty functionality is available only if the recycle bin is enabled, and only to superusers. To
empty the recycle bin:
2. Click Edit -> Empty Recycle Bin.
A warning message appears.
3. Click Yes.
All items are removed from the Recycle Bin panel.
Managing DNS Data
Specifying Host Name Restrictions
Use the host name restriction feature to enforce a naming policy for the host names of A, AAAA, Host, MX, and NS
records based on user-defined or default patterns.
Records that you created before you enabled the host name checking policy, need not comply with the host name
restriction that you specify.
You can select one of three preconfigured policies or define your own host naming policy with a POSIX regular
expression. The policies Infoblox provides implement standard host naming restrictions according to RFC 952, DOD
Internet Host Table Specification, and RFC 1123, Requirements for Internet Hosts -- Application and Support.
Note: The host name restriction limits the host name of A, AAAA, Host, MX, and NS records only.
You can specify (and override) host name restrictions at the grid, member, and zone level.
Grid Level
To specify host name restrictions for a grid:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Host Name Restrictions.
The Record Policies section lists the following default record policies:
Allow Any: You can use any host name.
Allow Underscore: You can only use host names with alphanumeric characters, dashes, and underscores
("-" and "_")
Strict Hostname Checking: You can only use host names that contain alphanumeric characters and dashes
(-).
3. Click Add to define your own host name checking policy. The Record Template dialog box appears. Enter a record
policy name and a regular expression string, and click OK. See Appendix B, "Regular Expressions", on page 693
for definitions of regular expressions.
The software does not validate the regular expressions that you enter. You can even specify an invalid regular
expression that might cause noncompliant errors when you create records.
You can only define your own host name restriction policy at the grid level. At the member level and at the zone
level, you can only select a policy.
Use the drop-down menu in the Host Name Restriction Policy section to select one of the following host name
checking policies: Allow Any, Allow Underscore, Strict Host Name Checking, or a user-defined policy. This sets
the policy for all the zones in the grid.
Apply Policy to dynamic updates and inbound zone transfers (required Strict Host Name Checking): If you
select the Strict Host Name Checking policy, this option is enabled by default. It enables the appliance to
apply the policy to dynamic DNS updates and zone transfers that it receives. You can then select which
action the appliance takes when it encounters names that do not conform to the policy. Select either Fail or
Warn. If you select Warn, the appliance allows the dynamic DNS update or zone transfer, but logs a syslog
message.
After you specify a host name restriction policy, if you create a record name that does not comply with this policy and
try to save it by clicking the Save icon, an error message appears.
Specifying Host Name Restrictions
Member Level
To configure the host name restriction policy for an individual member:
1. From the DNS perspective, click the DNS Members tab -> member -> Edit -> Member DNS Properties.
2. In the Edit Zone Properties dialog box, click Host Name Restrictions.
3. Click the Override grid host name restriction policy check box to override the grid host name restriction policy,
and specify the settings for this member. If you choose the override option, then you must select a host name
policy from the Host Name Restriction Policy drop-down menu.
Apply Policy to dynamic updates and inbound zone transfers (required Strict Host Name Checking): If you
select the Strict Host Name Checking policy, this option is enabled by default. It enables the appliance to
apply the policy to dynamic DNS updates and zone transfers that it receives. You can then select which
action the appliance takes when it encounters names that do not conform to the policy. Select either Fail or
Warn. If you select Warn, the appliance allows the dynamic DNS update or zone transfer, but logs a syslog
message.
5. In the Host Name Restriction Policy section, select one of the following host name checking policies or a
user-defined policy:
Allow Underscore: You can only use host names with alphanumeric characters and underscores ("-" and
"_")
(-).
Zone Level
To configure the host name restriction policy for an authoritative forward-mapping zone:
Forward-Mapping Zones) -> zone -> Edit Properties.
You can only specify host name restrictions for authoritative forward-mapping zones. You cannot specify host
name restrictions for forward zones, stub zones, IPv4 reverse-mapping zones, and IPv6 reverse mapping zones.
2. In the Edit Zone Properties dialog box, click Host Name Restrictions.
3. Click the Override grid host name restriction policy check box to override the grid host name restriction policy,
and specify the settings for this zone. If you choose the override option, you must select a host name policy from
the Host Name Restriction Policy drop-down menu.
4. Use the drop-down menu in the Host Name Restriction Policy section to select one of the following host name
checking policies or a user-defined policy:
("-" and "_")
(-).
For example, if you create a zone myAuthZone and specify the host name restriction to be Strict Hostname Checking
and then you add an A record to myAuthZone and enter corp_100 as the domain name, the following error message
appears:
RR name cor p_100 does not compl y wi t h pol i cy St r i ct Host name Checki ng
To resolve this error, change the domain name to corp100.
Managing DNS Data
Obtaining a List of Invalid Record Names
To get a list of all record names that do not comply with the host name checking policy, from the DNS perspective,
click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for Forward-Mapping Zones) -> zone -> Host
Name Compliant Report.
The Host Name Compliance Report appears. It lists the record name, type, value, and comment for all existing records
that do not comply with the host name restriction policy defined (at the grid, member, or zone level). You can
right-click a record name and edit it to make it compliant or delete it.
Adding Hosts
Adding Hosts
After adding zones, you are ready to add hosts and records for the zones. You can choose to add a bulk host, that
assigns a range of addresses to a set of hosts. While adding a host, you can choose to add an alias (CNAME record)
for the host.
A host record defines attributes for a node, such as the name-to-address and address-to-name mapping. This
alleviates having to specify an A record and a PTR record separately for the same node. A host can also define aliases
and DHCP fixed address nodes.
You must first create a zone before you can add a host record for the zone. For more information, see Adding an
Authoritative Subzone on page 356 To create a host record, you need to know the host name and one or more IP
addresses.
Note: The hosts in a zone can be located on different networks.
To add a host:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add
Resource Records -> Host.
2. In the Add Host editor, click Host Record Properties, and specify the following information:
In the Name field, enter a unique name for the host. For example, you might enter BigWin for the sales
organization host system. For A, AAAA, Host, MX, and NS records in the forward-mapping zones, ensure that
the name you enter complies with the host name restriction policy defined for the zone. If you create a
record name that does not comply with this policy and you try to save it by clicking the Save icon, an error
message appears.
Configure for DNS: Select this check box to enable DNS for this host. Click Select zone... to select the DNS
zone in the Select Forward Mapping Zone dialog. If you clear this check box, the appliance disables the
Select zone... button, the Aliases section, and the Time to Live Settings editor.
Note: The Configure for DNS check box and the Select zone... button appear only if you are adding a host using
the DHCP and IPAN perspective.
In the Comment field, enter a distinguishing comment.
Click Disable this host to temporarily disable the host.
3. In the IP Address section, click Add, enter the following information in the Host Address dialog box, and then click
OK.
IP Address: Enter the IP address of the host.
Configure for DHCP: Select this check box if you want DHCP to serve this host.
Note: When you select this check box, the appliance enables the following input fields.
Match On
MAC Address: Select this to assign the IP address to a host, provided that the MAC address of the
requesting host matches the MAC address that you specify here.
None (reserved): Select this to reserve this particular IP address for future use, or if the IP address is
statically configured on a system (the Infoblox server does not assign the address from a DHCP
request).
MAC Address: Enter a MAC address (such as the MAC address for a DHCP fixed address) for the host. You
must enter an IP address, however, entering the MAC address is optional. The MAC Address field defines a
fixed address for a DHCP host. For more information on fixed address host, see Adding Hosts on page 387.
NetBIOS Name: Enter the NetBIOS name for this IP address.
OS: Enter the operating system for this IP address.
Managing DNS Data
Last Discovered: The timestamp of the last discovery.
Override network domain name: Click this check box and enter a Domain Name in the text field.
Override network broadcast address: Click this check box and enter a Broadcast Address in the text field.
Override network routers: Click this check box, enter an IP Address in the text field, and click Add.
Override network DNS servers: Click this check box, enter an IP Address in the text field, and click Add.
Override network lease time: Click this check box and specify a new Lease Time in Days, Hours, Minutes,
and Seconds.
Override network PXE lease time setting: Click this check box, then click Enable PXE Lease Time, and
specify a new lease time in Days, Hours, Minutes, and Seconds.
Override network custom options: Click this check box, click Add Option, click Select Option, select an
option from the list and click OK, enter a value and click OK.
Override network BOOTP options: Click this check box and specify the following information:
Boot File name
Next Server name
Boot Server name
Override network Deny BOOTP request: Click this check box and select the Deny BOOTP request check box
that follows.
Override option list request: Click this check box and select the Ignore option list requested by client and
return all defined options check box that follows.
4. In the Aliases section, click Add, enter a fully qualified domain name (a CNAME record for the host), and then
click OK.
5. Click Time to Live Settings to set the time to live (TTL) for this record. The default is to use the zone TTL settings.
To specify other settings, click Override zone TTL settings, and enter the settings in Days, Hours, Mins, Secs. For
more information on TTL settings, see Specifying Time To Live Settings on page 407.
6. Click IPAM Device Info, and then enter the following:
Device Type: Choose the appliance type for this host from the drop-down list.
Device Labels: Type relevant information in the various fields. It is not necessary to enter information in
every field. Only use the ones that you want. The first four fields are predefined: Location, Owner,
Manufacturer, and Model. The remaining fields are titled Custom1 Custom20 by default. You can define
your own set of labels for these fields (see Classifying an IPAM Device on page 558).
Adding Bulk Hosts
Adding Bulk Hosts
If you need to add a large number of hosts, you can have the NIOS appliance add them as a group and automatically
assign host names based on a range of IP addresses and the host name format you specify. Such a group of hosts is
called a bulk host, which the appliance manages and displays as a single bulk host.
Specifying Bulk Host Name Formats
Bulk host name formats provide a flexible way to define bulk host names. You create multiple bulk host formats at
the grid level. Either select from the default bulk host formats or create your own. You can specify a different format
for each bulk host. When you assign a bulk host name format to a bulk host in a zone, the system applies the zones
host name policy to it.
A bulk host name consists of a prefix, a suffix, and the name of the domain to which the host belongs. Except a period,
the prefix can contain any printable character that complies with the zone host name policy. The suffix is derived from
an IP address in the bulk host IP address range.
The suffix format is a string of ASCII characters that uses $ (unpadded) or # (zero-padded) followed by 1,2,3,4 to refer
to the first, second, third, or fourth IP address octet; it uses $1,$2,$3,$4 or #1,#2,#3,#4. $2 refers to the second
unpadded octet and #4 refers to the fourth zero-padded octet.
For example:
The prefix of a bulk host = info
IP address = 213.19.32.133
Domain name = infoblox.com.
If you specify the default four-octet format -$1-$2-$3-$4, the bulk host name is info-213-19-23-133.infoblox.com.
If you specify a custom name format such as *#1*#2*#3*#4, the bulk host name is
info*213*019*023*133.infoblox.com.
Before Defining Bulk Host Name Formats
Before you specify a bulk host name format, ensure that it complies with the following rules:
The NIOS appliance uses the name space bulk-xx-xx-xx-xx for bulk hosts, so you should not use this name for
CNAMEs, DNAMEs, or host name aliases because it causes conflicts.
When you add a bulk host, if you enable the Automatically add reverse mapping option and there is a CNAME
record in the corresponding reverse zone that conflicts with a PTR record generated by the bulk host, the bulk
host insertion fails and an error message appears. For example, if there is a CNAME with the alias 15 in a
reverse zone 1.168.192.in-addr.arpa and if you add a bulk host foo/192.168.1.10/192.168.1.20 with the
Automatically add reverse mapping option selected, the insertion fails and an error message appears because
both the bulk host and the CNAME generate a record 15.1.168.192.in-addr.arpa in the reverse zone.
You cannot create or change a bulk host if a zone is locked by another user. If you select a different template for
the grid, it changes each record associated with the bulk host.
You can define bulk host name formats only at the grid level and override them at the bulk host level; not at the
zone or bulk host object level.
During an upgrade, the system migrates existing bulk hosts to NIOS 4.2r1 version. Note:
If you did not customize the bulk host IP format, there is no action required. All migrated bulk hosts
continue to use the grid-level default four-octet format -$1-$2-$3-$4. See Specifying Bulk Host Name
Formats on page 389.
If you customized the bulk host IP format, the system creates a new template called Migrated Default
template. All migrated bulk hosts override the grid-level default template and use the Migrated Default
template.
Managing DNS Data
Note: The NIOS appliance considers two bulk hosts that have the same prefix, start address, and end address as
duplicate hosts; even if they use different bulk host formats.
Bulk Host Name Format Rules
Table 10.4 describes the rules that you should follow when you create bulk host name formats. It also provides
examples of valid and invalid formats for each rule.
Table 10.4 Bulk Host Name Format Rules and Examples
Rule Example
The suffix format cannot have more
than four octets.
-$4-$5 is invalid.
The octets must be in order. -$2-$3-$4 is valid but -$3-$2-$4 is invalid.
Do not skip octets. -$2-$3-$4 is valid but -$2-$4 is invalid.
Do not use a combination of both the
$ and # symbols together as octet
references; use only one of them.
-$2-#3-$4 is invalid.
The suffix format must contain at least
the fourth octet. You must define at
least one -$4 or -#4.
-$4 is valid but -$3 is invalid.
The suffix format must not start with
the $ character.
$4 is invalid.
If the suffix format uses $ references,
it cannot be preceded by a digit. You
must add a non-digit prefix to each $
or # reference. You cannot use a
period (.) as a prefix.
-$2-$3-$4
The \ character is the designated
escape character for the $, # and \
characters.
You cannot use the $ or # symbols as
separators unless you prefix them
with an escape character \.
For the IP address 213.19.32.133, the format \#-#1-#2-#3-#4
expands to #213019032133.
The bulk host name format must
comply with its zone host name policy.
You cannot insert a bulk host name format -?-$4 in a zone that uses
Allow Underscore as host name policy because the policy does not
allows you to use the ? character in the host name.
The bulk host name must comply with
the maximum label length.
The sum of the bulk host name prefix and suffix cannot be longer than
63 characters. When you enter a suffix format, the NIOS appliance
determines the length of the longest bulk host defined, and checks
that the sum of the bulk host prefix and suffix length does not exceed
63 characters; if it exceeds, an error message appears.
The bulk host name cannot result in
FQDN longer than 255 characters.
Adding Bulk Hosts
To specify bulk host name formats:
2. Click Host Name Restrictions in the Grid DNS Properties editor.
The Bulk Host Name Formats section displays the four default name suffix formats. The following example
shows the host name that each format generates for the zone test.com:
Four Octets: $1-$2-$3-$4 (Default)Generates foo-192-168-1-15.test.com
One Octet: -$4Generates foo-15.test.com
Three Octets: -$2-$3-$4Generates foo-168-1-15.test.com
Two Octets: -$3-$4Generates foo-1-15.test.com
For the IP address 10.100.0.10, the format -$1-$2-$3-$4 generates the host name suffix -10-100-0-10. The
format #1-#2-#3-#4 generates the host name suffix -010-100-000-010.
3. Click Add to specify a bulk host name format name and define the format in the Bulk Host Name Format dialog.
The format you define appears on the list of Name Formats. You can also select format and click Modify to
change the format name and definition in the Bulk Host Name Format dialog, or click Delete to remove the
format from the list.
4. Optional. Select the Default Bulk Host Name Format from the drop-down list if you want to change the grid default
bulk host name format to the format you specified in step 3.
Configuring Bulk Hosts
To add a bulk host:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> Bulk Host.
2. Click Bulk Host Properties in the Add Bulk Host editor.
3. In the Prefix field, enter a name (or series of characters) to insert at the beginning of each host name. Except a
period, you can enter any printable character that complies with the zone host name policy.
The NIOS appliance computes the
maximum length of the bulk host
suffix by expanding the bulk host IP
format using 255.255.255.255.
For the format string -$1-$2-$3-$4, the maximum length of the suffix
is -255-255-255-255 that is 16 characters. Therefore, the maximum
length of the host prefix is 47 characters.
The bulk host name must not be the
same as a CNAME/DNAME.
If there is a CNAME record with alias foo-003-015, you cannot insert a
bulk host foo/1.2.3.10/1.2.3.20 using template -#3-#4 because
foo-003-015 is also one of the synthetic host names in the bulk host.
Each host name in the bulk host must
be unique.
You cannot insert a bulk host foo/1.2.3.10/1.2.4.20 using the
template -$4 because the system resolves the host name foo-10 to
both 1.2.3.10 and 1.2.4.10. To ensure that the bulk host name is
unique, use the template -$3-$4.
You cannot insert a bulk host that
violates the uniqueness of two bulk
hosts that have the same prefix and
use the same name format.
If there is a bulk host foo/1.2.3.10/1.2.4.20 using the template
-$3-$4, you cannot insert another bulk host foo/1.3.4.10/1.3.5.20
using the same template because the system resolves host name
foo-4-15 to both 1.2.4.15 and 1.3.4.15. Instead, use the template
-$2-$3-$4 to ensure that the two bulk hosts are unique.
Table 10.4 Bulk Host Name Format Rules and Examples
Rule Example
Managing DNS Data
The sum of the bulk host prefix length and suffix length must not exceed 63 characters. When you enter a prefix,
the NIOS appliance computes the maximum length of the bulk host suffix to verify that the total prefix and suffix
length does not exceed 63 characters. If it does, the appliance displays an error message indicating the number
of characters that you must remove to make a valid prefix.
4. Enter the first IP address in the range of addresses for the group in the Starting IP Address field
5. Enter the last IP address in the range of addresses for the group in the Ending IP Address field.
6. To override the default four-octet suffix format and specify a different format, click Override grid bulk host name
format and select a host name format from the Name Formats drop-down menu.
The Name Formats drop-down menu lists the formats Four Octets, Three Octets, Two Octets, and One Octet
along with any other bulk host name formats that you have defined. See Specifying Bulk Host Name Formats on
page 389.
7. Enter a text string in the Comment field to help identify this record.
8. Click Automatically Add Reverse Mapping to have the appliance automatically add the reverse mapping address.
9. Click Disable this Bulk Host to disable the host.
10. Click Time to Live Settings to set the time to live (TTL) for this record. The default is to use the zone TTL settings.
To specify other settings, click Override zone TTL settings, and enter the settings in Days, Hours, Mins, Secs. For
more information on TTL settings, see Specifying Time To Live Settings on page 407.
Example 1 - Responding to DNS AXFR Queries
This example shows the responses the bulk host foo/1.2.3.10/1.2.3.20 returns to DNS AXFR (Asynchronous Full
Transfer Zone) queries.
If the bulk host uses the template -$3-$4, the query returns:
f oo- 3- 10. t est . com
. . . . . .
If the bulk host uses the template -#2-#3-#4, the query returns:
f oo- 002- 003- 010. t est . com
f oo- 002- 003- 011. t est . com
. . . . . .
f oo- 002- 003- 020. t est . com
Example 2 - Importing Zones for Bulk Hosts
When you import zones for bulk hosts, the system selects the most specific match.
The following example can possibly match three octet, two octet, and one octet formats; however, the system selects
the most specific four octet default format.
The query:
f oo- 1- 2- 3- 4I N A 1. 2. 3. 4
f oo- 1- 2- 3- 5I N A 1. 2. 3. 5
Results in the match:
f oo/ 1. 2. 3. 4/ 1. 2. 3. 5( Four Oct et s)
Not in any of the following:
f oo- 1/ 1. 2. 3. 4/ 1. 2. 3. 5( Thr ee Oct et s)
f oo- 1- 2/ 1. 2. 3. 4/ 1. 2. 3. 5( Two Oct et s)
f oo- 1- 2- 3/ 1. 2. 3. 4/ 1. 2. 3. 5( One Oct et )
Associating Shared Record Groups With Zones
Shared records are groups of DNS Resource Records that you can assign to one or more zones. Use shared records to
create and update multiple resource records shared by different zones. You can only create shared records in a shared
record group and assign the group to one ore more zones. The zones handle the shared records as any other resource
record.
See Chapter 11, Shared Records, on page 411 for information on shared record groups.
To link a shared record group to forward-mapping authoritative zones using the zone editor:
Forward-Mapping Zones) -> Add Forward Mapping Zone -> Authoritative.
2. Click the Shared Record Groups section in the Add Forward Authoritative Zone editor.
3. Click Add.
The Shared Record Groups defined appear.
4. Click a group that you want to add to the zone and click OK.
The shared record group appears in the editor.
Managing DNS Data
Adding Resource Records
After adding zones you can add resource records to those zones and hosts, with the option of disabling any record.
When you disable a record, the NIOS appliance does not answer queries for it, nor does it include disabled records
in zone transfers and zone imports. The appliance still displays disabled records in the GUI, marked with red to
indicate a disabled state.
The NIOS appliance allows you to create the following types of records:
Address (A)
Pointer (PTR)
Service location (SRV)
Mail exchanger (MX)
Text (TXT)
Canonical name (CNAME)
DNAME
The NIOS appliance also allows you to specify time-to-live (TTL) settings for each record. If you do not specify a TTL
for a record, the appliance applies the default TTL value of the zone to each record. +
This section covers the following topics:
Adding A Records on page 394
Adding A Records
An A (address) record maps a domain name to an IPv4 address. To define a specific name-to-address mapping, add
an A record to a previously defined authoritative forward-mapping zone (see Creating an Authoritative
Forward-Mapping Zone on page 353).
To add an A record:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> A Record.
2. Enter the following A Record Properties:
Domain Name: Enter a host name that you want to map to an IP address. The name you enter is prefixed to
the zone name. For example, if the zone name is corp100.com and you enter www , its full name becomes
www.corp100.com .
Infoblox also supports wildcard A records. A wildcard A record maps all names for which there is no specific
A record in a domain to a single IP address. For example, you can use a wildcard A record to map all names
in the corp100.com domain to the IP address of a public-facing web server. The NIOS appliance responds to
queries for names such as www1.corp100.com, ftp.corp100.com, main.corp100.com, and so on to the
same IP address. If there are also A records for specific names in the corp100.com domain, the NIOS
appliance first matches queries for those names to their records. However, if a query arrives for a name for
which a specific A record does not exist, the NIOS appliance can then use the wildcard card to map the
name to a default address. To make a wildcard A record, enter an asterisk ( * ) in the Domain name field.
Ensure that the domain name you enter complies with the host name restriction policy defined for the zone.
If you create a record name that does not comply with this policy and you try to save it by clicking the Save
icon, a Save Error message appears.
IP Address: Enter the IPv4 address to which you want the domain name to map. An IPv4 address is a 32-bit
number in dotted decimal notation. It consists of four 8-bit groups of decimal digits separated by decimal
points (example: 192.168.1.2).
Comment: Enter a descriptive comment for this record.
Disable this A record: Clear the check box to enable the record. Select the check box to disable it.
3. Click Time to Live Settings, and select the Override zone TTL settings check box to override the settings inherited
from the zone and configure TTL settings for this record. Enter the settings in the Days, Hours, Mins, and Secs
fields. For more information on TTL settings, see Specifying Time To Live Settings on page 407.
4. Click IPAM Data, and then enter the following:
MAC Address: Enter the MAC address for this IP address.
NetBIOS Name: Enter the NetBIOS Name for this IP Address.
OS: Enter the OS for this IP address.
Last Discovered: The last discovered timestamp.
Adding NS Records
An NS record identifies the authoritative DNS server for a domain. NS records associate with one or more IP addresses
used for related A record and PTR record generation. You can configure an NS record for anycast IP addresses on the
appliance. For more information about anycast, see Anycast Addressing on page 452.
To add an NS(A) record:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> NS Record.
NS Record Properties
Zone: Display the DNS zone name for the NS record.
Name: Display the name for the NS record.
View: Display the Infoblox view for the NS record.
Name Server: Enter the host name you want to configure as the name server for the zone .
2. Enter the following associated IP addresses
IP addresses associated with NS record: Click Add. In the IP Address dialog box, do the following and click
OK:
IP Address: Enter the IP address for the NS record.
Automatically create corresponding PTR record: Click the check box to enable autogeneration of PTR
records for the IP address.
Adding AAAA Records
An AAAA (quad A address) record maps a domain name to an IPv6 address. To define a specific name-to-address
mapping, add an AAAA record to a previously defined authoritative forward-mapping zone (see Creating an
Authoritative Forward-Mapping Zone on page 353).
To add an AAAA record:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> AAAA Record.
Managing DNS Data
2. Enter the following AAAA Record Properties:
Domain Name: Enter a host name that you want to map to an IP address. The name you enter is prefixed to
the zone name. For example, if the zone name is corp100.com and you enter www , its full name becomes
www.corp100.com .
Infoblox also supports wildcard AAAA records. A wildcard AAAA record maps all names for which there is no
specific AAAA record in a domain to a single IP address. For example, you can use a wildcard AAAA record to
map all names in the int.corp100.com domain to the IPv6 address of an internal web server. The NIOS
appliance responds to queries for names such as www1.int.corp100.com, home.int.corp100.com,
main.int.corp100.com, and so on to the same address. If there are also AAAA records for specific names in
the int.corp100.com domain, the NIOS appliance first matches queries for those names to their records.
However, if a query arrives for a name for which a specific AAAA record does not exist, the NIOS appliance
can then use the wildcard card to map the name to a default address. To make a wildcard AAAA record,
enter an asterisk ( * ) in the Domain name field.
Ensure that the host name you enter complies with the host name restriction policy defined for the zone. If
you create a record name that does not comply with this policy and you try to save it by clicking the Save
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note
that if there are multiple noncontiguous groups of zeros, the double colon can only be used for one group
to avoid ambiguity. The NIOS appliance displays an IPv6 address in its shortened form, regardless of its
form when it was entered.
Disable this AAAA record: Clear the check box to enable the record. Select the check box to disable it.
3. Select the Override zone TTL settings check box to override the settings inherited from the zone and configure
TTL settings for this record. Enter the settings in the Days, Hours, Mins, and Secs fields. For more information on
TTL settings, see Specifying Time To Live Settings on page 407.
Adding PTR Records
A PTR (pointer) record maps an address to a host name, and can only be added for a reverse mapping zone. If you
have not already done so, you must first create a reverse mapping zone before adding a PTR record for the zone. For
more information, see Creating an Authoritative Forward-Mapping Zone on page 353. To create a PTR record, you
need to specify a domain name and host name.
Note: You must configure PTR records manually for IPv6 addresses. Unlike IPv4 PTR records, IPv6 PTR records are not
autogenerated.
To add an IPv4 or IPv6 PTR record:
Reverse-Mapping Zones or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add Resource Records -> PTR Record.
2. Enter the following PTR Record Properties:
IP Address: Enter the IPv4 or IPv6 address that you want to map to a domain name.
An IPv4 address is a 32-bit number in dotted decimal notation. It consists of four 8-bit groups of decimal
digits separated by decimal points (example: 192.168.1.2).
An IPv6 address is a 128-bit number in colon hexadecimal notation. It consists of eight 16-bit groups of
hexadecimal digits separated by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
Host Name: Enter the host name to which you want the PTR record to point (example: www.corp100.com).
Disable this PTR record: Clear the check box to enable the record. Select the check box to disable it.
3. Click Time to Live Settings, and select the Override zone TTL settings check box to override the settings inherited
from the zone and configure TTL settings for this record. Enter the settings in the Days, Hours, Mins, and Secs
fields. For more information on TTL settings, see Specifying Time To Live Settings on page 407.
4. Click IPAM Data, and then enter the following:
MAC Address: Enter the MAC address for this IP address.
NetBIOS Name: Enter the NetBIOS Name for this IP Address.
OS: Enter the OS for this IP address.
Last Discovered: The last discovered timestamp.
Adding MX Records
An MX (mail exchanger) record maps a domain name to a mail exchanger. A mail exchanger is a server that either
delivers or forwards mail. You can specify one or more mail exchangers for a zone, as well as the priority for using
each mail exchanger. A standard MX record applies to a particular domain or subdomain. A wildcard MX record
applies to a domain and all its subdomains. See Figure 10.20.
Figure 10.20 MX Records
Note: You must also create an A record for the host defined as a mail exchanger in an MX record.
corp100.com
site1.corp100.com
Mail Exchanger
mail1.corp100.com
1.2.2.10
An MX record for the mail exchanger that answers queries for
just the corp100.com domain (and its corresponding A record):
cor p100. comI N MX 0 mai l 1. cor p100. com
mai l 1. cor p100. comI N A 1. 2. 2. 10
An MX record for just site1.corp100.com, a subdomain of
corp100.com:
si t e1. cor p100. comI N MX 0 mai l 1. cor p100. com
A wildcard MX record for the corp100.com domain,
the site1.corp100.com subdomain, and any other
subdomains of corp100.com:
*. cor p100. comI N MX 0 mai l 1. cor p100. com
The following MX records
Domain
Subdomain
other subdomains of
corp100.com
direct queries for one or more domains to the same mail exchanger:
Managing DNS Data
To add an MX record:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> MX Record.
MX Record Properties
Domain Name: If you want to define an MX record for a domain whose name matches the zone in which you
define the MX record, leave this field empty. The NIOS appliance automatically adds the domain name (the
same as the zone name) to the MX record. For example, if you want to create an MX record for a mail
exchanger serving the corp100.com domain and you define the MX record in the corp100.com zone, leave
this field empty.
If you want to define an MX record for a subdomain, enter the subdomain name here. The NIOS appliance
prefixes the name you enter to the domain name for the zone in which you define the MX record. For
example, if you want to create an MX record for a mail exchanger serving site1.corp100.coma subdomain
of corp100.comand you define the MX record in the corp100.com zone, enter site1 in this field.
If you want to define an MX record for a domain and all its subdomains, enter an asterisk ( * ) here to create
a wildcard MX record.
Ensure that the host name you enter complies with the host name restriction policy defined for the zone. If
you create a record name that does not comply with this policy and you try to save it by clicking the Save
Mail Exchanger: Enter the fully qualified domain name of the mail exchanger.
Priority: Enter an integer between 0-65535. The priority determines the order in which a client attempts to
contact the target mail exchanger. The highest priority is 0 and is queried first.
Disable this MX record: Clear the check box to enable the record. Select the check box to disable it.
Adding SRV Records
An SRV (service location) record directs queries to hosts that provide specific services. For example, if you have an
FTP server, then you might create an SRV record that specifies the host which provides the service. You can specify
more than one SRV record for a host. To create an SRV record, you need to specify the domain name, priority, weight,
port, and target host. For more information about SRV records, see RFC 2052, A DNS RR for specifying the location of
services (DNS SRV) .
To add a SRV record:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> SRV Record.
SRV Record Properties
Domain Name: Enter a service name and protocol name to complete the domain name for the target host. If
the name of the service is defined in RFC 1700, ASSIGNED NUMBERS , use that name. Otherwise, you can
use a locally-defined name. (Do not use service port and protocol numbers.) To distinguish the service and
protocol name labels from the domain name, add an underscore as a prefix to the service name and
protocol name; for example, _http._tcp.corp100.com or _ftp._tcp.corp100.com
contact the target host; the domain name host with the lowest number has the highest priority and is
queried first. Target host with the same priority is attempted in the order defined in the Weight field.
Weight: Enter an integer between 0-65535. Weight allows you to distribute the load between target hosts.
The higher the number, the more that host handles the load (compared to other target hosts). Larger
weights give a target host a proportionately higher probability of being selected.
Port: Enter the appropriate port number for the service running on the target host. You can use standard or
nonstandard port numbers, depending on the requirements of your network.
Target: Enter the canonical domain name of the host (not an alias); for example, www2.corp100.com
Note: In addition, you need to define an A record mapping the canonical name of the host to its IP address.
Comments: Enter a descriptive comment for the record.
Disable this SRV record: Clear the check box to enable the record. Select the check box to disable it.
Adding TXT Records
A TXT (text record) record contains supplemental information for a host. For example, if you have a sales server that
serves only North America, you can create a text record stating this fact. You can create more than one text record for
a domain name.
To add a TXT record:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records ->TXT Record.
TXT Record Properties
Domain Name: If you want to define a TXT record for a domain whose name matches the zone in which you
define the TXT record, leave this field empty. The NIOS appliance automatically adds the domain name (the
same as the zone name) to the TXT record. For example, if you want to create a TXT record for the
corp100.com domain and you define the TXT record in the corp100.com zone, leave this field empty.
If you want to define a TXT record for a host or subdomain, enter that name here. The NIOS appliance
prefixes the name you enter to the domain name for the zone in which you define the TXT record. For
example, if you want to create a TXT record for a web server whose host name is www2.corp100.com and
you define the TXT record in the corp100.com zone, enter www2 in this field.
Text: Enter the text that you want to associate with the record. It can contain up to 255 characters.
Comments: Enter a descriptive comment for this record.
Disable this TXT record: Clear the check box to enable the record. Select the check box to disable it.
Using TXT Records for SPF
SPF (Sender Policy Framework) is an anti-forgery mechanism designed to identify spam e-mail. SPF fights e-mail
address forgery and makes it easier to identify spam, worms, and viruses. Domain owners identify sending mail
servers in DNS. SMTP receivers verify the envelope sender address against this information, and can distinguish
legitimate mail from spam before any message data is transmitted.
SPF makes it easy for a domain to say, I only send mail from these machines. If any other machine claims that I'm
sending mail from there, they're not valid. For example, when an AOL user sends mail to you, an e-mail server that
belongs to AOL connects to an e-mail server that belongs to you. AOL uses SPF to publish the addresses of its e-mail
servers. When the message comes in, your e-mail servers can tell if the server that sent the e-mail belongs to AOL or
not.
Managing DNS Data
SPF records are actually specialized TXT records that identify what machines send mail from a domain. You can think
of SPF records as being reverse MX records that e-mail servers can use to verify if a machine is a legitimate sender of
an e-mail. Please refer to http://spf.pobox.com/draft-ietf-marid-protocol-00.txt for the current SPF protocol
specification.
SPF Record Examples
cor p100. com. I N TXT v=spf 1 mx al l
cor p100. net . I N TXT v=spf 1 a: mai l . cor p100. comal l
cor p100. net . I N TXT v=spf 1 i ncl ude: cor p100. comal l
cor p100. net . I N TXT v=spf 1 mx - al l exp=get l ost . cor p100. com
cor p100. com. I N TXT v=spf 1 i ncl ude: cor p200. comal l
Adding CNAME Records
A CNAME record maps an alias to a canonical name. You can use CNAME records in both forward- and IPv4
reverse-mapping zones to serve two different purposes. (At this time, you cannot use CNAME records with IPv6
reverse-mapping zones.)
CNAME Records in Forward-Mapping Zones
In a forward-mapping zone, a CNAME record maps an alias to a canonical (or official) name. CNAME records are often
more convenient to use than canonical names because they can be shorter or more descriptive. For example, you can
add a CNAME record that maps the alias qa to the canonical name engr.corp100.com.
Note: A CNAME record does not have to be in the same zone as the canonical name to which it maps.
To add a CNAME record to a forward-mapping zone:
Forward-Mapping) -> zone -> Edit -> Add Resource Records -> CNAME Record.
Note: IPv6 reverse-mapping zones support only PTR records at this time.
CNAME Record Properties
Alias: Enter the alias for the canonical name.
Canonical Name: Enter the complete canonical (or official) name of the host.
Disable this CNAME record: Clear the check box to enable the record. Select the check box to disable it.
CNAME Records in IPv4 Reverse-Mapping Zones
You can add CNAME records to an IPv4 reverse-mapping zone to create aliases to addresses maintained by a different
name server when the reverse-mapping zone on the server is a delegated child zone with fewer than 256 addresses.
This technique allows you to delegate responsibility for a reverse-mapping zone with an address space of fewer than
256 addresses to another authoritative name server. See Figure 10.21 and RFC 2317, Classless IN-ADDR.ARPA
delegation .
Figure 10.21 CNAME Records in a Reverse-Mapping Zone
You add CNAME records in the parent zone on your name server. The aliases defined in those CNAME records point
to the addresses in PTR records in the child zone delegated to the other server.
When you define a reverse-mapping zone that has a netmask from /25 (255.255.255.128) to /31
(255.255.255.254), you must include an RFC 2317 prefix. This prefix can be anything such as the address range
(examples: 0-127, 0/127) to descriptions (examples: first-network, customer1). On a NIOS appliance, creating such
a reverse-mapping zone automatically generates all the necessary CNAME records. However, if you need to add them
manually to a parent zone that has a child zone with fewer than 255 addresses:
Reverse-Mapping) -> zone -> Edit -> Add Resource Records -> CNAME Record.
2. Enter the following CNAME Record Properties:
Alias: Enter the host portion of an IP address. For example, if the full IP address is 10.1.1.1 in a network
with a 25-bit netmask, enter 1. (The 10.1.1.0/25 network contains host addresses from 10.1.1.1 to
10.1.1.126. The network address is 10.1.1.0, and the broadcast address is 10.1.1.127.)
Parent Zone
10.1.1.0/24
Customer1
DNS Server
Delegated Child Zone
10.1.1.0/25
Delegated Child Zone
10.1.1.128/25
Customer2
DNS Server
Local DNS Server
PTR PTR
CNAME
CNAME
CNAME Records for Customer1
CNAME Records for Customer2
ALIAS CANONICAL NAME
1.1.1.10.in-addr.arpa 1.0/127.1.1.10.in-addr.arpa
. . . . . .
ALIAS CANONICAL NAME
. . . . . .
All the PTR records for
Customer1 use the
addresses defined as
canonical names in the
CNAME records on the
local DNS server.
Sample PTR records:
IP Address:
1.0/127.1.1.10.in-addr.arpa
Host Name:
host1.customer1.com
IP Address:
2.0/127.1.1.10.in-addr.arpa
Host Name:
host2.customer1.com
. . .
The PTR records for
Customer2 also use the
addresses defined as
canonical names in the
CNAME records on the
local DNS server.
Managing DNS Data
Canonical Name: Enter host_ip_addr.prefix.network.in-addr.arpa (host IP address + 2317 prefix + network
IP address + in-addr.arpa). For example, enter 1.0/25.1.1.10.in-addr.arpa. This IP address must match the
address defined in the PTR record in the delegated child zone.
Disable this CNAME record: Clear the check box to enable the record. Select the check box to disable it.
3. Specify one of the following Time to Live Settings:
Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 407.
Adding DNAME Records
A DNAME record maps all the names in one domain to those in another domain, essentially substituting one domain
name suffix with the other (see RFC 2672, Non-Terminal DNS Name Redirection). For example, adding a DNAME record
to the corp100.com domain mapping corp100.com to corp200.com maps name-x.corp100.com to
name-x.corp200.com:
When a request arrives for a domain name to which a DNAME record applies, the NIOS appliance responds with a
CNAME record that it dynamically creates based on the DNAME definition. For example, if there is a DNAME record
cor p100. com. DNAME cor p200. com.
and a request arrives for server1.corp100.com, the NIOS appliance responds with the following CNAME record:
ser ver 1. cor p100. com. CNAME ser ver 1. cor p200. com.
If responding to a name server running BIND 9.0.0 or later, the NIOS appliance also includes the DNAME record in its
response, so that name server can also create its own CNAME records based on the cached DNAME definition.
The following are two common scenarios for using DNAME records:
One company buys another and wants people using both the old and new name spaces to reach the same
hosts.
A virtual Web hosting operation offers different vanity domain names that point to the same server or servers.
There are some restrictions that apply to the use of DNAME records:
You cannot have a CNAME record and a DNAME record for the same subdomain.
You cannot use a DNAME record for a domain or subdomain that contains any subdomains. You can only map
the lowest level subdomains (those that do not have any subdomains below them). For an example of using
DNAME records in a multi-tiered domain structure, see Figure 10.22 on page 403.
Domain Name Target Domain Name
server1.corp100.com > server1.corp200.com
. . . .corp100.com > . . . .corp200.com
Figure 10.22 Adding DNAME Records for the Lowest Level Subdomains
In the case of a domain structure consisting of a single domain (no subdomains), adding a DNAME record redirects
queries for every name in the domain to the target domain, as shown in Figure 10.23.
Figure 10.23 Adding a DNAME Record for a Single Domain
When using a DNAME record, you must copy the resource records for the source domain to the zone containing the
target domain, so that the DNS server providing service for the target domain can respond to the redirected queries.
For the example in Figure 10.23, copy these records:
After copying these records to the zone containing the corp100.corp200.com domain, delete them from the zone
containing the corp100.com domain.
Copy from corp100.com to corp100.corp200.com
www1 IN A 10.1.1.10 www1 IN A 10.1.1.10
www2 IN A 10.1.1.11 www2 IN A 10.1.1.11
ftp1 IN A 10.1.1.20 ftp1 IN A 10.1.1.20
mail1 IN A 10.1.1.30 mail1 IN A 10.1.1.30
Corp200 buys Corp100 and wants to redirect queries for
corp100.com to corp200.com; however, the multitiered
structure of corp100.com prohibits a complete mapping
of all its subdomains. In such a case, DNAME records
provide only a partial solution.
corp100.com
dev.corp100.com
mktg.corp100.com
art.mktg.corp100.com
dev100.corp200.com
art.mktg100.corp200.com
corp200.com
DNAME Record
Domain Name:
dev.corp100.com
Target Domain:
dev100.corp200.com
DNAME Record
Domain Name:
art.mktg.corp100.com
Target Domain:
art.mktg100.corp200.com
corp100.com corp100.corp200.com
corp200.com
DNAME Record
Domain Name:
corp100.com
Target Domain:
corp100.corp200.com
www1.corp100.com
www2.corp100.com ftp1.corp100.com
mail1.corp100.com www1.corp100.corp200.com
ftp1.corp100.corp200.com
mail1.corp100.corp200.com
www2.corp100.corp200.com
Corp200 buys Corp100 and wants to redirect
all queries for corp100.com to corp200.com.
To accomplish this, you add a single DNAME
record to corp100.com.
Managing DNS Data
If DNS service for the source and target domain names is on different name servers, you can import the zone data
from the NIOS appliance hosting the source domain to the appliance hosting the target domain. For information
about this procedure, see Importing Zone Data on page 359.
If DNS service for the source and target domain names is on the same name server and the parent for the target
domain is on a different server, you can delegate DNS services for the target domain name to the name server that
providedand continues to provideDNS service for the source domain name (see Figure 10.24 on page 404). By
doing this, you can continue to maintain resource records on the same server, potentially simplifying the
continuation of DNS administration.
Figure 10.24 Making the Target Zone a Delegated Zone
The following tasks walk you through configuring the two appliances in Figure 10.24 to redirect queries for
corp100.com to corp100.corp200.com using a DNAME record:
On the ns1.corp100.com name server, do the following:
1. Create a new forward-mapping zone called corp100.corp200.com. See Configuring Authoritative Zones on page
353.
2. Copy all the resource records for the domain or subdomain to which the DNAME record is going to apply from
corp100.com to corp100.corp200.com. See Copying Zone Records on page 342.
Note: Because you can only specify the records by type, not individually, you might have to copy some records
that you do not want and then delete them from the corp100.corp200.com zone.
3. In the corp100.com zone, delete all the resource records for the domain or subdomain to which the DNAME
record is going to apply.
4. Add a DNAME record to the corp100.com zone specifying corp100.com as the domain and
corp100.corp200.com as the target domain. Adding a DNAME record is explained in the next section.
5. On the ns1.corp200.com name server, add corp100.corp200.com as a delegated zone and specify
ns1.corp100.com as the name server for it. See Configuring a Delegated Zone on page 365.
corp100.corp200.com corp100.com
ftp1.corp100.corp200.com
mail1.corp100.corp200.com
corp200.com
On the primary name server for corp200.com
(ns1.corp200.com), specify corp100.corp200.com as a
delegated zone and specify ns1.corp100.com as the
name server for that zone.
ns1.corp100.com
Primary name server for corp100.com
and authoritative name server for
corp100.corp200.com
ns1.corp200.com
Primary name server
for corp200.com
Note: This is a conceptual representation of domain name mapping and
depicts the resulting hierarchical relationship of corp200.com as the parent
zone for corp100.corp200.com. The hosts are not physically relocated.
Resource Records
corp100.com IN SOA ns1.corp100.com
IN NS ns1.corp100.com
corp100.com IN DNAME corp100.corp200.com
Resource Records
corp100.corp200.com IN SOA ns1.corp200.com
www1 IN A 10.1.1.10
www2 IN A 10.1.1.11
ftp1 IN A 10.1.1.20
mail1 IN A 10.1.1.30
DNAME Records for Forward-Mapping Zones
To add a DNAME record to a forward-mapping zone:
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> DNAME Record.
2. Enter the following DNAME Record Properties:
Domain Name: Enter the name of a subdomain. If you are adding a DNAME record for the entire zone, leave
this field empty. This field is for adding a DNAME record for a subdomain within the selected zone.
Target Domain: Enter the domain name to which you want to map all the domain names specified in the
Domain Name field.
Comments: Enter identifying text for this record, such as a meaningful note ore reminder.
Disable this DNAME record: Clear the check box to enable the record. Select the check box to disable it.
Note: If you specify a subdomain in the Domain Name field when configuring a DNAME record and the
subdomain is also a subzone, the DNAME record appears in the list view for the subzone, not in the list
view for the parent zone selected in the process of adding the record.
DNAME Records for Reverse-Mapping Zones
You can use DNAME records to redirect reverse lookups from one reverse-mapping zone to another. You can use
DNAME records for reverse-mapping zones to simplify the management of subzones for classless address spaces
larger than a class C subnet (a subnet with a 24-bit netmask).
RFC 2672, Non-Terminal DNS Name Redirection, includes an example showing the delegation of a subzone for an
address space with a 22-bit netmask inside a zone for a larger space with a 16-bit netmask:
$ORI GI N 0. 192. i n- addr . ar pa.
8/ 22 NS ns. sl ash- 22- hol der . exampl e.
8 DNAME 8. 8/ 22
9 DNAME 9. 8/ 22
10 DNAME 10. 8/ 22
11 DNAME 11. 8/ 22
The reverse-mapping zone 0.192.in-addr.arpa. applies to the address space 192.0.0.0/16. Within this zone is a
subzone and subdomain with the abbreviated name 8/22. (Its full name is 8/22.0.192.in-addr.arpa.) This
subdomain contains its own subdomains corresponding to the 1024 addresses in the 192.0.8.0/22 subnet:
Subdomain 8/22 (8/22.0.192.in-addr.arpa)
Subdomain 8.8/22 for addresses 192.0.8.0 192.0.8.255 (or 192.0.8.0/24)
The NS record delegates authority for the reverse-mapping subzone 8/22 to the DNS server
ns.slash-22-holder.example.
Managing DNS Data
Finally, the DNAME records provide aliases mapping domain names that correspond to the 192.0.8.0/24,
192.0.9.0/24, 192.0.10.0/24, and 192.0.11.0/24 subnets to the respective subdomains 8.8/22, 9.8/22, 10.8/22,
and 11.8/22 in the 8/22.0.192.in-addr.arpa subzone.
Note: NIOS appliances support DNAME records in reverse-mapping zones that map addresses to target zones with
a classless address space larger than a class C subnet. However, NIOS appliances do not support such target
zones.
You might also use DNAME records if you have a number of multihomed appliances whose IP addresses must be
mapped to a single set of domain names. An example of this is shown in Figure 10.25.
Figure 10.25 DNAME Records to Simplify DNS for Multihomed Appliances
Note: If you specify a subdomain in the Domain Name field when configuring a DNAME record, and the subdomain
is also a subzone, the DNAME record appears in the list view for the subzone, not in the list view for the parent
zone that was selected when adding it.
To add a DNAME record to a reverse-mapping zone:
Reverse-Mapping Zones) -> zone -> Edit -> Add Resource Records -> DNAME Record.
Note: IPv6 reverse-mapping zones support only PTR records at this time.
2. Enter the following DNAME Record Properties:
Domain Name: If you are adding a DNAME record for the entire zone that you selected in the tree view (that
is, the zone selected in step 1), leave this field empty. If you are adding a DNAME record for a subdomain
within the selected zone, enter the name of the subdomain name here.
View: Shows the name of the current view.
.
.
.
1
2
3
4
Multihomed
Appliances
Instead of maintaining a PTR record for the IP address of
each interface on every multihomed appliance, you can
store all the PTR records in one reverse-mapping zone
and use DNAME records in the other zones to point
reverse lookups to the one set of PTR records.
All PTR records
are here.
All DNAME
records are
here.
Reverse-Mapping
Zones
Reverse-Mapping
Zones
1.1.10.in-addr.arpa.
2.1.10.in-addr.arpa. 4.1.10.in-addr.arpa.
3.1.10.in-addr.arpa.
Resource Records
3.1.1.10.in-addr.arpa IN NS ns1.corp100.com
1 IN PTR www1.corp100.com
2 IN PTR www2.corp100.com
3 IN PTR ftp1.corp100.com
4 IN PTR stor1.corp100.com
Resource Records
4.1.10.in-addr.arpa IN DNAME 3.1.10.in-addr.arpa
Resource Records
Resource Records
Target Domain: Type the name of the reverse-mapping zone to which you want to map all the addresses
specified in the Domain Name field.
Comments: Enter text to help identify this record or to provide a meaningful note or reminder about it.
Disable this DNAME record: Clear check box to apply the DNAME record. Select check box to disable it.
Specifying Time To Live Settings
You can specify TTL (time to live) settings for Infoblox host records and resource records. TTL settings determine how
long the record will be valid in the cache of a caching DNS server. You can configure TTL settings at the grid, zone, and
record level.
To specify TTL settings for a grid:
2. In the Grid DNS Properties editor, click General.
3. In the Default TTL and Negative TTL fields, enter values for Days, Hours, Mins, Secs, as necessary. The default TTL
determines the period for which positive responses to queries remain valid. (You can override this setting for
specific zones and for individual host and resource records.) The negative TTL determines the period for which
negative responses remain valid. (You can override this setting for specific zones.)
To configure TTL settings for an individual zone:
From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Authoritative Zone Properties -> Settings, and override the grid-level TTL settings.
To configure TTL settings for an Infoblox host or resource record:
From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> + (for zone ) ->
View -> Records -> record -> Edit -> Record Properties, and override the grid- or zone-level TTL settings.
Managing DNS Data
Managing Hosts and Resource Records
After zones have been created, they need to be managed, which involves modifying, removing, disabling, and
enabling an Infoblox host or DNS resource record.
Modifying, Disabling, or Removing a Host or Record
The NIOS appliance allows you to modify or remove an existing host or record. An alternative to changing or deleting
a host or record is to disable it. This alleviates having to remove, and then add a host or record again when physical
repair or relocation of a network device occurs. When the changes to the physical device are complete, you can simply
re-enable the host or record.
To modify or disable a host or record:
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> View ->
Records.
2. In the Records viewer, double-click the host or record you want to modify. The host_record editor appears.
Make the necessary changes in the editor.
To disable the host or record, click the Disable this host_record check box.
To enable a host or record, clear the check box.
Deleting a Host or Record
You can delete a host or record to permanently remove it from the system. You can delete a single record or host, or
select multiple objectsincluding a combination of hosts and various resource recordsand delete an entire
selected group.
Records.
2. In the Record viewer, click a host or record -> Edit -> Remove host_record.
3. To delete a set of hosts or records, click one object, then hold down the SHIFT key for contiguous objects or CTRL
for non contiguous objects, click the other objects, then click Edit -> Remove.
Viewing DNS Record Listings
Viewing DNS Record Listings
The NIOS appliance allows you to easily view record listings and search for specific types of records, sorting this
information, and filtering the search findings.
To view record listings for a zone:
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Records.
2. In the Records viewer, choose one of the following Filter types from the drop-down list, to sort the records
accordingly:
All Types
A Record
AAAA Records
Bulkhost Record
CNAME Record
DNAME Record
Host Record
HOST ADDRESS Record
HOST ALIAS Record
MX Record
NS Record
PTR Record
SRV Record
TXT Record
3. To go directly to a specific record, enter the record name in the Go to text field.
Managing DNS Data

Chapter 11 Shared Records
Shared records are groups of DNS resource records that you can assign to one or more zones. Use shared records to
create and update multiple resource records shared by different zones.
This chapter contains the following sections:
Understanding Shared Records on page 412
Using Shared Records on page 414
Adding Shared Records on page 417
Configuration Example on page 420
By default, only superusers can add, edit, and delete shared record groups. Limited-access admin groups can access
shared record groups, only if their administrative permissions are defined. For information on setting permissions for
shared record groups, see Administrative Permissions for Shared Record Groups on page 88.
Shared Records
Understanding Shared Records
You can create shared records in a shared record group and assign the group to one or more zones. The zones handle
the shared records as any other resource record.
To add a group of records in three different zones, you can just add the records in a shared record group and link the
group to the three zones. To add another set of records in only two of the zones, create another group and link the
group to the two specific zones.
You can create several zones that contain the same shared records. For example, if you have three views with two
zones containing 100 records each, you need not create and maintain 600 individual records. You can simply create
the 100 records and share them between two zones and three different views. When a shared record changes, the
system automatically updates them in each zone.
You need not restart the appliance when you create, delete, or modify shared records.
A unique icon identifies shared records both in the shared record group view and the regular DNS zone view.
The shared group icon highlights the groups and an icon overlay highlights shared records.
Figure 11.1 shows an example of how to create and use shared records.
In this example, you create two shared record groups: group1 that contains the A records ftp and printer1 and the MX
record mx1 and group2 that contains the A record web and the MX record mx2. Associate group1 with the internal
view zones sales.corp100.com and finance.corp100.com and the external view zone sales.corp100.com. Associate
group2 with the internal view zone marketing.corp100.com and the external view zones sales.corp100.com and
marketing.corp100.com.
Figure 11.1 Creating Shared Records
sales.corp100.com
finance.corp100.com
Each record is
shared by
several zones,
but stored as a
single database
object.
sales.corp100.com
marketing.corp100.com
marketing.corp100.com
Internal
view
External
view
Internal
view
External
view
group1
mx1
printer1
ftp
mx2
web
group2
sales.corp100.com
finance.corp100.com
Understanding Shared Records
Shared Records Benefits
You can use shared records to:
Reduce object count by using one shared record instead of the creating the same record in multiple zones. For
example, for 10 zones and 500 records per zone, the object count reduces from 5278 objects to 781 objects.
Include multiple A, AAAA, SRV, MX, and TXT resource records in a group and share the group between many
zones.
Simplify and expedite the administration of resource records. When you create or update a shared record, the
appliance automatically updates it in all associated zones.
Shared Records Features
The following are the features of shared records. You can:
Include the following types of DNS resource records in a shared record group: A, SRV, MX, AAAA, TXT; you cannot
include CNAME, DNAME, PTR, Host, or Bulk host records. See Adding Shared Records on page 417.
Create shared records only in authoritative zones. You cannot create shared records in forward zones, stub
zones, or reverse mapping zones.
Link a shared record group to several zones. Zones that contain shared records can also contain regular DNS
records (not shared).
Add shared records only from the shared record group. Click the shared record group to see the views and zones
to which it is linked.
Change or delete shared records from both the shared record group view and the regular DNS zone view. When
you change or delete a record, it changes the canonical source of the shared record and impacts all the zones
that contain the record. These changes are specific only to the Infoblox GUI; not to the Public API.
Shared Records Limitations
You cannot do the following:
Include CNAME, DNAME, PTR, host, or bulk host records in shared record groups.
Copy shared records from a zone.
Use dotted names such as my.name as the shared record name.
Shared Records
Using Shared Records
This section describes the steps to create and use shared records.
1. Create a shared record group in which you can add related shared records. See Configuring Shared Record
Groups on page 414.
2. Add related A, SRV, MX, AAAA, or TXT records into the shared record group. See Adding Shared Records on page
417.
3. Check that the records you added appear in the appropriate shared record group. See Viewing Records in Shared
Record Groups on page 415
4. Associate the shared record group with different zones. See Associating Shared Record Groups With Zones on
page 415.
5. Check the zones you linked to the shared record group. SeeViewing Zones Associated With Shared Record
Groups on page 415.
You can also:
Delete a zone that you linked to the shared record group. See Removing Shared Record Group Zone
Associations on page 416
Delete a shared record group or recover it. See Associating Shared Record Groups With Zones on page 415.
Configuring Shared Record Groups
To add a shared record group:
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Shared Record Group -> Edit -> Add
Shared Record Group.
The Add Shared Record Group editor appears.
2. Click Shared Record Group Properties in the Add Shared Record Group editor, and specify the following:
Group Name: Enter the name of the shared record group. It can be up to 64 characters long and can contain
any combination of printable characters. You can change the shared record group name even after you
create the group. It does not impacts the shared records in the group.
Comment: Enter notes about the shared record group.
3. Click Host Name Restrictions, select the Override grid host name restriction policy check box to supersede the
host name restriction policy set at the grid level and use the drop-down menu to select one of the following host
name checking policies:
("-" and "_")
(-).
This sets the host name policy for the shared records in the group. See Specifying Host Name Restrictions on
page 384.
Note: The shared record group host name policy overrides the zone policy.
Using Shared Records
Viewing Records in Shared Record Groups
To view shared records in a group, select the shared record group in the tree as follows:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> + (for
shared_record_group)
2. Select View -> Records.
The Records Panel appears on the right. It lists the shared record name, type, value, and comment fields. To edit the
shared record properties from this panel, click the shared record name and select Edit -> Shared A Record Properties.
You can associate a shared record group with a zone only if you have read/write access to All Shared Record Groups
and read/write access to the associated zone. Use the zone association panel or the zone editor to associate a shared
record group with a zone.
To associate a shared record group with a zone using the zone association panel:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> shared_record _group
-> Edit -> Add Zone Association.
2. Expand the list of zones and select the zones into which you want to add the shared record groups. Shift-click to
select multiple zones.
3. Click OK.
The system links the shared record group to the zones you select.
To associate a shared record group with a zone using the zone editor:
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> + (for view ) -> + (for Forward-Mapping
Zone ) -> + (for zone ) -> Edit -> Authoritative Zone Properties.
2. Click Shared Record Groups in the zone editor.
3. Click Add.
The Shared Record Groups dialog appears. It lists the shared record groups that the zone can access.
4. Select a shared record group name and click OK. Shift-click to select multiple shared record groups.
The system adds the shared record group to the zone.
Viewing Zones Associated With Shared Record Groups
You can view, manage, sort and search zone associations of a shared record group using the views panel.
To view the list of zones that contain the shared record group:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> shared_record_group)
2. Select View -> Shared Record Group Associations.
The Associations panel that lists the views and zones in the group appears on the right. You can view and delete the
zones from this panel; however, you cannot edit them.
Shared Records
Removing Shared Record Group Zone Associations
You can delete a shared record group zone associations either by removing the zone from the shared record group or
by removing the shared record group from the zone.
To remove a zone from a shared record group:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> shared_record_group.
2. Select View -> Shared Record Group Associations.
The Associations panel that lists the views and zones in the group appears on the right.
3. Click the zone name and select Edit -> Remove zone.
The system deletes zone from the shared record group.
To remove a shared record group from a zone:
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> + (for view ) -> + (for Forward-Mapping
Zone ) -> + (for zone ) -> Edit -> Authoritative Zone Properties.
2. Click Shared Record Groups in the zone editor.
3. Click the shared record group name, click Delete and then click OK to confirm that you want to remove the shared
record group.
The system removes the shared record group from the zone.
Deleting and Recovering Shared Record Groups
Before you delete a shared record group, you must remove the zone associations in the group; otherwise, an error
message appears when you delete. See Removing Shared Record Group Zone Associations on page 416.
To delete a shared record group, select:
From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> shared_record_group -> Edit
-> Remove shared record group.
Use the Recycle Bin feature to recover a deleted shared record group and retrieve the deleted zones. See Using the
Recycle Bin on page 382.
Using the Shared Record Group API
You can use the Shared Record Group API to:
Create, delete, modify shared record groups and associate them with zones.
Add, delete, and update shared records.
You cannot use the Shared Record Group API to update or delete shared records retrieved from a zone.
Adding Shared Records
This section describes how to add the following types of shared records. You cannot add CNAME, DNAME, PTR, Host,
or Bulk host records into a shared record group.
Adding Shared A Records on page 417
Adding Shared AAAA Records on page 417
Adding Shared MX Records on page 418
Adding Shared SRV Records on page 418
Adding Shared TXT Records on page 419
Adding Shared A Records
An A (address) record maps a domain name to an IP address. To define a specific name-to-address mapping, add an
A record to a previously defined authoritative forward-mapping zone (see Creating an Authoritative Forward-Mapping
Zone on page 353).
To add an A record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> shared_record_group ->
Edit -> Add Shared Resource Records -> A Record.
2. Enter the following Shared A Record Properties:
Record Name: Enter the name of the A record that you want to include in the shared record group. The
record name cannot be a dotted name such as www.infoblox.com.
IP Address: Enter the IP address to which you want to map the domain name.
Disable this A record: Clear the check box to enable the record. Select the check box to disable it.
3. Click Time to Live Settings and select the Override zone TTL settings check box to ignore the TTL settings that the
record inherited from the zone. To configure TTL settings for this record, enter the settings in the Days, Hours,
Mins, and Secs fields. For more information on TTL settings, see Specifying Time To Live Settings on page 407.
Adding Shared AAAA Records
AAAA (quad A address) records map a domain name to an IPv6 address. To define a specific name-to-address
mapping, add an AAAA record to a previously defined authoritative forward-mapping zone (see Creating an
Authoritative Forward-Mapping Zone on page 353).
To add a shared AAAA record:
Edit -> Add Shared Resource Records -> AAAA Record.
2. Enter the following Shared AAAA Record Properties:
Record Name: Enter the name of the AAAA record that you want to include in the shared record group. The
Shared Records
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. If
there are multiple noncontiguous groups of zeros, you can only use the double colon for one group to
avoid ambiguity. The NIOS appliance displays an IPv6 address in its shortened form, regardless of its form
when it was entered.
Disable this shared AAAA record: Clear the check box to enable the record. Select the check box to disable
it.
Adding Shared MX Records
An MX (mail exchanger) record maps a domain name to a mail exchanger. A mail exchanger is a server that either
delivers or forwards mail. You can specify one or more mail exchangers for a zone, as well as the priority for using
each mail exchanger. A standard MX record applies to a particular domain or subdomain. A wildcard MX record
applies to a domain and all its subdomains.
To add a shared MX record:
Edit -> Add Shared Resource Records -> MX Record.
2. Enter the following Shared MX Record Properties:
Record Name: Enter the name of the MX record that you want to include in the shared record group. The
Mail Exchanger: Enter the fully qualified domain name of the mail exchanger.
contact the target mail exchanger. The highest priority is 0 and is queried first.
Disable this MX record: Clear the check box to enable the record. Select the check box to disable it.
Adding Shared SRV Records
An SRV (service location) record directs queries to hosts that provide specific services. For example, you can create
an SRV record for an FTP server to specify the host that provides the FTP service. You can specify more than one SRV
record for a host. To create an SRV record, you need to specify the domain name, priority, weight, port, and target
host. For more information about SRV records, see RFC 2052, A DNS RR for specifying the location of services (DNS
SRV) .
To add a shared SRV record:
Edit -> Add Shared Resource Records -> SRV Record.
2. Enter the following SRV Record Properties:
Record Name: Enter the name of the SRV record that you want to include in the shared record group. The
contact the target host; the domain name host with the lowest number has the highest priority and is
queried first. Target host with the same priority is attempted in the order defined in the Weight field.
Weight: Enter an integer between 0-65535. Weight allows you to distribute the load between target hosts.
The higher the number, the more that host handles the load (compared to other target hosts). Larger
weights give a target host a proportionately higher probability of being selected.
Port: Enter the appropriate port number for the service running on the target host. You can use standard or
nonstandard port numbers, depending on the requirements of your network.
Target: Enter the canonical domain name of the host (not an alias); for example, www2.corp100.com
Note: In addition, you need to define an A record mapping the canonical name of the host to its IP address.
Comments: Enter a descriptive comment for the record.
Disable this shared SRV record: Clear the check box to enable the record. Select the check box to disable it.
Adding Shared TXT Records
A TXT (text record) record contains supplemental information for a host. For example, if you have a sales server that
serves only North America, you can create a text record describing it. You can create more than one text record for a
domain name.
To add a shared TXT record:
Edit -> Add Shared Resource Records ->TXT Record.
2. Enter the following shared TXT record Properties
Record Name: Enter the name of the TXT record that you want to include in the shared record group. The
Text: Enter the text that you want to associate with the record. It can contain up to 255 characters.
Disable this TXT record: Clear the check box to enable the record. Select the check box to disable it.
Shared Records
Configuration Example
The following example shows you how to configure shared records. In this example, you:
Create a zone Infoblox.com that is shared among the default, internal, and external views.
Create an A record www and an MX record mx1 in a shared record group (group1), which is associated with the
zone Infoblox.com in all three views.
Add another MX record in a new shared record group (group2), which is associated with the zone Infoblox.com
only in the default and internal views.
To include an A record www and an MX record mx1 in all three views:
1. Create a shared record group called group1.
a. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Shared Record Group -> Edit
-> Add Shared Record Group.
b. Click Shared Record Group Properties in the Add Shared Record Group editor, and specify the following:
c. Group Name: Enter the name of the shared record group as group1.
2. Add an A record www into group1.
a. From the DNS perspective, click the Infoblox Views tab -> + (for Shared Record Groups ) -> + group1 ->
Edit -> Add Shared Resource Records -> A Record.
b. Enter the following Shared A Record Properties:
Record Name: Enter www.
IP Address: Enter the IP address 10.9.0.0.
c. Click the Save icon.
3. Add an MX record mx1 into group1.
b. Enter the following Shared MX Record Properties:
Record Name: Enter mx1.
Mail Exchanger: Enter www.infoblox.com.
Priority: Enter 10.
Comment: Enter mail exchanger record for shared record group1.
4. Assign group1 to default/infoblox.com, internal/infoblox.com, and external/infoblox.com.
Edit -> Add Zone Association.
b. Expand the list of zones and select the zones default/infoblox.com, internal/infoblox.com,
external/infoblox.com into which you want to add group1. Shift-click to select multiple zones.
c. Click OK.
The shared record group group1 is added to the zones default/infoblox.com, internal/infoblox.com,
external/infoblox.com.
To include another MX record mx2 only in the default and internal views:
1. Create another shared record group called group2.
d. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Shared Record Group -> Edit
-> Add Shared Record Group.
e. Click Shared Record Group Properties in the Add Shared Record Group editor, and specify the following:
f. Group Name: Enter the name of the shared record group as group2.
2. Add an MX record mx2 into group2.
b. Enter the following Shared MX Record Properties:
Record Name: Enter mx2.
Mail Exchanger: Enter www.infoblox.com.
Priority: Enter 15.
Comment: Enter mail exchanger record mx2 for shared record group2.
3. Assign group2 to default/infoblox.com and internal/infoblox.com.
Edit -> Add Zone Association.
b. Expand the list of zones and select the zones default/infoblox.com and internal/infoblox.com into
which you want to add group2. Shift-click to select multiple zones.
c. Click OK.
Shared Records

Chapter 12 Configuring DNS Services
The service configurations of a grid are inherited by all members, zones, and networks. For this reason, it is
recommended that you configure services at the grid level before configuring member, zone, and network services.
Note: Limited-access admin groups can access certain DNS resources only if their administrative permissions are
defined. For information on setting permissions for admin groups, see Managing DNS Resource Permissions
on page 83.
This chapter explains how to configure grid services, and is organized as follows:
Configuring DNS Services on page 424
Changing General DNS Properties for a Grid on page 424
Enabling Zone Transfers on page 426
Specifying DNS Queries on page 428
Specifying Root Name Servers on page 430
Specifying Sort Lists on page 431
Using Forwarders with a Grid on page 432
Using Forwarders with a Member on page 432
Specifying Minimal Response Returns on page 432
Disabling and Enabling DNS Service for a Grid Member on page 433
Configuring DNS Zone Services on page 434
Disabling Forwarding for a Zone on page 434
Changing the SOA Name for a Zone on page 435
Setting the Serial Number in the SOA Record on page 435
Adding an E-mail Address to the SOA Record on page 435
Active Directory and Unauthenticated DDNS Updates on page 439
Active Directory and GSS-TSIG-Authenticated DDNS Updates on page 441
Viewing DNS Files on page 447
Viewing DNS Cache Files on page 447
Viewing a DNS Configuration File on page 447
Viewing DNS Zone Statistics on page 447
Configuring DNS Services
When you configure DNS services at the grid level, all grid members, and zones belonging to those members, inherit
the grid-level configuration settings unless you specifically override them for selected members and zones. You can
configure the following DNS services at the grid level:
Changing General DNS Properties for a Grid on page 424
Enabling Zone Transfers on page 426
Specifying DNS Queries on page 428
Specifying Root Name Servers on page 430
Specifying Sort Lists on page 431
Using Forwarders with a Grid on page 432
Using Forwarders with a Member on page 432
Specifying Minimal Response Returns on page 432
Disabling and Enabling DNS Service for a Grid Member on page 433
Configuring Additional IP Addresses for a Grid Member on page 433
Specifying Bulk Host Name Formats on page 389
Changing General DNS Properties for a Grid
The Grid DNS Properties panel offers the following capabilities:
Specifying Zone Deletion Confirmation on page 425
Notifying External Secondary Servers on page 425
Setting Source Port Settings on page 426
From the Grid perspective, click + (for grid ) -> + (for Services) -> DNS -> Edit -> Service Properties.
Specifying TTL Settings
TTL (time to live) is the time that a name server is allowed to cache data. After the TTL expires, the name server is
required to update the data. Setting a high TTL reduces network traffic, but also reduces the accuracy of your cached
data. Conversely, setting a low TTL increases the accuracy of cached data, but also increases the traffic on your
network.
Note: If you choose to configure one TTL setting, you must provide values for all of them.
To specify TTL settings for a grid:
2. In the General section of the Grid DNS Properties editor, modify the following values as necessary:
Refresh Every: This interval tells the secondary how often to send a message to the primary for a zone to
check that its data is current, and retrieve fresh data if it is not. The default is three hours.
Retry Every: This interval tells the secondary how long to wait before attempting to recontact the primary
after a connection failure between the two occurs. The default is one hour.
Expire After: If the secondary fails to contact the primary for the specified interval, the secondary stops
giving out answers about the zone because the zone data is too old to be useful. The default is 30 days.
Default TTL (Time to Live): This interval tells the secondary how long data can be cached.
Negative TTL (Time to Live): This interval tells the secondary how long data can be cached for Does Not
Respond responses.
3. Click the Save icon and the Restart Services icon if it flashes.
Specifying Zone Deletion Confirmation
To ensure that a zone is not deleted by accident, the Enable double confirm for zone deletion property is enabled by
default.
To disable and re-enable the double confirmation requirement before a zone is deleted:
2. In the General section of the Grid DNS Properties editor, clear the Enable double confirm for zone deletion check
box to disable the double confirmation requirement.
Select the check box again to re-enable the double confirmation requirement.
Notifying External Secondary Servers
You can specify grid members (that are secondary name servers) to send notify messages to other secondary name
servers outside the grid. Enabling this option increases the number of notify messages; however, it ensures that an
external secondary name server receives notify messages when its master is a secondary name server in a grid. It is
enabled by default.
To disable secondary name servers from sending notify messages to secondary name servers outside the grid and
then and re-enable it:
2. In the General section of the Grid DNS Properties editor, clear the Enable member secondaries to notify external
secondaries check box. To re-enable the functionality, select the check box again.
All authoritative name servers in a grid (all primary and secondary servers) send notify messages to external
secondary servers by default. Because grid members can use database replication to maintain up-to-date zone data
sets, even if the primary server fails, the secondary servers in the grid can keep their zone data synchronized. Any
external secondary servers can fall out of sync, however, if they rely only on the primary server to send notify
messages when there is new zone data.
For the external secondary servers to accept notify messages from the secondary name servers in the grid and then
request zone transfers from them, you must configure the authoritative name servers in the grid as primary servers
on the external servers. This ensures that the external secondary servers continue to receive notify messages, even
if the primary server is unavailable.
All authoritative name servers in the grid send notify messages to the external secondaries when zone data updates
occur. The external secondary servers then query all the name servers they have configured as primary for that zone.
After this, the external secondary servers request a zone transfer from the name server whose zone has the highest
serial number. If more than one response contains the highest serial number, the external secondary servers transfer
data from the first primary server in their list.
For more information on zone transfers, see Enabling Zone Transfers on page 426.
Setting Source Port Settings
When requesting zone transfers from the primary server, some secondary DNS servers use the source port number
(the primary server used to send the notify message) as the destination port number in the zone transfer request.
To specify source port numbers for notify messages at the grid level:
2. In the General section of the Grid DNS Properties editor, click the Set static source port for notify messages check
box.
3. Optionally, click the Set static source port for queries check box.
For information on notify messages for zone transfers, see Establishing Zone Transfer Notify Messages on page 428.
Enabling Zone Transfers
A zone transfer is the process of sending zone data across a network from one name server to another. This is the
principle method a primary name server uses to send data to a secondary server. When the primary server detects a
change to its zone data, it notifies the secondary servers. The secondary servers reply by checking to see if the serial
number they have for the zone matches the serial number for the zone on the primary server. If not, the secondary
servers request a zone transfer.
In addition to receiving zone change notifications, a secondary server periodically polls the primary server to see if
their zone data is in sync. In response, the primary server can send a DNS message containing just the new zone data,
or the entire data set. The first type of transfer is known as an incremental zone transfer, or IXFR. The second type of
transfer is known as a full zone transfer, or AXFR.
A NIOS appliance, acting as the primary name server for a zone, by default allows zone transfers to its secondary
name servers. This includes all servers listed in the NS records for that zone. You can also specify zone transfers to
other name servers, such as when migrating zone data to a new server or to a management system. You can specify
one or more destinations to which the local appliance sends zone transfers. You can also specify the security and
format of the transfers.
By default, grid members automatically receive updated zone data via database replication (through an encrypted
VPN tunnel). You can change the default behavior to allow grid members to use zone transfers instead of grid
replication. This is helpful when the primary server is another grid member, as a zone transfer is significantly faster
than database replication.
Keep in mind that a database replication updates zone data for both the active and passive nodes of an HA member.
Therefore, if there is a failover, the new active node (the previous passive node) immediately begins serving zone
data with fresh information. In the case of a zone transfer, the passive node does not receive zone data until after a
failover, when it becomes an HA master. At that time it sends a notify message to the primary server, which then
performs a zone transfer. If there is a lot of zone data, the transfer can take up to several minutes, thereby causing a
break in the availability of the new HA master.
If there are no HA members as secondary servers, zone transfers improve performance without a potential drawback.
If you have HA members as secondary servers, zone transfers can result in service interruption when there is a
failover. Furthermore, if the primary server is down when the HA member fails over, the new active node cannot
receive zone data until the primary server comes back online.
To configure zone transfers at the grid level:
1. Under the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. Expand the Zone Transfers section of the Grid DNS Properties editor.
3. In Allow zone transfers to section, click Add, specify the following information, and then click OK:
IP Address: Select, and enter a destination IP address for zone transfers.
Network: Enter a destination network IP Address for zone transfers, and select a Subnet mask from the
drop-down menu (1-31).
Allow: Select to allow zone transfers to the specified destination.
Deny: Select to deny zone transfers to the specified destination.
4. Optionally, you can make the following configuration adjustments:
Modify a zone: Select the zone from the list and click Modify.
Remove a zone: Select the zone from the list and click Remove.
Move a zone up the list: Select the zone and click Move up. The zone moves up the list incrementally with
each click of the button.
Move a zone down the list: Select the zone and click Move down. The zone moves down the list
Using a TSIG Key for Zone Transfers
You can use TSIG (transaction signature) keys to authenticate zone transfer requests and replies. The same key name
and key value must be on the primary and secondary name servers for TSIG-authenticated zone transfers to occur.
When using TSIG, it is important that both appliances involved with the authentication procedure use NTP (Network
Time Protocol) for their time settings (see Using NTP for Time Settings on page 119).
You can use the key generation tool described in this section to create the TSIG key needed to secure transactions
between primary and secondary name servers. You can also enter an existing TSIG key, or click Generate to create
one.
Note: This TSIG function does not use GSS-TSIG (secure updates to Microsoft servers using a key from a Kerberos
server).
To generate a TSIG key at the grid level for a primary server:
2. In the Grid DNS Properties editor, click Zone Transfers.
3. In the Allow TSIG Transfers for section, click Add, specify the following information, and then click OK:
Key name: Enter a meaningful name for the key, such as a zone name or the name of the remote name
server with which the local server authenticates zone transfer requests and replies. This name must match
the name of the same TSIG key on other name servers that use it to authenticate zone transfers with the
local server.
Use DNS One 2.x TSIG: Select this check box when the other name server is an Infoblox appliance running
DNS One 2.x code.
4. Optionally, you can:
Modify a TSIG zone key: Select the member from the list and click Modify.
Move a TSIG key down the list: Select the member and click Move down. The member moves down the list
Specifying a Zone Transfer Format
The zone transfer format determines the BIND format for a zone transfer. This provides tracking capabilities for single
or multiple transfers and their associated servers.
To specify a zone transfer format:
2. In the Grid Properties editor, click Zone Transfers.
3. In the Allow TSIG Transfers for section, select one of the following options from the Zone Transfer Format
drop-down menu:
Many Answers (Secondaries run BIND 8/9): includes as many records as the packet size allows
Many Answers except for these Servers: includes as many records as the packet size allows
One Answer (Secondaries run BIND 4): includes one record per packet
One Answer except for these Servers: includes one record per packet
Note: If you select Many-Answers except for these Servers or One-Answer except for these Servers, enter the IP
address of the Excluded Servers and click Add.
Establishing Zone Transfer Notify Messages
When requesting zone transfers from the primary server, some secondary DNS servers use the source port number
(the primary server used to send the notify message) as the destination port number in the zone transfer request. If
the primary server uses a random source port number when sending the notify messagethat the secondary server
then uses as the destination port number when requesting a zone transferzone transfers can fail if there is an
intervening firewall blocking traffic to the destination port number.
You can specify a source port number for notify messages to ensure the firewall allows the zone transfer request from
the secondary server to the primary server. If you do not specify a source port number, the NIOS appliance sends
messages from a random port number above 1024. For information about specifying source port numbers for notify
messages, see Setting Source Port Settings on page 426.
Specifying DNS Queries
The inheritance feature allows you to specify grid configuration options, individual member options, network level
options, and zone level options. This allows you to specify options at the granular level, and override grid options.
For example, you can configure grid members to perform queries in a different way than the grid. You can configure
queries in the following ways:
Specifying Queries at the Grid Level
Specifying Recursive Queries for a Grid
Specifying Queries at the Grid Level
By default, queries are allowed from any address. You can specify restrictions on the allowed origins for queries, as
well as how queries are allowed.
If the query is recursive and the recursion option is enabled, the NIOS appliance queries other servers for the DNS
data it needs. A recursive query requires the appliance to return requested DNS data, or locate the data through
queries to other servers. For information about allowing recursion, refer to Specifying Recursive Queries for a Grid on
page 429.
To allow or deny queries at the grid level:
2. In the Grid DNS Properties editor, click Queries.
3. In the Allow queries from section, click Add, enter the following address information for servers from which
queries are allowed or denied, and then click OK:
IP Address: Enter an IP address
Network: Enter a network IP Address, and select a Subnet mask from the drop-down menu (1-31).
Any: Select to allow or deny queries from any IP address.
Permission:
Allow: Allows queries from the specified source.
Deny: Denies queries from the specified source.
Modify server properties: Select the server from the list and click Modify.
Remove server: Select the server from the list and click Remove.
Move server up the list: Select the server and click Move up. The server moves up the list incrementally with
Move a server down the list: Select the server and click Move down. The server moves down the list
Note: You can also allow queries at the member level.
Specifying Recursive Queries for a Grid
When a NIOS appliance receives a query for DNS data it does not have, it first sends a query to any specified
forwarders. If a forwarder does not respond and you have enabled recursive queries (and disabled the Use Forwarders
Only check box under Member DNS Properties -> Forwarders), the NIOS appliance sends a recursive query to specified
internal root servers. If an internal root server is not configured, the appliance then sends a recursive query to the
Internet root servers. For more information on specifying root name servers, see Specifying Root Name Servers on
page 430.
To configure recursive queries for a grid:
2. In the Grid DNS Properties editor, click Queries.
3. Select the Allow recursion check box.
4. In the Allow recursive queries from section, click Add, enter the following address information for server from
which recursive queries are allowed or denied, and then click OK:
IP Address: Enter an IP address.
Network: Enter a network IP Address, and select a Subnet mask from the drop down menu (1-31).
Any: Select to allow or deny recursive queries from any IP address.
Allow: Select to allow recursive queries from the specified source.
Deny: Select to deny recursive queries from the specified source.
Move server up the list: Select the server and click Move up. The server moves up the list incrementally with
Move a server down the list: Select the server and click Move down. The server moves down the list
Setting the Source Port Number for Queries
Specifying a source port number for recursive queries ensures that a firewall will allow the response. If you do not
specify a source port number, the NIOS appliance sends these messages from a random port number.
When performing recursive queries, by default the NIOS appliance uses a random source port number above 1024.
The queried server responds using the source port number in the query as the destination port number in its
response. If there is an intervening firewall that does not perform stateful inspection and blocks incoming traffic to
the destination port number, the recursive query fails.
For information on how to specify source port numbers for queries at the grid level, see Setting Source Port Settings
on page 426.
Note: You can also specify these settings at the member level.
Specifying Root Name Servers
Root name servers contain the root zone file which lists the name and IP addresses of the authoritative name servers
for each top-level zone. When a a root name server receives a query for a domain name, it provides at least the names
and addresses of the name servers that are authoritative for the top-level zone of the domain name.
You can configure the NIOS appliance to use Internet root name servers or custom root name servers. If you enable
recursive queries and the appliance receives a recursive query for DNS data it does not have, it queries specified
forwarders (if any) and then queries any root name servers you configure. If you do not specify internal root name
servers and the appliance can access the Internet, it queries the Internet root name servers.
The NIOS appliance provides the flexibility to specify root name servers at the grid, member, and custom view-level.
The default view uses either the member-level root name servers (if specified) or the grid-level root name servers. For
information on configuring root name servers at the view level, see View Level on page 431. For example, you can
specify a set of internal root name servers for a custom view and grid root name servers for another custom view.
Grid Level
To specify root name servers at the grid level:
2. In the Grid DNS Properties editor, click Root Name Servers and select one of the following options:
Use Internet root name servers: This option is selected by default. You can select the Internet root name
servers or specify custom root name servers.
Use custom root name servers: Enables you to specify custom root name servers. Click Add, enter the
following information in the Custom Root Server Item dialog box, and click OK:
Host Name: Enter a name for the root name server.
IP Address: Enter the IP address of the root name server.
The server information appears in the Custom Root Servers field.
Member Level
To specify root name servers at the member level, select the following navigational path and click Override grid root
name servers.
From the DNS perspective, click the DNS Members tab -> + (for grid) -> member -> Edit -> Member DNS Properties ->
Root Name Servers.
Use the steps explained in Grid Level on page 430 to specify custom root servers in the Member DNS Properties
editor. Restart services after you save the settings.
View Level
You can specify root name servers at the view level for all DNS views except the default view. The default view uses
either the member level root name servers (if specified) or the grid level root name servers. Custom views can either
use the grid root name servers or you can override the grid-level setting and specify root name servers for custom
views.
Every grid member has a default view, so if you want to specify root name servers for a default view, you can override
the grid root name server setting at the member level and the default view can use the member-level setting.
To specify the root name server for the custom view, select the following navigational path and click Override grid root
name server.
From the DNS perspective, click the Infoblox Views tab -> + view -> Edit -> IB View Properties -> Root Name Servers.
Use the steps explained in Grid Level on page 430 to specify custom root servers in the View editor. Restart services
after you save the settings.
Specifying Sort Lists
A sort list sorts the order of addresses in responses made to DNS queries. If a DNS lookup produces a response with
multiple addresses, the NIOS appliance sorts the addresses, putting the addresses in the address match list first. If
no addresses match a query, the appliance sorts the addresses according to the address of the querier, putting the
addresses that match the querier first.
To configure a sort list at the grid level:
2. In the Grid DNS Properties editor, click Sortlist, and then click Add.
3. In the Sort List Item dialog, choose from the following:
IP Address: Select radio button and enter the IP address to add to the sortlist. This is a single address with
a 32-bit netmask.
Network: Enter a network IP Address to add to the sortlist, and select a Subnet mask from the drop-down
menu.
Any: Select to add any address to the sortlist.
4. Click OK.
Modify the sortlist: Select an item from the list and click Modify.
Remove an item from the sortlist: Select item from the list and click Remove.
Move an item up the list: Select the item and click Move up. The item moves up the list incrementally with
Move an item down the list: Select the item and click Move down. The item moves down the list
Note: You can also define sortlists at the member level.
Using Forwarders with a Grid
A forwarder is essentially a name server that other name servers send all of their off-site queries to first. The forwarder
builds up a cache of information, avoiding the need for the other name servers to send queries off-site. The NIOS
appliance can first send a query to a forwarder for DNS data it does not have in its cache and authoritative data, and
can work with one or more forwarders.
You can select any grid member as a forwarder.
You can use forwarders to process all queries for off-site DNS data. This is useful in organizations that need to
minimize off-site traffic, such as a remote office with a slow connection to a companys network.
If you activate the Use Forwarders Only check box in the Grid DNS Properties panel, the NIOS appliance sends queries
to forwarders only, and not to other internal or Internet root servers.
To use a forwarder with a grid:
2. In the Grid DNS Properties editor, click Forwarders.
3. Enter an IP Address in the text field, and then click Add. The IP address appears in the Forwarder text field.
4. To remove a forwarder, select the IP address from the Forwarder list, click Delete, and then click Yes.
5. To use only forwarders on your network (and not root servers), select the Use Forwarders Only check box.
Using Forwarders with a Member
You can use forwarders with a grid member in the same way they are used with a grid.
To use a forwarder for a grid member:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click General.
3. Click the Override Grid Forwarder Settings check box.
4. Enter an IP Address in the text field, and then click Add. The IP address appears in the Forwarder text field.
5. To remove a forwarder, select the IP address from the Forwarder list, click Delete, and then click Yes.
6. Optionally, click the Use Forwarders Only check box to use only the specified forwarders on your network and not
root servers.
Specifying Minimal Response Returns
You can enable a NIOS appliance to return a minimal amount of data in response to a query. This capability speeds
up the DNS services provided by the appliance. This section covers how to turn this feature off and on.
To return minimal response data:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Member DNS Properties.
2. In the General section of the Member DNS Properties editor, ensure that the Return minimal responses check box
is selected. It is selected by default.
Disabling and Enabling DNS Service for a Grid Member
You can disable the DNS service for any grid member. Be aware that disabling DNS service for a member removes the
NS records from it. If you later re-enable DNS service for this member, the NS records are then restored.
To disable DNS service for a grid member:
1. Log in as the NIOS appliance administrator, or as a superuser.
2. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Grid DNS Properties.
3. In the General section of the Grid DNS Properties editor, clear the Enable DNS Server check box.
To re-enable the service, select the check box again.
Configuring Additional IP Addresses for a Grid Member
The NIOS appliance supports multiple IP addresses on the loopback interface. You can enable DNS service on
multiple addresses for any grid member. For more information about configuring multiple IP address and anycast
addressing, see Configuring IP Routing Options on page 449.
To configure DNS service on additional IP addresses for a grid member:
1. Log in as the appliance administrator, or as a superuser.
2. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Member DNS Properties.
3. In the General section of the Member DNS Properties editor, click Add to open up the Select Additional Listen On
Address dialog box
4. Select the additional IP address you want to DNS services enabled. If there are no additional IP addresses listed,
configure additional addresses as described in Configuring IP Addresses on the Loopback Interface on page 450.
Click OK.
Configuring DNS Zone Services
You can configure settings for a zone, assign primaries and secondaries, and allow zone transfers. This section
explains how to specify primary and secondary servers, time to live settings, zone transfers, query lists, dynamic
updates, and Active Directory servers, and is organized in the following way:
Disabling Forwarding for a Zone on page 434
Changing the SOA Name for a Zone
Adding an E-mail Address to the SOA Record on page 435
Disabling Forwarding for a Zone
You can disable forwarding for a zone, so the NIOS appliance does not forward a query to another name server, for
data (it does not have) that is requested in the query. Instead, the appliance returns an error to the resolver that the
record does not exist.
To disable forwarding for a zone:
Forward-Mapping) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, select the Disable Forwarding check box.
Specifying TTL Settings for a Zone
TTL (time-to-live) is the time that a name server is allowed to cache data. After the TTL expires, the name server is
required to update the data. You can configure the TTL settings for a zone. Setting a high TTL reduces network traffic,
but also reduces the accuracy of your cached data. Conversely, setting a low TTL increases the accuracy of cached
data, but also increase the traffic on your network. There are five TTL settings, however, if you choose to configure one
setting you must also provide values for the other settings.
To specify TTL settings for a zone:
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, select the Override Grid Settings radio button.
3. Specify the following values:
Refresh every: This interval tells the secondary how often to send a message to the primary for a zone to
check that its data is current, and retrieve fresh data if it is not. The default is three hours.
Retry every: This interval tells the secondary how long to wait before attempting to recontact the primary
after a connection failure between the two occurs. The default is one hour.
Expire after: If the secondary fails to contact the primary for <expire> seconds, the secondary expires the
zone. This TTL setting defines the amount of time after which the secondary stops giving out answers about
the zone because the zone data is too old to be useful. The default is one week.
Default TTL: Time to Live interval that specifies how long data is cached in the grid secondary server.
Negative TTL: Time to Live interval that specifies how long data is cached for Does Not Respond
responses in the grid secondary server.
4. Click the Save icon, and the Restart Services icon if it flashes.
Changing the SOA Name for a Zone
If the primary name server of a zone is a grid member, the NIOS appliance allows you to change the SOA (start of
authority) name that is automatically created when you initially configure the zone. For example, you might want to
hide the primary server for a zone. If your appliance is named dns1. zone. t l d, and for security reasons, you may
want to show a secondary server called dns2. zone. t l d as the primary server. To do so, you would go to
dns1. zone. t l d zone (being the true primary) and change the SOA to dns2. zone. t l d to hide the true identity of the
real primary server.
To change the SOA name for a zone:
2. In the Settings section of the Authoritative Zone Properties editor, select the Set primary for SOA check box, and
then enter the new SOA name in the text field to its right.
Setting the Serial Number in the SOA Record
The serial number in the SOA record incrementally changes every time the record is modified. This serial number
plays a key role when and how zone data is updated via zone transfers. For example, if a secondary server has a
higher serial number than the primary server, zone transfers would come from the secondary, not the primary server.
The NIOS appliance allows you to change the serial number (in the SOA record) for the primary server so it is higher
than the secondary server, thereby ensuring zone transfers come from the primary server (as they should).
You have the option of using administrative style serial numbers instead of a simple counter. To do this, create a serial
number like: yyyymmddxx (such as 2004101843) where yyyy is the year, mm is the month, dd is the day of the month,
and xx is the edit number (so, in the example, we have made 43 changes on 10/18/2004).
You can change the serial number in an SOA record only if the primary server of the zone is a grid member. To change
the serial number in an SOA record:
2. In the Settings section of the Authoritative Zone Properties editor, select enter one of the following:
Click the Increment serial number by check box, and then enter an increment number in the text field to the
right.
Click the Set serial number check box, and then enter a serial number in the text field to the right.
Adding an E-mail Address to the SOA Record
If the primary name server of a zone is a grid member, you can add an administrator e-mail address to the SOA record
to help people determine who to contact about this zone.
To add an e-mail address for an SOA record at the grid level:
2. In the General section of the Grid DNS Properties editor, enter the e-mail address in the E-mail Address (for SOA
RNAME field) field.
To add an e-mail address to an SOA record of a zone:
2. In the Settings section of the Authoritative Zone Properties editor, click the Override e-mail address check box,
and then enter an e-mail address in the E-mail Address text field.
Allowing Zone Transfers for a Zone
By default, the NIOS appliance automatically performs zone transfers within a grid. However, you can configure the
appliance to allow zone transfers to an external DNS name server. Zones within a grid automatically receive updated
zone data via database replication that occurs over a secure SSL-based VPN.
Traditional zone transfers are only necessary when deploying appliances with standard name servers, or devices that
are outside of the grid, such as an external primary server or external secondary servers. This section only applies to
external DNS servers that are not grid members.
The NIOS appliance allows the use of standards-based TSIG keys, that use the one-way hash function MD5 to secure
transfers between the primary and secondary name servers. Zones can override globally configured TSIG keys.
Note: This TSIG function does not use GSS-TSIG (secure updates to Microsoft
servers using a key from a Kerberos

server).
An NTP server should be used for the time settings on both devices that perform TSIG transfers. Adding a secondary
server creates a new NS record and allows ALL transfers, and therefore you must enable TSIG.
Caution: If only one name server is enabled, it will appear both servers are sending current data, but the server
without TSIG enabled will send non-signed transfers.
To allow zone transfers to a zone:
2. In the Authoritative Zone Properties editor, click Transfers.
3. Click the Override Grid zone transfer settings check box.
Note: You can specify whether transfers are sent to a single address or a network. Use an IP address to designate
a single server, or use the network option for a range of addresses on a network.
4. To Allow zone transfers to a specified destination, click Add, do the following, and then click OK:
Click the IP Address radio button, and enter a system IP address. Or, click the Network radio button, enter a
network address and Select a CIDR value from the drop-down menu for the Subnet Mask.
Under Permission, click Allow or Deny, to allow or deny zone transfers to the specified destination.
5. To Allow TSIG transfers for a specified destination, click Add, do the following, and then click OK.
Enter a Key name, such as a zone name or the name of the remote name server with which the local server
authenticates zone transfer requests and replies. This name must match the name of the same TSIG key on
other name servers that use it to authenticate zone transfers with the local server.
Enter a Key, such as an existing TSIG key by typing or pasting it into the field, or click Generate to create a
new key.
Click the Use DNS One 2.x TSIG check box when the other name server is an Infoblox appliance running DNS
One 2.x code.
For more information, refer to Authenticating Updates with TSIG on page 555.
Allowing Query Access for a Zone
You can configure query properties for a zone, and query access for members and grids. By default, queries are
allowed from any source.
To specify query access for a zone:
2. In the Authoritative Zone Properties editor, click Queries.
3. Click the Override Grid query zone settings check box.
4. In the Allow queries from field, click Add, and do the following:
Note: You can specify whether queries are allowed from a single address or a network. Use an IP address to
designate a single server, or use the network option for a range of addresses on a network.
Click the IP Address radio button, and enter a system IP address. Or, click Network, enter a network IP
Address, and select a Subnet mask from the drop-down menu.
Under Permission, click Allow or Deny to allow or deny zone transfers to the specified destination.
5. Click OK.
Supporting Active Directory
Active Directory is a distributed directory service that authenticates network users andby working with DHCP and
DNSprovides the location of and authorizes access to services running on devices in a Windows network.
You can integrate a NIOS appliance providing DHCP and DNS services with a Windows 2000 or 2003 server running
AD (Active Directory). Assuming that you already have AD set up and it is currently in use, you can migrate DHCP and
DNS services away from internal operations on the AD server or from other third party DHCP and DNS systems to NIOS
appliances that serve DHCP and DNS. The basic DHCP, AD, and DNS services are shown in Figure 12.1.
Figure 12.1 DHCP, Active Directory, and DNS
Note: There are no special configurations to consider when providing DHCP services for a network using AD.
Consequently, the following content focuses on DNS. For information about configuring DHCP, see Chapter 15,
Configuring DHCP Services, on page 483 .
Clients sending DDNS (dynamic DNS) updates to a DNS server can authenticate the updates using GSS-TSIG (Generic
Security Service-Transaction Signatures). GSS-TSIG is a modified form of TSIG authentication that makes use of a
Kerberos server (running on the AD server) to act as a third-party authenticator. Microsoft
refers to this type of

authenticated DDNS update as a secure dynamic update.
When adding a NIOS appliance that serves DNS to an AD environment, you must configure the AD/Kerberos server
and NIOS appliance as followsbased on whether or not you want the DNS server to support DDNS updates using
GSS-TSIG authentication:
AD/Kerberos Server
1. Enable zone transfers to the NIOS appliance.
2. (For GSS-TSIG) Create a user account for the NIOS appliance that it can use for authentication.
3. (For GSS-TSIG) Export the DNS server keytab file and save it to your management system.
NIOS Appliance
4. (GSS-TSIG) Enable GSS-TSIG support.
5. (GSS-TSIG) Import the DNS server keytab file from your management system to the NIOS appliance.
6. (GSS-TSIG) Enable GSS-TSIG authentication.
Infoblox
DHCP Server
AD (Active Directory) Server and
Kerberos Server (for GSS-TSIG*)
Infoblox
DNS Server
AD/Kerberos
Connections
TCP/IP Network
Configuration Requests
Clients
1
2
3
Note: For clarity, the DHCP
and DNS servers are shown
on separate appliances. A
single appliance can also
provide both services.
* Clients can optionally use
GSS-TSIG (Generic Security
Service-Transaction
Signatures) to authenticate
DDNS updates.
DNS Queries
and
DDNS Updates
7. Add a forward-mapping zone and give it a name matching the AD DNS zone whose resource records you
want to import.
8. Specify the DC (domain controller) from which the appliance can receive DNS updates. A domain controller
is an AD server that replicates its data among other DCs within its AD domain and among DCs in other
domains.
The NIOS appliance automatically transfers zone data for the parent zone and the containers for its
subzones from the specified DC.
9. Enable the acceptance of DDNS updates from the AD server and from the DHCP clients/AD members whose
addresses the DHCP server assigns. You can set this at the grid, member, and zone levels.
10. (For GSS-TSIG) Enable acceptance of GSS-TSIG DDNS updates from the AD server and from the addresses
that the DHCP server assigns. You can set this at the grid, member, and zone levels.
As you can see from the above task list, adding a NIOS appliance that serves DNS to an AD environment without
GSS-TSIG support involves four simple steps. To include GSS-TSIG support, there are several additional steps.
Active Directory and Unauthenticated DDNS Updates
You can configure a forward-mapping zone to support AD (Active Directory) and receive unauthenticated DDNS
updates from DHCP clients/AD members.
Note: Before configuring the NIOS appliance, enable the AD server to permit zone transfers to the IP address of the
appliance.
To create a forward-mapping zone with AD support:
1. From the DNS perspective, click the Infoblox Views tab > + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
2. In the Add Forward Authoritative Zone dialog box, enter the following:
Authoritative Zone Properties:
Name: Type the name of the forward-mapping zone. This name must match the name in the AD server so
that the zone transfer from the AD server to the NIOS appliance can succeed.
Comment: Type a descriptive note for this zone.
Disable this zone: (clear)
Primary Server Assignment:
Select member: Choose the name of the local NIOS appliance from the drop-down list, and then click OK.
Secondary Server Assignment:
If the secondary DNS server is a member of the same grid as the local NIOS appliance, click Add, and
choose its name from the drop-down list.
If the primary and secondary DNS servers are not members of the same grid, click Add, type a resolvable
domain name and IP address in the Name and IP Address fields, and then click OK.
Updates:
Override member update settings: (select)
Allow dynamic updates from: Click Add, select IP Address, enter the IP address of the AD server (domain
controller) from which you want the NIOS appliance to receive DDNS updates, select Allow, and then click
OK.
(If you want the NIOS appliance to receive updates for this zone from multiple AD servers, add the IP
address for each name server individually.)
Allow dynamic updates from: Click Add, select Network, enter the network address and netmask of the
DHCP clients/AD members from which you want the NIOS appliance to receive DDNS updates, select Allow,
and then click OK.
Allow GSS-TSIG clients to perform dynamic updates: (clear)
Zone AD Servers:
Enable Active Directory support: (select)
Domain Controllers: Click Add, enter the IP address of the domain controller (AD server) from which the
appliance can receive DNS updates, and then click OK.
Note: You can add IP addresses for multiple domain controllers.
Automatically create underscore zones: (select)
This option automatically creates the following subzones that the DNS server must have to answer
AD-related DNS queries:
_msdcs.zone
_sites.zone
_tcp.zone
_udp.zone
domaindnszones.zone
forestdnszones.zone
Active Directory and GSS-TSIG-Authenticated DDNS Updates
You can configure a zone to support AD (Active Directory) and receive secure DDNS updates from clients using
GSS-TSIG (Generic Security Service-Transaction Signatures). GSS-TSIG involves a set of clientserver negotiations to
establish a security context. Within this context, the client and server collaboratively create and mutually verify
transaction signatures on messages that they exchange. Windows 2000 systems and later support DDNS updates
using GSS-TSIG.
Note: For information about GSS-TSIG, see RFC 3645, Generic Security Service Algorithm for Secret Key Transaction
Authentication for DNS (GSS-TSIG).
GSS-TSIG makes use of the Kerberos v5 authentication system. Before configuring the NIOS appliance to support
GSS-TSIG, you must create a user account on the Kerberos server for the NIOS appliance. Then you must export the
corresponding keytab file from the Kerberos server and import it onto the NIOS appliance. The initial configuration
tasks are shown in Figure 12.2 on page 441.
Figure 12.2 Adding a NIOS Appliance to an AD Environment with GSS-TSIG Support
On an already functioning AD Server:
1. Add a user account for the NIOS appliance to the AD server. A corresponding account on the Kerberos server is
automatically created.
2. Export the keytab file for the NIOS appliance account from the Kerberos server to a local directory on your
management system.
Export the keytab file for the DNS
server account from the Kerberos
server to a local directory on your
management system.
Make a forward-mapping
zone and import zone
data from the AD server.
Note: Make sure that
zone transfers from the
AD server to the NIOS
appliance are enabled.
Add a user account
for the DNS server.
Import the keytab file to
the NIOS appliance.
Enable GSS-TSIG updates.
corp100.com corp100.com
Forward-
Mapping
Zone
NIOS
Appliance
Administrators
Management
System
Keytab
File
AD (Active Directory)
Kerberos Server
AD DNS
Zone
1 2
3
4
6
User Account
Reverse-
Mapping
Zone
1.1.10.in-addr.arpa
Optional: Make a
reverse-mapping
zone.
5
Import Zone Data
On a NIOS appliance:
1. Import the keytab file from your management system to the appliance.
2. Configure a forward-mapping zone with the same name as the AD zone, import the zone data from the AD server,
and enable GSS-TSIG updates at both the grid and member levels.
3. (Optional) Create a reverse-mapping zone for the network address space that corresponds to the domain name
space in the forward-mapping zone.
The process in which a DHCP client dynamically updates its resource records on a DNS server using GSS-TSIG
authentication is shown in Figure 12.3. The illustration also shows the relationship of the clients, the DHCP server,
the DNS server, and the Kerberos server (running on the AD server).
Note: For explanations of the alphanumerically notated steps in Figure 12.3, see the section following the
illustration.
Figure 12.3 Authenticating DDNS Updates with GSS-TSIG
1. DHCP IP Address and Network Parameters Assignment
a. The DHCP client requests an IP address.
b. The DHCP server assigns an IP address, subnet mask, gateway address, DNS server address, and a domain
name.
DHCP Client
AD Member
DHCP Server
DNS Server
AD (Active Directory) Server
Kerberos Server
DHCP
Unauthenticated DDNS
Update Attempt (Refused)
TKEY Negotiations
(GSS Handshake)
GSS-TSIG-Authenticated
DDNS Update (Accepted)
DDNS
Update
Active
Directory
1
2
3
4
5
DNS
Query
Kerberos
c2
c3
c1
c
d
b2
b1
a2
a1
a
b
a
b
a
b
a
b
2. Active Directory Computer and User Logins
a. The computer automatically sends a broadcast to find the AD server and logs in.
Note: Computer accounts have passwords that the AD server and computer maintain automatically. There are
two passwords for each computer: a computer account password and a private key password. By default,
both passwords are automatically changed every 30 days.
b. The user manually logs in to a domain.
3. DNS Query for the Kerberos Server
a. The computer (or client ) automatically sends a query for _kerberos._udp.dc_msdcs.dom_name to the DNS
server whose IP address it received through DHCP.
b. The NIOS appliance replies with the IP address of the Kerberos server.
4. Kerberos Login, and TGT and Service Ticket Assignments
a. The client automatically logs in to the Kerberos server.
b. The Kerberos server sends the client a TGT (ticket-granting ticket).
c. Using the TGT, the AD member requests a service ticket for the DNS server.
d. The Kerberos server replies with a service ticket for that server.
5. DDNS Dynamic Update of the Clients Resource Records
a. Unauthenticated DDNS Update Attempt (Refused)
1. The client sends an unauthenticated DDNS update.
2. The DNS server refuses the update.
b. TKEY negotiations (GSS Handshake):
1. The client sends the DNS server a TKEY (transaction key) request, which includes the service ticket.
The service ticket includes the clients principal and proposed TSIG (transaction signature) key,
along with other items such as a ticket lifetime and a timestamp.
2. The DNS server responds with a DNS server-signed TSIG. The two participants have established a
security context.
c. GSS-TSIG-Authenticated DDNS Update (Accepted)
1. The client sends an authenticated DDNS update, which includes the following resource records:
A Address record, which maps a domain name to an IP address
or
PTR Pointer record, which maps an IP address to a domain name
TKEY Transaction Key record, which establishes shared secret keys for use with the TSIG resource
record. For more information, see RFC 2930, Secret Key Establishment for DNS (TKEY RR).
TSIG A meta-record that is never cached and never appears in zone data, a TSIG record is a
signature of the update using an HMAC-MD5 hash that provides transaction-level authentication.
For more information, see RFC 2845, Secret Key Transaction Authentication for DNS (TSIG).
2. The DNS server authenticates the DDNS update and allows it to complete.
3. The DNS server sends a GSS-TSIG-authenticated response to the AD member, confirming the
update.
Note: For GSS-TSIG authentication to work properly, the NIOS appliance must be set in the same time zone as the AD
server and their system clock times must be synchronized within five minutes of each other. One approach is
to use NTP on the NIOS appliance and the AD server and point them both at the same NTP server.
Creating an AD User Account
To create a user account for the NIOS appliance on the AD server, which automatically creates a corresponding user
account on the Kerberos server:
1. Connect to the AD server and make a user account for the NIOS appliance.
Note: The name you enter in the User logon name is the name that you later use when exporting the keytab file.
This is also the principal name. The text in the First name, Initials, Last name, and Full name fields is
irrelevant to this task.
2. The AD server automatically creates a Kerberos account for this user with an accompanying keytab.
If you define an expiration date for the user account and you later create a new account when the first one
expires, the keytab for the corresponding Kerberos account changes. At that point, you must update the keytab
file on the NIOS appliance (see Exporting the Keytab File and Importing the Keytab File on page 445).
Optionally, if your security policy allows it, you can set the user account for the NIOS appliance so that it never
expires.
Exporting the Keytab File
You can export the keytab file for the Kerberos account by using the Ktpass utility that is included in the Microsoft
Windows Resource Kit. Depends on whether you use a Microsoft Windows 2000-based or Windows 2003-based
resource kit, you enter different commands for the exportation.
To export the keytab file using a Microsoft Windows 2000 Resource Kit:
1. Start a command prompt.
2. Enter the following command to export the keytab file for the NIOS appliance user account:
C:> Ktpass -princ service_name/FQDN_instance@REALM -mapuser AD_username -pass password -out
filename.keytab
For example:
C: > Ktpass -princ DNS/ns1.corp100.com@CORP100.COM -mapuser ns1@corp100.com -pass 37Le37
-out ns1.keytab
To export the keytab file using a Microsoft Windows 2003 Resource Kit:
1. Start a command prompt.
2. Enter the following command to export the keytab file for the NIOS appliance user account:
C:> Ktpass -princ service_name/FQDN_instance@REALM -mapuser AD_username -pass password -out
filename.keytab -ptype KRB5_NT_PRINCIPAL
For example:
C: > Ktpass -princ DNS/ns1.corp100.com@CORP100.COM -mapuser ns1@corp100.com -pass 37Le37
-out ns1.keytab -ptype KRB5_NT_PRINCIPAL

wher e:
-princ = Kerberos principal
DNS = Service name in uppercase format
ns1.corp100.com = Instance in FQDN (fully-qualified domain name) format; this is the same as the DNS
name of the NIOS appliance
CORP100.COM = The Kerberos realm in uppercase format; this must be the same as the AD domain
name
-mapuser = Maps the Kerberos principal name to the AD user account
ns1@corp100.com = The AD user name for the NIOS appliance
-pass = The AD user account password
37Le37 = The password of the user account for the NIOS appliance
-out = Exports the keytab file
ns1.keytab = The name of the keytab file
-ptype = Sets the principal type
KRB5_NT_PRINCIPAL = The name of the principal
Note: The keytab file contains highly sensitive data for the NIOS appliance account. Ensure that you store and
transport its contents securely.
Importing the Keytab File
To import the keytab file to the NIOS appliance:
1. Log in to the appliance.
2. From the DNS perspective, click DNS Members -> + (for grid ) -> member.
3. Right-click the member name, and then select Import GSS-TSIG Keytab File.
4. Navigate to the keytab file, select it, and then click OK.
Each time you export a keytab file from a Kerberos server running on Windows 2003, the version number of the
keytab file increases incrementally. Because the version number on the keytab file that you import to the NIOS
appliance must match the version that is in use on the Kerberos server, you should select the last keytab file
that is exported from the Kerberos server if you have exported multiple keytab files. (A Kerberos server running
on Windows 2000 does not increase the version number of keytab files with each export.)
Modifying an AD User Account
To change any AD user account information (login, password, etc):
1. Remove the previous user account from AD.
2. Create a new user for GSS-TSIG mapping.
3. Generate a new keytab file.
4. Import the keytab file to the DNS server.
Enabling GSS-TSIG Authentication
Before you can enable GSS-TSIG authentication, make sure that the keytab file from the Kerberos account for the NIOS
appliance is loaded on the appliance.
1. From the DNS perspective, click DNS Members -> + (for grid) -> member -> Edit -> Member DNS Properties.
2. Check the GSS-TSIG section of the Edit Member DNS Properties editor. If a principal name and version number
are listed, there is a keytab file loaded on the appliance. Compare this information with that for the NIOS
appliance account on the Kerberos server to make sure that they match. If there is no keytab file on the NIOS
appliance or if the loaded keytab file does not match that on the Kerberos server, you must load the correct
keytab file as explained in Exporting the Keytab File on page 444 and Importing the Keytab File.
To enable GSS-TSIG authentication at the grid and member levels:
1. From the DNS perspective, click DNS Members -> grid -> Edit -> Grid DNS Properties.
2. In the Updates section of the Edit Grid DNS Properties editor, select Allow GSS-TSIG clients to perform dynamic
updates .
4. From the DNS perspective, click DNS Members -> + (for grid ) -> member -> Edit -> Member DNS Properties.
5. In the GSS-TSIG section of the Edit Member DNS Properties editor, select Enable GSS-TSIG authentication of
clients.
Creating a Zone with AD and GSS-TSIG Support
To create a forward-mapping zone with AD and GSS-TSIG support:
1. From the DNS perspective, click the Infoblox Views tab > + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
2. In the Add Forward Authoritative Zone dialog box, enter the following:
Authoritative Zone Properties:
Name: Type the name of the forward-mapping zone. This name must match the name in the AD server so
that the zone transfer from the AD server to the NIOS appliance can succeed.
Comment: Type a descriptive note for this zone.
Disable this zone: (clear)
Primary Server Assignment:
Select member: Choose the name of the local NIOS appliance from the drop-down list, and then click OK.
Secondary Server Assignment:
If the secondary DNS server is a member of the same grid as the local appliance, click Add, and choose its
name from the drop-down list.
If the primary and secondary DNS servers are not members of the same grid, click Add, type a resolvable
domain name and IP address in the Name and IP Address fields, and then click OK.
Updates:
Override member update settings: (select)
Allow dynamic updates from: Click Add, select IP Address, enter the IP address of the AD server (domain
controller) from which you want the NIOS appliance to receive DDNS updates, select Allow, and then click
OK.
(If you want the NIOS appliance to receive updates for this zone from multiple AD servers, add the IP
address for each name server individually.)
Allow dynamic updates from: Click Add, select Network, enter the network address and netmask of the
DHCP clients/AD members from which you want the NIOS appliance to receive DDNS updates, select Allow,
and then click OK.
Allow GSS-TSIG clients to perform dynamic updates: (select)
Zone AD Servers:
Enable Active Directory support: (select)
Domain Controllers: Click Add, enter the IP address of the domain controller (AD server) from which the
appliance can receive DNS updates, and then click OK.
Note: You can add IP addresses for multiple domain controllers.
Automatically create underscore zones: (select)
This option automatically creates the following subzones that the DNS server must have to answer
AD-related DNS queries:
_msdcs.zone
_sites.zone
_tcp.zone
_udp.zone
domaindnszones.zone
forestdnszones.zone
Viewing DNS Files
Viewing DNS Files
There are three types of DNS files:
Viewing DNS Cache Files
Viewing a DNS Configuration File
Viewing DNS Zone Statistics
Viewing DNS Cache Files
You can view a DNS cache file for a grid and its member.
To view DNS cache files:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> View -> DNS Cache.
The cache file contents appears in the DNS Cache File viewer. Use the scroll bar to scroll through the contents of
a large cache file.
2. To clear the display, click the X on the DNS Cache File tab.
3. To refresh the cache file, click View -> Refresh.
4. To search within the cache file, click the magnifying glass icon, enter a search string in the dialog text field, and
then click Search.
5. To save a copy of the cache file for troubleshooting purposes, click the download icon, enter a file name, and then
click Save.
Viewing a DNS Configuration File
To view a DNS configuration file:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> View -> DNS Configuration.
The configuration file contents appears in the DNS Config File viewer. Use the scroll bar to scroll through the
contents of the config file.
2. To clear the display, click the X on the DNS Config File tab.
3. To refresh the config file, select View -> Refresh.
4. To search within the file, click the magnifying glass icon, enter a search string in the dialog text field, and then
click Search.
5. To save a copy of the config file for troubleshooting purposes, click the download icon, enter a file name, and
then click Save.
Viewing DNS Zone Statistics
A zone statistics file provides BIND 9 statistics collected by the DNS Server. You can see grid counters and counters
per zone.
To view DNS statistics:
Forward-Mapping Zones) -> zone -> View -> Zone Statistics.
2. To clear the display, click the X on the DNS Config File tab.
3. To refresh the config file, select View -> Refresh.

Chapter 13 Configuring IP Routing Options
You can enable and configure anycast addressing as well as configure multiple IP address on loopback interfaces on
the NIOS appliance, allowing the appliance to function in different network deployments.
Configuring anycast on the appliance and within your network allows you to add redundancy and improve reliability
for DNS server queries. Configuring multiple IP addresses on the loopback interface assists in server migration, server
consolidation, or network address change.
You can also enable DNS services after configuring multiple IP addresses on a loopback interface on the appliance.
For more information about enabling DNS services on an interface, see Configuring Additional IP Addresses for a Grid
Member on page 433.
Multiple IP Addresses on an Interface on page 450
Anycast Addressing on page 452
Configuring IP Routing Options
Multiple IP Addresses on an Interface
You can configure one or more IP addresses on the loopback interface of the NIOS appliance. This section discusses
the following topics:
IP Addressing on an Interface on page 450
Configuring IP Addresses on the Loopback Interface on page 450
Advertising Loopback IP Addresses to the Network on page 451
Configuration Example: Configuring IP Addresses on the Loopback Interface on page 451
IP Addressing on an Interface
You can configure multiple IP addresses on the loopback interface on the NIOS appliance. Enabling multiple IP
addresses allows you to configure the loopback interface as the destination for DNS queries. Configuring multiple IP
addresses on the loopback interface is helpful in different scenarios, such as DNS server migration.
Consider the following scenarios where configuring multiple IP addresses on the loopback interface is beneficial:
Consolidation of DNS servers to a smaller number of servers: You can configure these different IP addresses for
multiple servers onto a single interface of a NIOS appliance during migration to minimize any downtime for
users.
Change in the network addresses of DNS servers: You can configure the appliance interface with both the
current server IP address and the new IP address, minimizing any downtime during the migration to the new IP
address.
Migration of DNS servers.
All three of the scenarios listed require a way to provide uninterrupted services during any change in the network.
Configuring multiple IP addresses to the loopback interface provides the administrator tools to provide continuous
service during server migration.
Configuring IP Addresses on the Loopback Interface
You can configure one or more IP addresses on the loopback interface of the appliance.
To configure an IP address on the loopback interface, perform the following tasks:
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties.
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section.
3. In the Advanced IP configuration section, click Add to open the Advanced IP Configuration dialog box and to
configure a new IP address onto the interface.
4. In the Advanced IP Configuration dialog box, enter the following information:
Network Address: Enter the IP address you want to configure on the interface.
Anycast: Select this check box to configure the IP address as an anycast address on the interface. If you do
not click this check box, the interface is configured as a non-anycast IP address. For more information on
configuring anycast addressing, see Configure an Anycast Address on an Interface on page 456.
Bound Interface: Select which physical interface you want associated with the configured IP address.
Currently, the NIOS appliance supports the loopback interface as the bound interface.
Netmask: Use the drop-down list to specify the netmask for the interface. When you click the drop-down
list, the dialog box displays the choice of netmasks. The choices appear as Classless Inter-Domain Routing
(CIDR) notation of netmasks with the actual netmask bit representation appearing to the right of the
drop-down list once the choice is selected. You cannot change the netmask for a loopback interface. The
netmask is set to /32 by default.
Comments: Enter a text string to help identify this interface and IP address.
Multiple IP Addresses on an Interface
5. Click OK.
To configure multiple IP addresses on the loopback interface, repeat the previous steps for each IP address you want
to add.
Note: If you are configuring the interface on a grid master, the grid is temporarily be disrupted upon saving the
configuration and restarting services on the appliance. The grid reconnects and the appliance regains the role
as grid master after this short delay automatically.
Advertising Loopback IP Addresses to the Network
Configuring multiple IP addresses on the loopback interface relies on the upstream router to populate routes to the
loopback interface.
If you are configuring non-anycast addresses on the loopback interface, or you are not running OSPF within your
network, you must configure the upstream router to reach the NIOS appliance through a static route. Consult with your
network administrator for more information about configuring static routes from the router to the additional IP
addresses on the loopback interface.
Configuration Example: Configuring IP Addresses on the Loopback Interface
You can configure one or more IP addresses on the appliance interface. In this example, configure the following IP
addresses on the loopback interface of the appliance: 10.1.10.1/24, 10.1.10.2/24, and 10.16.1.1/24.
Figure 13.1 Configuring an IP Address on an Interface
Infoblox device
Configure the device with the following IP
addresses on the loopback interface:
10.1.10.1/32
10.1.10.2/32
10.16.1.1/32
Query to 10.1.10.1/32
Query to 10.1.10.2/32
Query to 10.16.1.1/32
To configure IP addresses on the loopback interface of an appliance:
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties. The Edit Grid
Member editor appears in the GUI.
2. In the Edit Grid Member editor, click Advanced IP configuration to expand that section.
3. In the Advanced IP configuration section, click Add. The Advanced IP Configuration dialog box appears in the GUI.
In the Advanced IP Configuration dialog box, enter the following settings:
In the Network Address field, enter 10.1.10.1 as the IP address.
In the Bound Interface field, the available section is the loopback interface. This option selects the interface
to configure.
In the Netmask field, select the /32 from the drop-down list. This configures the address as 10.1.10.1/32.
In the Comment field, enter Interface-1 as a description for this IP address.
4. Click OK.
5. Repeat steps 3-9 to configure 10.1.10.2/32 and 10.16.1.1/32 on the loopback interface of the NIOS appliance.
7. Enable DNS services for the additional IP addresses. For more information about enabling DNS services on an
interface, see Configuring Additional IP Addresses for a Grid Member on page 433.
Anycast Addressing
Note: This feature is not supported on NIOS virtual appliances.
The NIOS appliance supports DNS services for anycast addresses on the loopback interface. This section provides
information on the following topics:
Network Communication Types on page 452
OSPF on page 454
Configure OSPF on an Interface on page 454
Configure an Anycast Address on an Interface on page 456
Configuration Example: Configuring Anycast Addressing on the Appliance on page 456
Network Communication Types
There are primarily four types of communication utilized within a network: unicast, broadcast, multicast, and anycast.
Each of the types of network communication are described in the following section, and focuses on anycast
addressing:
Unicast describes a one-to-one network communication between a single sender and a single recipient. The
routing protocol determines the path through the network from the sender to the recipient based on the specific
protocol or routing scheme. Unicast also describes the address type assigned to the recipient, used by the
routing protocol to determine the path to the recipient.
Multicast describes a one-to-many network communication between a single sender and a specific group of
recipients. All members within the group are intended recipients and each member receives a copy of the data
from the sender. Multicast also describes the address type assigned to the group of recipients, used by the
routing protocol to determine the path to the group.
Broadcast is similar to multicast, the exception being that data is sent to every possible destination regardless
of the groups or subnetwork. There is no specific group of recipients.
Anycast describes a one-to-nearest communication between a single sender and the nearest recipient within a
group. The routing protocol chooses one recipient within a target group based on the routing algorithm for the
specific protocol, and sends data to that recipient only.
Anycast Addressing
Network routers use routing protocols such as the (OSPF) Open Shortest Path First to determine the best path to the
nearest server. The NIOS appliance advertises the route information to the upstream router, a router that forwards
data on the network link and determines the forwarding path to destinations. To enable anycast for DNS queries, you
configure two or more DNS servers with the same anycast address on the loopback interfaces. When a DNS query is
sent to this IP address, the nearest server within the group of servers configured with the IP address responds to the
DNS query. In the case where the nearest server becomes unavailable, the next nearest server responds to the query.
From the client perspective, anycasting is transparent and the group of DNS servers with the anycast address appears
to be a single server.
Figure 13.2 Anycast Addressing
Anycasting for DNS provides the following benefits:
Improved Reliability: Anycast provides improved reliability because DNS queries are sent to an anycast IP
address configured on multiple DNS servers. If the nearest server is offline, then the next DNS server with the
anycast IP address responds to the query.
Load Balancing: Anycast provides load balancing for DNS queries and responses across multiple DNS servers.
Improved Performance: The NIOS appliance uses routing protocol algorithms (such as OSPF) to advertise
anycast routing information to the upstream router. Upstream router determine the best route to the nearest
DNS server. Anycast enables the queries to reach the nearest server faster, as well as providing faster responses
to queries.
The NIOS appliance provides the following support for DNS anycast:
You can configure up to ten anycast IP addresses for each grid member.
The appliance advertises routing information through OSPF. OSPF determines the nearest server to send DNS
queries.
The appliance advertises and withdraws route information based on reachability information to DNS servers
sent by OSPF route advertisements. OSPF uses routing algorithms to determine the best path to servers.
For more information about anycast addressing, see RFC 1546 Host Anycasting Service.
Client
europe.corp100.com
DNS Server
europe.corp100.com
Internet
DNS Query (example:
nslookup)
Anycast:In this example, the desktop sends a DNS query
to 10.128.1.12, the anycast address. Many servers
possess the anycast address. The routing protocol
selects the nearest server and the desktop queries that
server. The nearest server sends back a response after
receiving the query.
A routing protocol usually determines
the nearest server.
In this example, the nearest DNS
server is the Europe server, since the
client is located in Europe.
DNS Query
DNS Server
australia.corp100.com
DNS Server
america.corp100.com
DNS Server
asia.corp100.com
10.128.1.12
10.128.1.12
10.128.1.12
10.128.1.12
OSPF
The OSPF routing protocol is a link-state protocol based on the Dijkstra algorithm used to calculate the shortest path
to a destination address. This protocol uses a link-state database created using routing information advertised from
neighbors and peers, each with costs based on the state of that link to the destination.
The NIOS appliance uses the OSPF routing protocol to advertise routes for an anycast address on the appliance to the
upstream router. The upstream router uses the OSPF advertisements to determine the nearest server from a group
of servers. The upstream router then can forward the query to the chosen DNS server.
Routers uses this OSPF route advertisement to determine which of a group of DNS server is the nearest server. The
sender queries the chosen DNS server only. In practicality, the NIOS appliance relies upon OSPF to determine the best
route for DNS queries to take to the nearest DNS server.
OSPF network topologies consist of administrative domains called OSPF areas. An area is a logical collection of OSPF
routers, servers and other network devices that have the same area identifier. A router within an area keeps an OSPF
database for its OSPF area only, reducing the size of the database that is maintained.
You can configure authentication for OSPF advertisements to ensure that the routing information received from a
neighbor is authentic and the reachability information is accurate.
To enable the appliance to support OSPF and advertising anycast addresses, you must configure the LAN(HA)
interface as an OSPF advertising interface.
Note: If the NIOS appliance is part of an HA pair, the HA interface is chosen. If the appliance is not part of an HA pair,
the LAN interface is chosen.
For more information about the OSPF routing protocol, see RFC 2328 OSPFv2.
Configure OSPF on an Interface
You can configure the LAN(HA) interface on the NIOS appliance as an OSPF advertising interface. The interface
advertises the OSPF routing information out to the network so that routers can determine the best server to query. For
the NIOS appliance, you must configure the LAN(HA) interface as an OSPF advertising interface, and assign an area
ID on the interface to associate it with a specific area. The advertising interface sends out routing advertisements
about the anycast address into the network out to upstream routers.
Note: You must configure an OSPF advertising interface on the appliance to support anycast addressing.
To configure an interface to be an OSPF advertising interface, perform the following tasks:
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section. All of the
addresses configured on interfaces are displayed the Advanced IP configuration section.
3. In the OSPF Area Configuration section, click Add to open the OSPF Area Configuration dialog box.
Anycast Addressing
4. In the OSPF Area Configuration dialog box, enter the following information to configure the LAN(HA) interface as
the OSPF advertising interface:
Advertising Interface: Select the interface that sends out OSPF routing advertisements from the drop-down
list. OSPF advertisements are supported on the LAN(HA) interface only.
Area ID: Enter the OSPF area identifier of the network containing the upstream routers, in either an IP
address format or a decimal format. All network devices configured with the same OSPF area ID belong to
the same OSPF area. The area ID configured on the grid member must match the area ID of the upstream
router configuration.
Area Type: Select the type of OSPF area to associate with the advertising interface from the drop-down list.
The area type configured on the grid member must match the area type of the upstream router
configuration. The supported area types are described as follows:
Standard: A standard area has no restrictions on routing advertisements, and connects to the
backbone area (area 0) and accepts both internal and external link-state advertisements.
Stub: A stub area is an area that does not receive external routes.
Not-so-stubby: A not-so-stubby area (NSSA) imports autonomous system (AS) external routes and
sends them to the backbone, but cannot receive AS external routes from the backbone or other areas.
Authentication Type: Select the authentication method to use to verify OSPF routing advertisements on the
interface. The authentication type configured on the grid member must match the authentication type of
the upstream router configuration. The supported authentication types are described as follows:
None: No authentication for OSPF advertisement.
Simple: A simple password for OSPF advertisement authentication, in clear text.
Message-Digest: An MD5 hash algorithm to authenticate OSPF advertisements. This is the most secure
option.
Authentication Key ID: Enter the key identifier to use to specify the correct hash algorithm after you select
Message-Digest as your OSPF authentication type. The authentication key ID configured on the grid
member must match the authentication key ID of the upstream router configuration.
Authentication Key: Enter the authentication password to use to verify OSPF advertisements after you select
Simple or Message-Digest as your OSPF authentication type. Specify a key string between 1 to 8 characters
for Simple authentication, and a string between 1 to 16 characters for MD5 authentication. The
authentication key configured on the grid member must match the authentication key of the upstream
router configuration.
Retype Authentication Key: Reenter your authentication password for verification.
Automatically Calculate Cost: Select this check box to auto generate the cost to associate with the
advertising OSPF interface to the appliance. If this check box is not selected, then you specify the cost value
explicitly. Calculate the cost as 100,000,000 (reference bandwidth) divided by the interface bandwidth. For
example, a 100Mb interface has a cost of 1, and a 10Mb interface has a cost of 10.
Cost: Enter the cost to associate with the advertising OSPF interface to the appliance.
Hello Interval: Specify how often to send OSPF hello advertisements out from the appliance interface, in
seconds. Specify any number from 1 through 65,535. The default value is 10 seconds. The hello interval
configured on the grid member must match the hello interval of the upstream router configuration.
Dead Interval: Specify how long to wait before declaring that the NIOS appliance is unavailable and down,
in seconds. Specify any number from 1 through 65,535. The default value is 40 seconds. The dead interval
configured on the grid member must match the dead interval of the upstream router configuration.
Retransmit Interval: Specify how long to wait before retransmitting OSPF advertisements from the interface,
in seconds. Specify any number from 1 through 65,535. The default value is 5 seconds. The retransmit
interval configured on the grid member must match the retransmit interval of the upstream router
configuration.
Transmit Delay: Specify how long to wait before sending an advertisement from the interface, in seconds.
Specify any number from 1 through 65,535. The default value is 1 second. The transmit interval configured
on the grid member must match the transmit interval of the upstream router configuration.
5. Click OK.
From the Grid perspective, click grid -> Members -> grid_member. You can view the OSPF service status in the Detailed
Status dialog box.
Configure an Anycast Address on an Interface
You can configure anycast addressing on the loopback interface of the NIOS appliance by doing the following tasks:
Configure an IP address on the loopback interface
Specify the address as an anycast address.
Note: Anycast addressing is supported on the loopback interface only. All other interfaces are greyed out under the
Bound Interface drop-down list when you select the Anycast check box.
To enable and configure anycast addressing on the loopback interface, perform the following tasks:
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section. All of the
additional IP addresses configured on interfaces are displayed the Advanced IP configuration section. If you do
not see any entries, there is no configured IP addresses on the appliance.
Network Address: Enter the IP address you want to assign as the anycast address on the loopback interface.
Specify a 32-bit IPv4 address.
Anycast: You must select this check box to configure the IP address as an anycast address on the interface.
Bound Interface: Anycast addressing is supported on the loopback interface only. All other interfaces
greyed out under the Bound Interface drop-down list when you select the Anycast check box.
Netmask: You cannot change the netmask for a loopback interface. The netmask is set to /32 by default.
Comments: Enter a text string to help identify this interface and IP address.
4. Click OK.
Configuration Example: Configuring Anycast Addressing on the Appliance
The NIOS appliance supports anycast addressing on the loopback interface. Configure the anycast IP address
(10.1.100.10O) on the loopback interfaces on both of the NIOS appliances.
The process follows these steps:
Configuring the LAN(HA) interface as an OSPF Advertising Interface on page 457
Configuring the Anycast Address on the Loopback Interface on page 457
Configuring DNS services on the Anycast Address on the Loopback Interface on page 457
Configuring Anycast Addressing on the Upstream Router on page 458
Anycast Addressing
Configuring the LAN(HA) interface as an OSPF Advertising Interface
3. In the OSPF Area Configuration section, click Add. The OSPF Area Configuration dialog box appears in the GUI.
4. In the OSPF Area Configuration dialog box, enter the following information:
Advertising Interface: Select LAN(HA) from the drop-down list.
Area ID: Enter 1 as the OSPF area ID. Make sure you configure the same ID on the LAN(HA) interface of the
second NIOS appliance.
Area Type: Select Standard from the drop-down list to configure the LAN(HA) interface as part of a standard
OSPF area.
Authentication Type: Select Simple from the drop-down list to enable simple keyword authentication for
OSPF advertisements.
Authentication Key: Enter your simple password to use for OSPF authentication. For this example, enter
0123456 as your simple password.
Retype Authentication Key: Reenter your authentication password for verification.
Automatically Calculate Cost: Select this check box to auto generate the cost to associate with the
advertising OSPF interface to the appliance.
Hello Interval: Specify 10 seconds.
Dead Interval: Specify 40 seconds.
Retransmit Interval: Specify 5 seconds.
Transmit Delay: Specify 1 second.
5. Click OK.
Configuring the Anycast Address on the Loopback Interface
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties. The Edit Grid
Member editor appears in the GUI.
2. In the Edit Grid Member editor, click Advanced IP configuration to expand that section.
3. In the Advanced IP configuration section, click Add. The Advanced IP Configuration dialog box appears in the GUI.
4. In the Network Address field, enter 10.1.100.100 as the anycast IP address.
5. Select the Anycast check box to specify the IP address as an anycast address. After selecting the check box, all
other configurable options become inaccessible. Anycast is supported on the loopback bound interface only.
6. Click OK.
7. Repeat steps 3-6 to configure the anycast address on the other NIOS appliance.
Configuring DNS services on the Anycast Address on the Loopback Interface
Enable DNS service for the anycast address by specifying it as part of the grid member configuration. This allows the
anycast address to participate in DNS service. For information about DNS services on additional IP addresses for a
grid member, seeConfiguring Additional IP Addresses for a Grid Member on page 433.
Note: You must enable the DNS service to listen to the configured anycast address for anycast to function properly.
Without doing this, you will not see OSPF advertising routes to the DNS server.
Configuring Anycast Addressing on the Upstream Router
You can configure the upstream router to accommodate the anycast configuration on the NIOS appliance. The router
configuration must specify the same values as the anycast configuration of the NIOS appliance for the following
options in order for the upstream router to advertise routes to the anycast address:
Hello interval
Dead interval
Authentication Type
MD5 authentication key and key ID (if MD5 authentication is used)
Area ID
Area Type
For example, the hello interval in the router configuration must match the hello interval value in the appliance
configuration.
The following shows a compatible vendor router configuration to accommodate our anycast configuration example:
i nt er f ace Et her net 0/ 0
i p addr ess 192. 168. 1. 131 255. 255. 255. 0
i p ospf message- di gest - key 1 md5 keyabcde
i p ospf hel l o- i nt er val 10
i p ospf dead- i nt er val 40
!
r out er ospf 151
net wor k 192. 168. 1. 0 0. 0. 0. 255 ar ea 0. 0. 0. 0
ar ea 0. 0. 0. 0 aut hent i cat i on message- di gest
!

Chapter 14 Managing DHCP Data
This chapter contains the following topics that explain how to configure DHCP data:
Configuring a DHCP Network on page 461
Adding a Network on page 461
Splitting a Network into Subnets on page 462
Configuration Example: Splitting a Network on page 463
Expanding/Joining a Network on page 464
Configuration Example: Expanding/Joining Networks on page 465
Adding a Shared Network on page 466
Modifying a Network on page 466
Removing a Network on page 466
Enabling and Disabling a Network on page 467
Configuring IP Addresses and DHCP Address Ranges on page 467
Adding a Fixed Address on page 467
Handling DHCP Leases With Client Identifiers on page 468
Adding a DHCP Range on page 469
Excluding Addresses from a DHCP Address Range on page 469
Creating and Managing Templates on page 470
About Network Templates on page 471
Creating and Managing Network Templates on page 471
Modifying Network Templates on page 472
Adding a Network Using a Network Template on page 472
Creating and Managing DHCP Range Templates on page 473
Excluding Addresses from a DHCP Address Range on page 469
Modifying DHCP Range Templates on page 474
Deleting a DHCP Range Template on page 474
Adding a DHCP Range Using a Template on page 474
Creating and Managing Fixed Address Templates on page 476
Modifying Fixed Address Templates on page 476
Deleting Fixed Address Templates on page 477
Adding a Fixed Address Using a Template on page 477
Configuration Example: Creating a Network Using a Template on page 478
Managing DHCP Data
Note: Limited-access admin groups can access certain DHCP resources only if their administrative permissions are
defined. For information on setting permissions for admin groups, see Managing Administrative Permissions
for DHCP Resources on page 90
Configuring a DHCP Network
When you configure a NIOS appliance to provide DHCP services, you must define the network that it serves. After you
create a network, you can then create all the subnetworks individually or you can create a parent network that
encompasses all the subnetworks, and then use the split network feature to create the individual subnetworks
automatically. In addition to splitting a network, you can also create a shared network for subnets that are on the
same network segment. This section explains how to first create a network and split it into subnetworks, and then
how to create a shared network, in the following subsections:
Adding a Network or Splitting a Network into Subnets on page 462
Splitting a Network into Subnets on page 462
Expanding/Joining a Network on page 464
Adding a Shared Network on page 466
Modifying a Network on page 466
Removing a Network on page 466
Enabling and Disabling a Network on page 467
Tip: You can use the shortcut key (right click) on many features to display a drop-down menu where you select
options, rather than going to the menu bar and selecting an option.
Adding a Network
Add a network using the following procedure or using a network template (see Adding a Network Using a Network
Template on page 472).
You must define the network of the NIOS appliance. You must also assign at least one appliance to a network. If
appliances are in a grid, you must specify at least one grid member that serves DHCP for the network. Multiple grid
members can serve a network. If the server is an appliance, you must specify this appliance as the member that
serves the network.
Tip: You can also use a template to add a network. See Adding a Network Using a Network Template on page 472.
To add a network:
1. From the DHCP and IPAM Perspective, click Networks -> Networks -> Edit -> Add Network -> Network.
2. In the Network Properties editor, enter the following:
Address: Enter the IP address of the network.
Netmask: Select the appropriate number of subnet mask bits for the network. You can scroll through the list
or press a number on your keyboard to jump to that value.
Comment: You can enter useful information about the network, such as the name of the organization it
serves.
Disable this network: Select this check box if you do not want the DHCP server to serve DHCP for this
network. This is useful when you are in the process of setting up the DHCP server. Clear this check box after
you have configured the server and are ready to have it serve DHCP for this network.
Automatically create a reverse-mapping zone: Select this check box if you want the appliance to
automatically create the corresponding reverse-mapping zone for the network.
3. Click Member Assignment to expand the Member Assignment section.
4. Click Add.
5. Choose the grid member(s) that should serve DHCP for this network from the Select Grid Members dialog box.
Keep in mind, DHCP properties are inherited from this member. The network can be served by multiple members.
Managing DHCP Data
7. You can then override settings at the grid and member levels and enter unique settings for the network, as
described in each of the following sections:
Configuring DHCP Properties on page 488
Specifying DHCP Lease Times on page 491
Specifying BOOTP Properties on page 492
Specifying Custom DHCP Options on page 494
Configuring DDNS on the DHCP Server on page 543
Setting Watermark Properties on page 567
Splitting a Network into Subnets
Once you have created a network for DHCP, you can configure smaller subnetworks (subnets) with larger netmasks.
Because subnetting borrows bits, a larger netmask defines a larger number of network addresses and a smaller
number of host addresses. You can split the parent network into multiple smaller networks, without configuring each
of the newly-created networks.
These subnetworks inherit the addressing properties of the parent network, such as member assignments. The
exceptions are the default router and broadcast address configuration. The default router and broadcast address
configuration for address ranges and fixed address are disabled by default after splitting a network. You can enable
these properties explicitly for each subnetwork after splitting the parent network.
To split a single network into multiple smaller subnets with larger netmasks:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Networks) -> network -> Edit -> Split Network.
2. In the Split Network dialog box, enter the following:
Use the subnet mask slider to specify the appropriate subnet masks for each subnet. When you move the
slider, the NIOS appliance displays the number of subnets and IP addresses within that subnet.
Immediately add: Select either Only networks with fixed addresses and ranges or All possible subnetworks.
Note that when you add a large number of networks, the appliance could take a little longer to display the
networks.
Select the Automatically create reverse-mapping zones check box to enable reverse-mapping zones for the
subnets. A reverse-mapping zone is an area of network space for which one or more name servers have the
responsibility for responding to address-to-name queries.
3. Click OK to close the Split Network dialog box.
After you split the parent network, you can select each one and configure parameters for each subnetwork.
Note: The default router and broadcast address configurations are invalid after splitting a network. These
configurations are disabled by default.
Configuration Example: Splitting a Network
In Figure 14.1, The administrator of a corporate network, Sales-group1 10.0.0.0/16, plans to split the domain into
smaller subnetworks. Creating multiple subnetworks allow the administrator to plan for expansion and growing traffic
for the company. The administrator wants to split the parent network into smaller separate networks for the different
regional sales offices within the company. The parent network is a /16 network with up to 65,536 possible addresses.
After the split, the administrator has up to 256 subnetworks, each with 256 possible addresses available.
Figure 14.1 Splitting a Network
The NIOS configuration follows these steps:
1. From the DHCP and IPAM Perspective, select Networks -> +(for Networks) -> 10.0.0.0./16 -> Edit -> Split Network.
2. In the Split Network dialog box, confirm that the Network field contains the 10.0.0.0 network. This is the network
you are splitting into smaller subnetworks. Enter the following:
Use the Subnetworks mask slider to select the /24 mask, configuring each of the newly-created
subnetworks with a 255.255.255.0 netmask. When you move the slider, the NIOS appliance displays the
number of subnets and IP addresses within that subnet. Confirm that there are up to 254 possible
subnetworks, each with up to 254 addresses.
Immediately add: Select Only networks with fixed address and ranges. Only those networks with fixed
addresses are split.
Select the Automatically create reverse-mapping zones check box to enable reverse-mapping zones for
subnets.
3. Click OK to close the Split Network dialog box.
Parent Network
Subnetworks
Split into 256 Subnetworks
Europe-sales
10.0.0.0/24
Sales-group1
10.0.0.0/16
(with 65,536 possible addresses)
(each with 256 possible addresses)
Each of the subnetworks inherit the
parameters of the 10.0.0.0/16 Parent Network
S-America-sales
10.0.0.0/24
Asia-sales
10.0.0.0/24
N-America-sales
10.0.0.0/24
Not Inherited:
- Default Router
- Broadcast Address
Inherited:
All other parameters including:
- Lease time settings
- Member assignmentsk
- DNS Server configuration of the Parent
Network
- BOOTP configuration of the Parent
Network
- Email Server configuration of the Parent
Network
Parent Network parameters:
- Member assignments
- DNS Server configuration of the
Parent Network
- BOOTP configuration of the
Parent Network
- Email Server configuration of the
Parent Network
- Default Router
- Broadcast Address
.

.

.
Managing DHCP Data
5. To verify that the new networks have been created, from the DHCP and IPAM perspective, select Networks -> + (for
Networks) -> 10.0.0.0./16 to verify the new networks.
6. To view the properties for a particular subnetwork, select Networks -> + (for Networks) -> network -> View ->
Properties. The properties are identical to the parent network (10.0.0.0/16) configuration except for broadcast
address and default router, which are disabled by default.
Expanding/Joining a Network
Expanding/joining multiple networks into a larger network is the opposite of splitting a network. You can select a
network and expand it into a larger network with a smaller netmask. A smaller netmask defines a smaller number of
network addresses while accommodating a larger number of host addresses. Expanding a network allows you to
consolidate all of the adjacent networks into the expanded network. Adjacent networks are all networks falling under
the netmask of the newly-expanded network.
Each of the adjacent networks join the expanded network and inherit the DHCP member configuration options of the
selected network. The expanded network does not inherit the default router and broadcast address configurations of
the adjacent networks. Those configurations are disabled by default.
Note: The member assignment for the expanded network combines all member assignments of the joining
networks.
To expand/join a network:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> Edit -> Expand/Join
Network. The Expand/Join Network dialog box appears with network address and netmask fields populated with
the current settings based on the smaller adjacent networks configuration. The new expanded network inherits
the DHCP settings of the network selected in this step.
2. In the Expand/Join Network dialog box, select the following:
Use the Netmask drop-down list to specify the available subnet masks for the new expanded network.
Select a smaller netmask value, based on your requirements of the new expanded network. When you click
the drop-down list, the dialog box displays the choice of subnet masks for the new expanded network. The
choices appear as Classless Inter-Domain Routing (CIDR) notation of netmasks with the actual netmask bit
representation appearing to the right of the drop-down list once the choice is selected.
Note: You can configure a reverse-mapping zone only if the selected network is a classful network. A classful
network is a network configured with a /8, /16/or /24 netmask.
Immediately add: Select Automatically create reverse-mapping zones to configure the expanded network to
support reverse-mapping zones. A reverse-mapping zone is an area of network space for which one or more
name servers have the responsibility for responding to address-to-name queries. For more information
about reverse-mapping zones, see Creating an Authoritative Reverse-Mapping Zone on page 354.
3. Click OK to close the Expand/Join Network dialog box.
Note: Expanding a network removes the network from the list of shared networks.
Configuration Example: Expanding/Joining Networks
In Figure 14.2, The administrator of a network wants to consolidate all of the /24 engineering department networks
within the company into a single larger network. The administrator is planning a migration to another server and
wants to consolidate for help with the migration. There are four adjacent networks to consolidate, all falling under the
larger planned /16 network: QA1-company1 10.10.0.0/24, Dev-company1 10.11.0.0/24, Syst-company1
10.12.0.0/24, and QA2-company1 10.13.0.0/24. The resulting expanded network will be a /16 network with up to
65,536 possible addresses, inheriting the network properties of the Dev-company1 10.11.0.0/24 network.
Figure 14.2 Expanding/Joining a Network
1. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> 10.11.0.0/24 -> Edit ->
Expand/Join Network.
2. In the Expand/Join Network dialog box, confirm that the Network field displays the 10.11.0.0 network. This is the
network you are expanding. Enter the following:
Use the Netmask slider to select the /16 subnet mask, configuring the newly-expanded network with a /16
netmask (255.255.0.0). When you move the slider, the NIOS appliance displays the netmask for the
selected subnet. Confirm that the netmask for /16 shows 255.255.0.0. All networks falling under the /16
netmask join the newly-expanded network.
Select the Automatically create reverse-mapping zones check box. This enables reverse-mapping zones for
the subnets.
3. Click OK to close the Expand/Join Network dialog box.
Expanded Network
Subnetworks
QA1-company1
10.10.0.0/24
Eng-company1
10.0.0.0/16
(with 65,536 possible addresses)
(each with 256 possible addresses)
The Expanded Network inherits the
parameters of the selected 10.11.0.0/24
Subnetwork
Dev-company1
10.11.0.0/24
Syst-company1
10.12.0.0/24
QA2-company1
10.13.0.0/24
Subnetwork selected
to expand
Expand
Join
Join
Join
Not Inherited:
- Default Router
- Broadcast Address
Inherited:
All other parameters including:
- DNS Server configuration of the
Parent Network
Parent Network
- Email Server configuration of
the Parent Network
Subnetwork parameters:
- DNS Server configuration of
the Parent Network
Parent Network
- Email Server configuration of
the Parent Network
- Default Router
- Broadcast Address
All of the subnetworks join the
expanded address space
Managing DHCP Data
5. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> 10.0.0.0./16 -> Edit -> Network
properties to view the properties for the newly-expanded network. All of the properties are identical to the
network selected (10.11.0.0/24), except for the broadcast address and default router.
Adding a Shared Network
You can create a shared network when two subnets share a particular network segment. Before creating a shared
network, you must first create the subnetworks. For example, you must first create the networks 10. 32. 1. 0 and
10. 30. 0. 0 before designating them as a shared network.
To add a shared network:
1. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> Shared Networks -> Edit -> Add
Network -> Shared Network.
2. Enter a name for the shared network in the Shared Network Name field.
3. Click Add to open the Select Networks dialog box.
4. Select one or more of the networks.
Tip: To select more than one network at a time, hold down the Ctrl key and click to select subnets. In a long list of
networks, hold down the Shift key and select the first and last subnets to select a contiguous list of subnets.
Modifying a Network
You can modify existing network settings, with the exception of the network address and subnet mask. To modify a
network, shared network, or subnet, select the item you want to modify and click Edit -> Network Properties. Click the
Save icon and the Restart Services icon after you make a change.
Removing a Network
When you remove a network, all of its dataincluding all of its DHCP records, subnetworks, and records in its
subnetworksis erased from the database. Because of the potentially large loss of data that can occur when you
remove a network, the NIOS appliance requires a double confirmation of its removal. Instead of removing a network,
you can disable it.
Configuring IP Addresses and DHCP Address Ranges
Enabling and Disabling a Network
The NIOS appliance allows you to disable and enable currently existing networks instead of removing them from the
database. This feature is especially helpful when you have to move or repair the server for a particular network.
To disable a network or subnetwork:
1. Select the network that you want to disable.
2. Click Edit -> Network Properties.
3. In the Network Properties section of the Network editor, select Disable this network.
After you create networks for your organization, you can define either fixed address or DHCP address ranges in those
networks. Address ranges specify which IP addresses clients can lease. You can configure fixed addresses for
network resources, such as servers and printers.
For additional information about these tasks, see the following sections:
Adding a Fixed Address
Handling DHCP Leases With Client Identifiers
Adding a DHCP Range
Excluding Addresses from a DHCP Address Range
Adding a Fixed Address
After you define your network, you can assign fixed addresses to certain resources such as printers and servers.
When DHCP clients request and renew IP addresses, they normally send their hardware type or MAC address to a
DHCP server as a unique identifier. This enables the DHCP server to track the allocation of addresses and allows
administrators to reserve addresses for specific interfaces. The client sends the unique client identifier as option 61
in DHCP DISCOVER and REQUEST packets, as described in RFC2132, DHCP Options and BOOTP Vendor Extensions.
The client identifier is either the MAC address of the network interface card requesting the address or any string
uniquely identifying the client.
You can also use the DHCP client identifier to assign a fixed address to a NIOS appliance without using the MAC
address. It is especially useful for virtualized server processes that might be moved to different hardware platforms.
When a DHCP client sends option 61, the server first tries to find a fixed address host entry that matches the client
identifier. If it does not find any matching host entry, it uses the hardware address to find a matching host.
Tip: You can also use a template to add a fixed address. See Creating and Managing Fixed Address Templates on
page 476.To assign a fixed address:
1. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> network -> Edit -> Add Fixed
Address.
2. In the Fixed Address Properties editor, enter the following:
IP Address: Enter the IP address you are assigning to the host.
Allocate address dynamically: Select this option if you want to assign DHCP options to an appliance with a
dynamically assigned IP address. If you select this option, enter a MAC address, so you specify DHCP
options for a specific MAC address, while allowing the appliance to receive a dynamic IP address.
In the Match on section, select one of the three options to match your criteria.
MAC address: Select this to assign a fixed address to a host, provided that the MAC address of the
Managing DHCP Data
DHCP client identifier: Select this to assign a fixed address to a host with the same DHCP client
identifier that you specify here.
None (Reserved): Select this to reserve a particular IP address for future use, or if the IP address is
statically configured on a system (the NIOS appliance does not assign the address from a DHCP
request).
MAC Address: This field is enabled only when you select the Match MAC address or the Allocate address
dynamically check box. Enter the MAC address of the host.
DHCP client identifier: This field is enabled only when you select the Match DHCP client identifier check
box. Enter the client identifier of the host where you want the NIOS appliance to assign this IP address. The
client identifier must be unique within the network.
Prepend \0 to DHCP client identifier: This check box is enabled only when you select Match DHCP client
identifier. Select this when a DCHP client sends a \000 prefixed to the DHCP client identifier. \0 is the null
character. Some DHCP clients (for example, Microsoft) send the client identifier in a \000foo format (with
the null character prefix instead of just foo). The client identifier for the requesting host and the client
identifier stored in the NIOS appliance must match.
Comment: Enter useful information about the host, such as the type of resource.
Disable this fixed address: Select this check box if you do not want the DHCP server to allocate this IP
address.
3. You can then override settings at the network level and enter unique settings for the IP address, as described in
each of the following sections:
Handling DHCP Leases With Client Identifiers
The NIOS appliance uses the following rules when converting a DHCP lease into a fixed address:
If a DHCP lease is converted to a fixed address, the NIOS appliance copies the client identifier to the host, based
on information in the lease. If the appliance finds the client identifier in the lease information, the appliance
includes it when it creates the host. If it finds the MAC address, the appliance includes it when it creates the
host. If it finds both, the appliance includes only the MAC address (default) when it creates the host.
If you try to convert a DHCP lease or a fixed address with a client-identifier to a host, the NIOS appliance
displays an error message. This ensures that you do not attempt this operation and lose the data.
You cannot create two fixed addresses with the same client identifiers in the same network. The appliance
displays an error message if you do this.
If the appliance receives a second DHCP request with the same client identifier, it provides the same fixed IP
address if the lease is still binding.
Adding a DHCP Range
You must add a DHCP range for your network so the NIOS appliance can assign IP addresses within that specified
range to DHCP clients. Each range is managed by one or more DHCP servers for address assignments. If the client is
on a network that is assigned a DHCP range, the appliance distributes an available IP address from that range to the
DHCP client, or to a DHCP relay agent if the request came through an agent. You must also assign an appliance to a
DHCP range. If appliances are in a grid, you must specify which member serves DHCP for the DHCP range. If the server
is an independent appliance, you must specify this appliance as the member that serves the DHCP range.
Tip: You can also use a template to add a DHCP range. See Creating and Managing DHCP Range Templates on page
473.
To add a DHCP range to a network:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> Edit -> Add DHCP Range.
2. Enter the following in the DHCP Range Properties editor:
Start Address: Enter the first IP address in the range available for the clients.
End Address: Enter the last IP address in the range available for the clients.
Comment: Enter a text string to help identify this address range.
Disable this DHCP range: Select this check box if you do not want the DHCP server to allocate IP addresses
from this DHCP range. This is useful when you are in the process of setting up the DHCP server. Clear this
check box after you have configured the server and are ready to have it serve DHCP for this network.
3. Click Member Assignment to open the Member Assignment editor, and select one of the following:
Grid Member: Select the member that serves DHCP for this IP address range. The NIOS appliance populates
the drop-down list with the local appliance andif the appliance is part of a gridany other grid members.
or
Enable DHCP failover: Select this check box and click Select Association. In the Select DHCP Failover
Association dialog box, choose a failover association. If no failover peer associations are available in the
drop-down menu, see Configuring DHCP Failover on page 514.
Note: If you do not make a selection between one of these two options, DHCP is not served for this range.
5. You can then override settings at the network level and enter unique settings for the DHCP range, as described
in each of the following sections:
Adding a DHCP Range Using a Template on page 474
Defining Filters on page 499
Excluding Addresses from a DHCP Address Range
Some network devices need to use statically assigned IP addresses rather than addresses dynamically assigned
through DHCP. For example, DHCP servers must have statically configured IP addresses. Also, some devices (such as
legacy network printers) do not support DHCP.
Creating an exclusion range prevents the NIOS appliance from assigning the addresses in the exclusion range to a
client. You can use these addresses as static IP addresses. This prevents address conflicts between statically
configured devices and dynamically configured devices.
Managing DHCP Data
To exclude addresses from an address range:
1. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> network -> addr_range -> Edit
-> DHCP Range Properties.
2. In the Add DHCP Range editor, click Exclusion Ranges.
3. In the Exclusion Ranges section, click Add.
4. In the Exclusion Range dialog box, enter the following information:
Start Address: Enter the first IP address to exclude from the range.
End Address: Enter the last IP address to exclude from the range.
Comment: Enter comments such as the reason for excluding the IP addresses.
5. Click OK to close the Exclusion Range dialog box.
Creating and Managing Templates
A template is a set of rules that determine how to create an entity or object such as a network, a range, or a fixed
address. It enables administrators to create networks in a quick and consistent way. A template is metadata that you
can modify and reuse. For example, you can create a template that determines a networks address space layout. You
can create, modify, and delete a template. Changing or deleting a template does not affect existing objects created
based on the template.
There are three types of templates:
A network template, containing basic information about the network (name, netmask, and comments).
Optionally, if DHCP range templates and/or fixed address templates are available, you can add these to the
network template.
A DHCP range template, containing information about the DHCP range allocated for that template.
A fixed address template, containing information about the offset and number of addresses allocated to the
range.
You must be a superuser to create, edit, or delete a network template, range template, or fixed address template. A
superuser can set other admin groups privileges on these templates in the Administrator perspective. See
Administrative Permissions for DHCP Templates on page 95. You can create templates for DHCP ranges, excluded
DHCP ranges, and fixed address ranges.
About Network Templates
A network template is similar to a real network, except:
It is uniquely identified by a name.
It does not have a network container. Hierarchies such as network and subnets (split networks) do not apply to
network templates.
It does not have a network address. You enter the network address when you create an actual network from the
template.
It does not have a disabled status.
In the General DHCP Options of a DHCP range template, the broadcast address is an address offset number
rather than a broadcast IP address; the network router addresses are offset numbers as well.
An offset in a DHCP range template indicates the starting IP address of the DHCP range object created from the
template. For example, you can create a network template called test_network_template and a DHCP range
template test_range_template linked to this network template. If the test_range_template has an offset value
10, when you create a 10.0.0.0/8 network using the test_network_template, the appliance creates a DHCP
range with the starting IP address 10.0.0.10. If you create a 20.0.0.0/8 network using the
test_network_template, the appliance creates a DHCP range with the starting IP address 20.0.0.10.
When you create a network from a template, it automatically creates a network reverse mapping zone.
When you create a network from a template, you can enable a netmask to override the templates netmask.
Note: If you are adding a fixed address or a DHCP range to your network, you must set these up before creating the
network. See Adding a Fixed Address on page 467 and Adding a DHCP Range on page 469.
A network template is useful for setting up a network with fixed addresses and/or DHCP ranges selected from
predefined information. Once the fixed address and DHCP range information is set up, the network template contains
a range template list and a fixed address template list. You can select from an existing range or fixed address template
and add it to the list.
Creating and Managing Network Templates
Once you create a network template, you can add a network using any existing network template (you define the IP
address for the network, and the subnet mask information is inherited from the selected template).
To create a network template:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Templates) -> + (for Network Templates) -> Edit -> Add
Templates -> Network Template.
2. In the Add Network Template editor, enter the following in the Network Template Properties section:
Name: Enter a name for the network template such as ClassC.
Netmask: Either select a subnet mask for the network using the dropdown menu or click Allow any
netmask. For example, select the /24 (255.255.255.0) netmask to create a /24 network template.
Allow any netmask: Select this check box to let the subnet mask have any value. If you check this box, you
must specify the subnet mask when you create a network using this template.
Comment: You can enter useful information about the network, such as the name of the organization it
serves.
Automatically create a reverse-mapping zone: Select this check box if you want the appliance to
automatically create the corresponding reverse-mapping zone for the network.
3. In the Range Templates section, click Add, then choose a DHCP range template for this network template, then
click OK. The DHCP range template properties are inherited from this selection. You can select multiple DHCP
range templates by Shift-clicking or Ctrl-clicking the range templates in the Select DHCP Range Template dialog
box.
Managing DHCP Data
4. In the Fixed Address Templates section, click Add, choose a fixed address template for this network template in
the Select Fixed Address Template dialog box, and click OK. You can select multiple fixed address templates by
Shift-clicking or Ctrl-clicking the fixed address templates in the Select Fixed Address Template dialog box.
6. Click Add.
7. Choose the grid member(s) that serve(s) DHCP for this network from the Select Grid Members dialog box. The
DHCP properties are inherited from the selected member. The network can be served by multiple members.
Ensure that you include the DHCP range templates member in the Member Assignment section. Otherwise, an
error message appears.
8. Click OK to close the Select Grid Members dialog box.
described in the sections:
Modifying Network Templates
To modify a network template:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Templates)-> + (for Network Templates) ->
network_template -> Edit -> Network Template Properties.
2. Enter your changes.
Deleting Network Templates
To delete a network template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> Network Templates -> network_template -> Edit
-> Remove network_template.
A confirmation dialog box appears. Confirm the deletion or cancel without deleting the template.
Adding a Network Using a Network Template
Add a network using a network template as follows:
1. From the DHCP and IPAM Perspective, select Networks -> Edit -> Add Network -> Using Template.
2. In the Create Network and Children Using Template dialog box, enter the following:
Select Network template: Click to select a network template to create a new network. The new network uses
the properties defined in the template. This field displays only when a template is not pre-selected.
Network Address: Enter the IP address of the network that should use the template.
Netmask: This menu is enabled only if you selected the Allow any netmask option during network template
creation. Select the appropriate subnet mask for the network using the dropdown menu. This menu is
disabled if you specified the netmask in the network template instead of clicking Allow any netmask.
If desired, enter a comment in the Comment field.
3. Click OK to close the Create Network and Children dialog box.
Creating and Managing DHCP Range Templates
A DHCP range template has properties similar to those of a real DHCP range, except for the following:
It can be defined independently and can be referred by multiple network templates.
The start address and end address fields are replaced by numbers of the offset from the network start address
and the number of IP addresses in the range.
It does not have a disabled status.
For the exclusion range in the template, the start address and end address are replaced by the number of
offsets in the DHCP range template's start address and the number of IP addresses in the exclusion range.
It does not have any grid member assignment option.
In the General DHCP Options of a DHCP range template, the broadcast address is an address offset number
rather than a broadcast IP address; network router addresses are offset numbers as well.
Exclude ranges are templates with offset and number of address properties rather than start and end
addresses.
After you create a DHCP range template, you can use the template to create a DHCP range.
To create a DHCP range template:
1. From the DHCP and IPAM Perspective, select + (for Templates)-> + (for Range Templates) -> Edit -> Add Templates
-> DHCP Range Template.
2. Enter the following in the DHCP Range Templates Properties editor:
Name: Enter a name for the DHCP range template (for example, Region1 IT).
Offset: An offset in a DHCP range template indicates the starting IP address of the DHCP range object
created from the template. Enter the value for the offset from the start IP address of the network created
from the template to which this range template is linked.
Number of Addresses: Enter the number of IP addresses (can be one or more). You can use this template to
populate one or more fixed addresses.
Comment: Enter a text string to help identify this address range.
3. Click Member Assignment and select one of the following:
Grid Member: Select the member that serves DHCP for this IP address range template. The NIOS appliance
populates the drop-down list with the local appliance andif the appliance is part of a gridany other grid
members.
or
Enable DHCP failover: Select this check box and click Select Association. In the Select DHCP Failover
Association dialog box, choose a failover association. If no failover peer associations are available in the
drop-down menu, see Configuring DHCP Failover on page 514.
Note: If you do not make a selection between one of these two options, DHCP is not served for this range
template.
5. You can then override settings at the network level and enter unique settings for the DHCP range template, as
Managing DHCP Data
Excluding Addresses From DHCP Range Templates
Some network devices need to use statically assigned IP addresses rather than addresses dynamically assigned
through DHCP. For example, DHCP servers must have statically configured IP addresses. Also, some devices (such as
legacy network printers) do not support DHCP.
Creating an exclusion range prevents the DHCP server from assigning the addresses in the exclusion range to a client.
You can use these addresses as static IP addresses. This prevents address conflicts between statically configured
devices and dynamically configured devices.
To exclude addresses from a DHCP range template:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Templates) -> + (for Range Templates) ->
template_name -> Edit -> Edit Properties.
2. Select the Exclusion Range Templates editor.
3. Click Add, and enter the following information in the Exclusion Range Template dialog box, enter the following:
Offset: An offset in a DHCP range template indicates the starting IP address of the DHCP range object
created from the template. Enter the value for the offset from the start IP address of the network created
from the template to which this range template is linked. For example, if you specify an offset value of 9,
when you create a 25.0.0.0/8 network using the network template, the appliance creates a DHCP range
object with the starting IP address 25.0.0.9.
Number of Addresses: Enter the number of IP addresses (can be one or more) that you want to exclude in
the DHCP range template.
Comment: Enter comments such as the reason for excluding the IP addresses.
4. Click OK to close the Exclusion Range dialog box.
Modifying DHCP Range Templates
To edit a DHCP range template:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Templates) -> + (for Range Templates) ->
range_template -> Edit -> Properties.
2. Enter the changes in the DHCP Range Templates Properties editor.
Deleting a DHCP Range Template
To delete a DHCP range template:
1. From the DHCP and IPAM Perspective, select Networks + (for Templates) -> Range Templates -> range_template ->
Edit -> Remove range_template.
2. In the confirmation dialog box, select Yes to confirm the deletion.
Adding a DHCP Range Using a Template
After you create a DHCP range template, you can add a DHCP range to an existing network, based on the selected
template.
This section describes two ways to add a DHCP range from a template. You can select the network first, and then
select the DHCP range template, or you can select the template first and then select the network to which you are
adding a DHCP range.
Adding a DHCP Range from a Network
To add a DHCP range from an existing network:
1. From the DHCP and IPAM Perspective, click the Networks tab + (for Networks) -> network -> Edit -> Add DHCP Range
-> Using Template.
2. In the Create Range Using Template dialog box, click Select Range Template to display a list of available
templates.
3. In the Select DHCP Range Template dialog box, select the range template you want to use, and then click OK.
4. Fill in the Start Address and End Address fields.
5. If desired, enter text in the Comment field.
Adding a DHCP Range from a DHCP Range Template
To add a DHCP range to a network from an existing DHCP range template:
1. From the DHCP and IPAM Perspective, click the Networks tab -> + (for Templates) -> + (for Range Templates) ->
range_template -> Edit -> Add DHCP Range -> Using This Template.
2. In the Create Range Using Selected Template dialog box, click Select Network to list the available networks.
3. In the Select Network dialog box, select the network to which you want to add the DHCP range, and then click OK.
4. Fill in the Start Address and End Address fields.
5. If desired, enter text in the Comment field.
Managing DHCP Data
Creating and Managing Fixed Address Templates
A fixed address template also has properties similar to a fixed address, except for the following:
It can be defined to populate one or multiple fixed address templates.
It has the default, uneditable MAC address 00:00:00:00:00:00. All fixed address(es) created from the template
have this default MAC address. You must update it to an actual MAC address.
After you create a fixed address template, you can use the template to create fixed addresses.
To create a fixed address template:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Templates) -> Fixed Address Templates -> Edit ->
Add Templates -> Fixed Address Template.
2. In the Fixed Address Templates Properties editor, enter the following:
Name: Enter a name for the fixed address template (for example, HP Printer).
Offset: An offset in a template is a number indicating the offset for the starting IP address of the object
created from the template. Enter the value for the offset from the start IP address for the network created
from the template to which this template is linked.
Number of Addresses: Enter the number of IP addresses (can be one or more) to use as fixed addresses.
You can use this template to populate one or more fixed addresses.
Allocate address dynamically: Select this option if you want to assign DHCP options to a device with a
dynamically assigned IP address. This enables you to reserve an IP address.
MAC Address: The default, uneditable MAC address 00:00:00:00:00:00. All fixed addresses created from
the template have this default MAC address. You must update it to an actual MAC address when you create
a fixed address object using the template. For example, if you select the Allocate address dynamically
option in the template and use the template to create a fixed address object, then, you must update the
MAC address to an actual value. The appliance assigns a dynamically allocated IP address to this MAC
address.
Comment: You can enter useful information about the host, such as the type of resource.
3. You can then override settings at the network level and enter unique settings for the fixed address template and
range template, as described in each of the following sections:
Modifying Fixed Address Templates
To edit the general properties of a fixed address template:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Templates) -> + (for Fixed Address Templates) ->
fixed_address_template -> Edit -> Properties.
2. Make your changes in the Fixed Address Template Properties editor.
Deleting Fixed Address Templates
To delete a fixed address template:
1. From the DHCP and IPAM Perspective, select Networks -> +(for Templates) -> fixed_address_template -> Edit ->
Remove fixed_address_template.
Adding a Fixed Address Using a Template
There are two ways to use fixed address templates to add a fixed address. You can select the network first, and then
select the fixed address template, or you can select the template first, and then specify to which network you are
adding the fixed address.
Adding a Fixed Address from a Network
To add a fixed address from an existing network:
1. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> network -> Edit -> Add Fixed
Address -> Using Template.
2. In the Create Fixed Address Using Template dialog box click Select Fixed Address Template to display a list of
available fixed address templates.
3. In the Select Fixed Address dialog box, select the template you want to use, and then click OK to close the dialog
box.
4. Complete the following fields:
IP Address: This displays the IP address of the network. Modify it to select an individual address within this
network.
Match Client: Use one of the three options to select your matching criteria.
MAC address: Select this to assign a fixed address to a host, provided that the MAC address of the
DHCP client identifier: Select this to assign a fixed address to a host with the same DHCP client
identifier that you specify here.
(None) Reserved: Select this to reserve a particular IP address for future use, or if the IP address is
statically assigned to a system.
MAC Address: This field is enabled only when you select the Match MAC address or the Allocate address
dynamically check box. Enter the MAC address of the host.
DHCP client identifier: This field is enabled only when you select the Match DHCP client identifier check
box. Enter the client identifier of the host where you want the appliance to assign this IP address. The client
identifier must be unique within the network.
Prepend \0 to DHCP client identifier: This check box is enabled only when you select Match DHCP client
identifier. Select this when a DCHP client sends a \000 prefixed to the DHCP client identifier. \0 is the null
character. Some DHCP clients (for example, Microsoft) send the client identifier in a \000foo format (with
the null character prefix instead of just foo). The client identifier for the requesting host and the client
identifier stored in the NIOS appliance must match.
5. If desired, enter a comment in the Comment field.
6. You can then override settings at the network level and enter unique settings for the fixed address template and
range template, as described in each of the following sections:
Managing DHCP Data
Adding a Fixed Address Using a Fixed Address Template
To add a fixed address to a network from an existing fixed address template:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Templates)-> + (for Fixed Address Templates) ->
fixed_address_template -> Edit -> Add Fixed Address -> Using This Template.
2. In the Create Fixed Address Using Selected Template dialog box, click Select Network to list the available
networks.
3. In the Select Networks dialog box, select the network to which you are adding the fixed address, and then click
OK.
4. In the Create Fixed Address Using Selected Template dialog box, complete the fields as described in steps 4
through 6 of Adding a Fixed Address from a Network on page 477.
Viewing Range and Fixed Address for Network Templates
To list DHCP range templates and fixed address templates, in the DHCP and IPAM perspective, select Networks ->
+ (for Templates) -> + (for Network Templates) -> network_template -> View -> Range and Fixed Address Templates.
The Range and Fixed Address Templates panel appears. It displays the DHCP range templates and fixed address
templates assigned to the network template. You can filter the list to view specific types of templates (such as only
fixed address templates or only DHCP range templates).
Configuration Example: Creating a Network Using a Template
Figure 14.3 illustrates how to create and use a /24 network template with the following ranges and configuration:
First address 192.168.2.1 reserved for the router
Next 10 addresses (192.168.2.2 to 192.168.2.11) reserved for servers
Next 10 addresses (192.168.2.12 to 192.168.2.21) reserved for printers
Next 10 addresses (192.168.2.22 to 192.168.2.31) assigned as fixed addresses
Next 10 addresses (192.168.2.42 to 192.168.2.51) are in an exclusion range. If you assigned static addresses
to certain hosts in the middle of an address range template, you can exclude the addresses from the address
range template so the appliance does not assign the IP addresses to clients.
100 addresses (192.168.2.32 to 192.168.2.131) reserved for workstations. The appliance assigns these
dynamically.
Figure 14.3 Creating a Network Using Template
Use the following steps to configure the sample network template (shown in Figure 14.3). After you create the
templates, you can create a network using the templates.
1. Create the following DHCP range templates:
Server templates with the following values:
Name: Servers
Offset: 2
Number of Addresses: 10
Comment: Address range 2 to 11 for Servers
Printer template with the following values:
Name: Printers
Offset: 12
Comment: Address range 12 to 21 for printers and 22 to 31 in the exclusion range.
Exclusion range template with the following values:
Offset: 22
Comment: Excluding addresses 22 to 31 from the DHCP range 12 to 31.
Template for workstations with the following values:
Name: Workstations
Offset: 42
Comment: Address range 42 to 141 for DHCP on workstations
2. Create a fixed address template with the following values:
Name: myFixedAddress
Offset: 32
192.168.2.1
192.168.2.2 to
192.168.2.11
192.168.2.12 to
192.168.2.21
192.168.2.0 /24
network
192.168.2.22 to
192.168.2.31
192.168.2.32 to
192.168.2.131
Exclusion
range
Fixed
address
Router Servers Printers
Workstations
192.168.2.42 to
192.168.2.51
192.132.7.9
Managing DHCP Data
Allocate address dynamically: Select this option if you want to assign DHCP options to a device with a
dynamically assigned IP address.
MAC Address: The default, uneditable MAC address 00:00:00:00:00:00. All fixed addresses created from
the template have this default MAC address. You must update it to an actual MAC address when you create
a fixed address object using the template.
Comment: Fixed address template
3. Add the network template with the following values:
Name: myNetworkTemplate
Netmask: Select /24 as the subnet mask for the network using the dropdown menu
Comment: Network template for /24 network
Automatically create a reverse-mapping zone: Select this check box so that the NIOS appliance
automatically creates the corresponding reverse-mapping zone for the network.
4. Add the DHCP range templates Servers, Printers, and Workstations into the network template.
5. Add the fixed address template myFixedAddress into the network template.
6. Create a network using the network template myNetworkTemplate with the following values:
Select Network template: Click this button and select the network template myNetworkTemplate.
Network Address: Enter the IP address 192.168.2.0 of the network that you want to create using the
template.
7. To verify your configuration, from the DHCP and IPAM perspective select Networks -> + (for Templates) -> + (for
Network Templates) -> myNetworkTemplate -> View -> Range and Fixed Address Templates from the DHCP and
IPAM perspective.
The Range and Fixed Address Templates panel appears. It displays the DHCP range templates and fixed address
templates in the network template. You can filter the list to view specific types of templates (such as only fixed
address templates or only DHCP range templates).
You can use the recycle bin on the NIOS appliance to store deleted DHCP configurations. Items contained in the
recycle bin can be restored to active configuration at a later time, or can be permanently removed from the appliance.
You can use the recycle bin to restore DHCP networks, network containers, shared networks, DHCP ranges, fixed
addresses, MAC filters, and option 82 filters. NIOS does not support restoring deleted DHCP option filters.
If you do not use the recycle bin, the appliance deletes items permanently. The recycle bin is enabled by default on
the NIOS appliance. You can disable and enable the recycle bin as described in Using the Recycle Bin on page 310.
You can display the Recycle Bin panel and view all deleted items stored in the recycle bin. From the DHCP perspective,
all deleted DHCP items are shown if you have superuser privilege. If you are not a superuser, only the items deleted
by you specifically are displayed. By default, records are sorted by Name. To display the Recycle Bin panel and to view
the deleted configuration items for DHCP stored in the recycle bin:
1. From the DHCP perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
3. Click Edit -> Restore Selected Object. A warning message appears prompting you to confirm that you wish to
continue with the restore.
4. Confirm that the item was restored into the GUI by viewing the configuration where the item was originally
removed, and by confirming that the item does not appear in the Recycle Bin panel any longer.
Managing DHCP Data
You can empty the recycle bin, permanently removing all of the items displayed in the Recycle Bin panel from the
appliance. The empty functionality is available only if the recycle bin is enabled, and only to superusers. To empty
the recycle bin:
2. Click Edit -> Empty Recycle Bin. A warning message appears prompting you to confirm that you wish to empty the
recycle bin.
3. Confirm that all items were removed from the Recycle Bin panel.

Chapter 15 Configuring DHCP Services
You can configure the NIOS appliance as a full-featured DHCP server. When you configure an appliance to function as
a DHCP server, you can set operational parameters at the grid, member, network, DHCP range and individual IP
address levels. The appliance applies these parameters hierarchically. When you set parameters at the grid level, the
members, networks, DHCP ranges and IP addresses inherit these parameters, unless you override them at a more
specific level. Parameters set at the member level override grid-level settings and apply to the networks, DHCP ranges
and IP addresses that the member serves. Parameters set at the network level, override member-level settings and
apply to DHCP ranges and IP addresses within the network. Parameters set for a DHCP range override those set at
higher levels. You can also set specific parameters that apply only to a fixed addresses.
This chapter explains how to configure DHCP services in the following sections:
Configuring DHCP Overview on page 485
DHCP Configuration Checklist on page 487
Enabling DHCP and Setting Member Properties on page 489
Specifying Ping Settings on page 490
Defining Option 60 (Vendor-Class-Identifier) Match Rules on page 495
Defining Custom Options on page 495
Configuring Advanced DHCP Options on page 497
Configuring the DHCP Option Space on page 497
Adding Vendor Option Spaces on page 497
Enabling DHCP Logging on page 498
Configuring a MAC Address Filter on page 503
Configuring Option Filters on page 505
Configuring User Class Filters on page 510
Configuring a Relay Agent Filter on page 511
Managing DHCP Filters on page 513
Example DHCP Configuration File on page 509
Configuring a Relay Agent Filter on page 511
Managing DHCP Filters on page 513
Configuring DHCP Services
Configuring DHCP Failover on page 514
DHCP Failover Tasks on page 514
Creating a Failover Association on page 515
Monitoring the Failover Association on page 516
Failover Association Operations on page 516
Viewing DHCP Files on page 517
Viewing a DHCP Configuration File on page 517
Viewing DHCP Statistics on page 517
Note: Limited-access admin groups can access certain DHCP resources only if their administrative permissions are
defined. For information on setting permissions for admin groups, see Managing Administrative Permissions
for DHCP Resources on page 90
Configuring DHCP Overview
An overview of the complete DHCP configuration process is provided in the diagram below (and continued on the next
page), illustrating the main steps you will follow as you prepare your NIOS appliance for use:
Begin initial configuration of DHCP for a NIOS appliance.
Do you want to configure
grid-level DHCP properties?
No
Yes
Will DHCP failover
be used?
Configure the grid-level DHCP
properties (for example, the
DHCP options).
No
Enable the DHCP service on
an individual member.*
* Leave DHCP disabled
when configuring
members before
deployment so DHCP
services do not start
until the configuration is
complete.
- Create failover associations
- Enable DHCP service
Do you want to
configure member-level
DHCP properties?
Yes
No
Yes
Yes
Do you want to
enable DHCP service
on another member?
Configure the member-level
DHCP properties.
No
DHCP is now configured on (to be) enabled DHCP members.
Decide how the
network will be
used.
Specify the network address and netmask. - Select the member(s) to provide DHCP
service for this network.
- Specify the network address and netmask.
Continue on next page
1
2
Unmapped
Mapped
Do you want to
define network-level
DHCP properties?
Yes
Yes
Yes
Yes
No
Do you want to define
DHCP address ranges
for this network?
Specify the IP address and MAC
address for each fixed address.
Do you want to define fixed
addresses for this network?
Configure the network-level
DHCP properties.
Decide how the address
range will be allocated.
Specify the starting and ending
IP addresses.
- Specify the starting and ending
IP addresses
- Choose the failover association
Do you want to add
more ranges?
Do you want to add
more networks?
See 1 in the previous diagram
to repeat the process of adding
more networks on additional
members.
See 2 in the previous diagram to
repeat the process of enabling
the DHCP service on additional
members.
Do you have
additional members to
configure for DHCP?
Initial configuration of DHCP
networks is complete.
continued from previous page.
No
No
No
Yes
Failover range Unmapped range
Mapped
ranges
Yes
No
No
- Specify the starting and ending IP addresses.
- Choose the member to serve this address range.
DHCP Configuration Checklist
Each step in the flowchart above is included in the following checklist of steps:
Table 15.1 DNS Configuration Checklist
Complete creating configuration. Managing Appliance Operations on page 115
Decide if you want to configure DHCP properties.
Specifying Ping Settings on page 490
Enabling DHCP Logging on page 498
Decide if failover will be used. Configuring DHCP Failover on page 514
Decide how the network will be used and
configure the network.
Configuring a DHCP Network on page 461
Decide if you want to configure fixed addresses
for the network.
Configuring IP Addresses and DHCP Address Ranges on page
467
Decide if you want to define an address range for
the network.
Configuring IP Addresses and DHCP Address Ranges on page
467
Enable the DHCP service on the member. Enabling DHCP and Setting Member Properties on page 489
Configuring DHCP Properties
When you configure a NIOS appliance to function as a DHCP server, you can set certain properties that control how
the appliance operates. You can also specify the configuration information the appliance includes in its DHCP
messages. When a DHCP server assigns an IP address to a client, it can include configuration information the client
needs to connect to the network and communicate with other hosts and devices in the network.
You can set these properties at the grid level, and override them at the member, network, IP address range and fixed
address levels.
Grid Level
To configure general DHCP properties for a grid or for an independent appliance:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click General Properties.
Authoritative: Select this check box if the DHCP server is authoritative for the domain. Only authoritative
DHCP servers can send clients DHCPNACK messages when they request invalid IP addresses. For example,
a client moves to a new subnet and broadcasts a DHCPREQUEST message for its old IP address. An
authoritative DHCP server responds with a DHCPNACK, causing the client to move to the INIT state and to
send a DHCPDISCOVER message for a new IP address. Authoritative servers also respond to DHCPINFORM
messages from clients that do not receive IP addresses from the DHCP server, but need configuration
information.
Domain Name: Enter the name of the domain for which the grid serves DHCP data. The DHCP server
includes this domain name in Option 15 when it responds with a DHCPOFFER packet to a DHCPDISCOVER
packet from a client. If DDNS is enabled on the DHCP server, it combines the host name from the client and
this domain name to create the FQDN (fully-qualified domain name) that is uses to update DNS. For
information about DDNS, see Chapter 17, Configuring DDNS Updates from DHCP, on page 537.
Broadcast Address: Enter the broadcast IP address of the network to which the DHCP server is attached.
Routers: Enter the IP address of at least one router connected to the same network as the client. The DHCP
server includes this information in its DHCPOFFER messages.
DNS Servers: Enter the IP address of the DNS server(s) to which the client can send name resolution
requests. The DHCP server includes this information in its DHCPOFFER messages.
Number of Pings: Enter the number of pings that the NIOS appliance sends to an IP address to verify that it
is not in use. The range is 0 to 10, inclusive. Enter 0 to disable DHCP pings.
Ping Timeout: Enter the ping timeout value. The range is 1 to 5, inclusive.
Keep leases from deleted ranges until one week after expiration: If you select this check box, and then
delete a DHCP range, the appliance stores active leases from this range up to one week after the leases
expire. Therefore if you add a new DHCP range that includes the IP addresses of these active leases or
assign the DHCP range to another member within the grid, the appliance restores the active leases.
Ignore option list requested by client and return all defined options: Select this check box if you want the
appliance to ignore the requested list of options in DHCPREQUEST messages it receives from DHCP clients,
and to include all the configured options in DHCPOFFER messages it sends back to clients.
Configuring DHCP Properties
Enabling DHCP and Setting Member Properties
Though you can set general DHCP properties at the grid level, you enable DHCP services at the member level only.
Infoblox recommends that you configure the DHCP parameters before you enable DHCP on the NIOS appliance.
To configure general DHCP properties for a grid member:
1. From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties.
2. In the Member DHCP Properties editor, click General Properties.
Enable DHCP Server: Select this check box to enable the grid member to serve DHCP.
You can override the settings you defined at the grid level:
Authoritative setting
Domain name
Broadcast address
Router IP address
DNS server IP address
Ping settings
Lease deletion settings
Option list request settings
Network Level
To configure general DHCP properties for a network or shared network, follow the navigational path below and
override the member-level settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> Network Properties.
Address Range Level
To configure general DHCP properties for a DHCP address range, follow the navigational path below and override the
network-level settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> General DHCP Options.
Fixed Address Level
To configure general DHCP properties for a fixed address, follow the navigational path below and override the address
range settings. Restart services after you save the settings.
ip_addr -> Edit -> Fixed Address Properties -> General Properties.
Specifying Ping Settings
When a DHCP client first tries to connect to a network, it broadcasts its request for an IP address. When the NIOS
appliance receives such a request, it checks its record of assigned IP addresses and leases. Because there are a
limited number of IP addresses available, the appliance reassigns IP addresses whose leases might have expired.
Therefore, once the appliance selects a candidate IP address for lease, it sends an ICMP echo request (or ping) to the
IP address to verify that it is not in use.
If the NIOS appliance receives a response, this indicates that the IP address is still in use. The appliance then selects
another candidate IP address and sends it a ping. The appliance continues this process until it finds an IP address
that does not respond to the ping. The appliance then sends a DHCPOFFER message with the unused IP address to
the DHCP client.
Figure 15.1 Ping Overview
By default, the NIOS appliance pings the candidate IP address once and waits one second for the response. You can
change these default settings to better suit your environment. You can increase the number of pings and increase the
timeout value. For example, you can increase the timeout value to two seconds to accommodate delays caused by
problems in the network. Note that increasing any of the ping values increases the delay experienced by a client
before acquiring a lease. You can also disable the appliance from sending pings by changing the number of pings to
0.
1
5
2
4
3
Client broadcasts a
DHCPDISCOVER
message.
When the NIOS appliance
receives the DHCPDISCOVER
message, it checks its record
of IP addresses and selects an
IP address for lease.
The appliance sends the
configured number of pings
to the selected IP address.
The appliance receives a
reply, indicating that the IP
address is in use.
The appliance sends the client
a DHCPOFFER message with
the selected IP address.
ICMP Echo
Requests
ICMP Echo
Replies
The appliance selects another
IP address and sends it the
configured number of pings.
The appliance does not receive
a response within the specified
timeout, and assumes the
address is not in use.
ICMP Echo
Requests
IP Addresses
IP Addresses
Specifying DHCP Lease Times
You can change the default ping settings at the member level and at the grid level. You can define ping settings for
an entire grid, and when necessary, define different ping settings for a member. Settings at the member level override
settings at the grid level. For information about changing the default ping settings, seeConfiguring DHCP Properties
on page 488.
Specifying DHCP Lease Times
You can specify the length of time the DHCP server leases an IP address to a client. The default on the NIOS appliance
is 12 hours, and you can change this default according to your network requirements. There are a number of factors
to consider when setting the lease time for IP addresses, such as the types of resources and clients on the network,
and impact to traffic and performance. With NIOS appliances, you can set lease times at different levels, based on
these factors. You can set a default lease time at the grid level and then override this setting for specific members,
subnets, IP address ranges or fixed addresses when appropriate.
Some hosts use PXE (Preboot Execution Environment) to boot remotely from a server. When such a host starts up, it
first requests an IP address so it can connect to a server on the network and download the file it needs to boot. After
it downloads the file, the host reboots and sends another IP address request. To better manage your IP resources, set
a different lease time for PXE boot requests. You can configure the DHCP server to allocate an IP address with a shorter
lease time to hosts that send PXE boot requests, so IP addresses are not leased longer than necessary.
The following sections describe how to set lease times at the grid level and override these settings for a member,
network, address range, and fixed address.
Grid Level
To specify lease times for a grid:
1. From the DHCP and IPAM Perspective, click DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click Lease Times.
Lease Time: Enter the appropriate values in the Days, Hours, Mins and Secs fields.
Enable PXE Lease Time: Select this check box to enable the DHCP server to send a different lease time to
hosts that send PXE boot requests.
PXE Lease Time: Enter appropriate values in the Days, Hours, Mins and Secs fields. You can specify the
duration of time it takes a host to connect to a boot server, such as a TFTP server, and download the file it
needs to boot. For example, set a longer lease time if the client downloads an OS (operating system) or
configuration file, or set a shorter lease time if the client downloads only configuration changes.
Member Level
To set lease times for a grid member, follow the navigational path below and override the grid-level settings. Restart
services after you save the settings.
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> Lease Times.
Network Level
To override lease times for a network, follow the navigational path below and override the member-level settings.
Restart services after you save the settings.
Network Properties -> Lease Times.
Address Range Level
To set lease times for an address range, follow the navigational path below and override the network-level settings.
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> Lease Times.
Fixed Address Level
Give fixed addresses longer lease times since the IP address does not change. To set lease times for a fixed address,
follow the navigational path below and override the address range settings. Restart services after you save the
settings.
ip_addr -> Edit -> Fixed Address Properties -> Lease Times.
Specifying BOOTP Properties
You can configure the DHCP server to support clients that use BOOTP (bootstrap protocol) or that include the TFTP
server name option and boot file name option in their DHCPREQUEST messages. You can specify the name and/or IP
address of the boot server and name of the file the host needs to boot.
You can specify these properties at the grid, member, network, IP address range, and fixed address levels.
To deny BOOTP boot requests at the grid, member, network, IP address range, and fixed address levels select the
Deny BOOTP request checkbox.
Grid Level
To configure support for BOOTP boot requests on a grid:
2. Click BOOTP in the Grid DHCP Properties editor.
Boot Server Name: Enter the name of the server on which the boot file is stored. Clients can request for
either the boot server name or IP address. Complete this field if the hosts in your network send requests for
the boot server name. If the TFTP server is the NIOS appliance that is also serving DHCP, enter the name of
the appliance.
Next Server IP: Enter the IP address of the boot file server where the boot file is stored. Complete this field if
the hosts in your network send requests for the IP address of the boot server. If the TFTP server is the NIOS
appliance that is also serving DHCP, enter the IP address of the appliance.
Enter both the Boot Server Name and Next Server IP fields, if some hosts on your network require the boot
server name and others require the boot server IP address.
Boot File Name: The name of the file the client must download.
4. You can click Deny BOOTP request to disable the BOOTP settings and deny BOOTP boot requests at the grid level.
Member Level
To configure BOOTP properties for a DHCP member:
1. From the DHCP and IPAM Perspective, click DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> BOOTP.
2. Select the Override grid BOOTP settings checkbox to override the grid-level setting and specify the settings at the
member level.
3. Enter the Boot Server Name, the Next Server IP, and the Boot File Name. See Grid Level on page 488 for a
description of these fields.
Specifying BOOTP Properties
4. Click the Deny BOOTP request to disable the BOOTP settings and deny BOOTP boot requests at the member level.
Network Level
To configure BOOTP properties for a network or shared network:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> BOOTP.
2. Select the Override BOOTP settings checkbox to override the member-level setting and specify the settings at the
network level.
3. Enter the Boot File Name, the Next Server IP, and the Boot Server Name. See Grid Level on page 488 for a
4. Select the Override Deny BOOTP request checkbox to override the member-level setting and select the Deny
BOOTP request checkbox to deny BOOTP boot requests at the network level.
Address Range Level
To configure BOOTP properties for an IP address range:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> BOOTP.
2. Select the Override network BOOTP settings checkbox to override the network-level setting and specify the
settings at the DHCP range level.
4. Select the Override network Deny BOOTP request checkbox to override the network-level setting and select the
Deny BOOTP request checkbox to deny BOOTP boot requests at the DHCP range level.
Fixed Address
To configure BOOTP properties for a host with a fixed address:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network -> ip_addr
-> Edit -> Fixed Address Properties -> BOOTP.
2. Select the Override network BOOTP settings checkbox.
4. Select the Override BOOTP settings checkbox to override the network-level setting.
5. Select the Override network Deny BOOTP request checkbox to override the network-level setting and select the
Deny BOOTP request checkbox to deny BOOTP boot requests at the DHCP range level.
Specifying Custom DHCP Options
DHCP options describe network configuration settings and various services available on the network. These options
occur as variable-length fields at the end of DHCP messages. Each option is identified by an option code number. The
NIOS appliance supports up to 254 custom DHCP options, from option 1: subnet-mask to option 254: option-254.
You can use option spaces to define a new location in which you can store options. ISC DHCP has five predefined
option spaces: dhcp, agent, server, nwip, and fqdn. The DHCP option space has two types of options:
Predefined OptionsThese are the DHCP option codes from 1 to 254 that are allocated by the IANA and defined
by IETF standards. Examples of such options are: option 17 root-path text, option 19 ip-forwarding Boolean, and
option 13 boot-size uint16. The DHCP server knows these standard options and they are predefined on the
server. The administrator cannot redefine these options. NIOS appliances contain the Standard-DHCP option
space and its options as factory defaults.
Custom OptionsThese are the DHCP option codes from 1 to 254 that are not defined by IETF standards and are
available for private use. The administrator can enter a name when defining custom options.
The data type for some options is predefined. For example, the data type for option 1: subnet-mask is an IP address.
You cannot change the data type for this option. The data type for some other options is user-defined (at the grid
level) and can be in one of the formats shown in Table 15.2.
Table 15.2 DHCP Option Data Types
Option-254, for example, is undefined. You can associate the code number with a definition that provides some type
of information that none of the other options provides, using one of the preceding data types.
When defining a hexadecimal string for a custom DHCP option (such as option 43, vendor encapsulated options), use
only hexadecimal characters (0-9, a-f, or A-F) without spaces and separated by colons. The accepted form for a
hexadecimal string, as presented in a regular expression, is [0-9a-fA-F]{1,2}(:[0-9a-fA-F]{1,2})*
Data type Specifies
String An ASCII text string (the same as the text data type) or a list of
hexadecimal characters separated by colons
Formatting to distinguish an ASCII text string from a hexadecimal string
is important. For details, see the following section
Boolean A flag with a value of either true or false (or on or off )
IP address A single IP address
Array of IP addresses A series of IP addresses, separated by commas
You can optionally include a space after each comma
Text An ASCII text string
8-, 16-, or 32-bit unsigned integer A numeric range of the following possible values
8-bit unsigned integer: from 0 to 255
16-bit unsigned integer: from 0 to 65,535
32-bit unsigned integer: from 0 to 4,294,967,295
8-, 16-, or 32-bit signed integer A numeric range of the following possible values
8-bit signed integer: from -128 to 127
16-bit signed integer: from -32,768 to 32,767
32-bit signed integer: from -2,147,483,648 to 2,147,483,647
Specifying Custom DHCP Options
Two examples of correctly written hexadecimal strings:
aa:de:89:1b:34
1C:8:22:A3 (Note that the DHCP module treats a single hexadecimal character, such as 8 as 08.)
A few examples of incorrectly written hexadecimal strings:
:bb:45:d2:1f Problem: The string erroneously begins with a colon.
bb:45:d2:1f: Problem: The string erroneously ends with a colon.
bb:4 5:d2:1f Problem: The string erroneously includes a space between two characters (4 and 5).
bb:45:d2:1g Problem: The string erroneously includes a nonhexadecimal character (g).
The DHCP module treats incorrectly written hexadecimal strings as simple text strings, not hexadecimal strings. If the
string appears in quotes, it is a text string.
You can specify DHCP custom options at the grid level, member level, network level, DHCP address range level, or
fixed address level. The following sections describe:
Defining Option 60 (Vendor-Class-Identifier) Match Rules on page 495
Defining Custom Options on page 495
Defining Option 60 (Vendor-Class-Identifier) Match Rules
You can define option 60 (vendor-class identifier) match rules and filter on these rules.
Grid Level
To specify option 60 for a grid:
2. Click Custom Options in the Grid DHCP Properties editor.
3. Click Add to open the Option 60 (vendor -class-identifier) Match Rule dialog box, specify the following, and click
OK:
Option Space: Select a vendor-class option space from the drop-down menu.
Match Value: Enter a value for the match option (such as SUNW).
If the match value is a substring, click the Value is a Substring checkbox and enter:
Substring Offset: Enter the value of the offset at which the substring starts in the option data received
from the client. For example, enter 0.
Substring Length: Enter the length of the match value. For example, if the match value is SUNW, enter 4.
Defining Custom Options
Grid Level
To specify custom options for a grid:
2. In the Grid DHCP Properties editor, click Add to open the Option dialog box.
3. Click Select Option to open the Select Option dialog box that contains a list of option spaces, their names, option
codes, and data types.
a. Select an option and click OK. You can select from the DHCP or user-defined option spaces.
b. Enter a value for the option in the Value field following this criteria:
Enter false or true for a Boolean Flag type value.
Enter an ASCII text string, or enter a series of octets specified in hex, separated by colons.
Separate multiple values by commas. For example, to enter multiple IP addresses for netbios-name-servers,
enter a comma between each IP address.
Here are some examples of option names and correctly formatted values:
4. Click OK to close the Option dialog box.
5. Repeat this process for all desired options.
Member Level
To configure custom options for a DHCP member, follow the navigational path below and override the grid-level
settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> Custom Options.
Network Level
To configure custom options for a network or shared network, follow the navigational path below and override the
member-level settings. Restart services after you save the settings.
Network Properties -> Custom Options.
Address Range Level
To configure custom options for an address range, follow the navigational path below and override the network-level
settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> Custom Options.
Fixed Address Level
To configure custom options for a fixed address, follow the navigational path below and override the address
range-level settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click Network -> + (for Networks or Shared Networks) -> network -> padre ->
Edit -> Fixed Address Properties -> Custom Options.
Option name Value Comment
dhcp-client-identifier MyPC Double quotes are no longer needed for string type
values
dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f Series of octets specified in hex, separated by colons
for a Data-string type value
netbios-name-servers 10.1.1.5,10.1.1.10 Multiple IP addresses separated by commas
option-80 ABC123 Custom option number 80 set to the string ABC123.
Configuring Advanced DHCP Options
Configuring Advanced DHCP Options
This feature enables you to configure a variety of predefined and custom DHCP options through the NIOS GUI. It
supports vendor option spaces, vendor options, filtering based on any predefined DHCP option, and applying
conditional OR logic in filters. This provides an easy and graphical way to create complex DHCP server configurations.
The DHCP options configuration conforms to the following RFCs:
RFC 2132, DHCP Options and BOOTP Vendor Extension
RFC 3046, DHCP Relay Agent Information Option. The supported options include option 60 (Client Identifier), 21
(Policy Filter), 22 (Maximum Datagram Reassembly Size), 23 (Default IP Time-to-Live), and 82 (Support for
Routed Bridge Encapsulation).
RFC 3925, Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
RFC 2939, Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
When you configure DHCP options, you can also check for errors to ensure that you configure the option correctly.
When it detects an error, the appliance displays an error message and what you should do to correct it. The appliance
also displays an informational message if the option configuration takes more than three seconds.
If you configure a DHCP option using this feature, you can upgrade to newer releases of the Infoblox NIOS software
without reconfiguring the option.
DHCP offers up to 256 special option sets to customize the delivery of IP addresses to users and various devices such
as printers and IP phones.
Configuring the DHCP Option Space
The DHCP option space contains the predefined DHCP option spaces. You can also define custom options in the DHCP
option space as follows:
1. From the DHCP and IPAM Perspective, select Option Spaces -> right-click DHCP and select Edit Properties.
The DHCP Option Space editor appears. It lists the predefined option name, option number, and data type. It
has a Custom Options section in which you can define your own custom options and add them to the DHCP
Option Space.
2. In the Custom Options section, click Add.
The Custom Options dialog box appears. Enter the name of the option, select the option code, select the option
type, and click OK.
Adding Vendor Option Spaces
Apart from using the DHCP option space, you can also define your own option spaces and include options such as
vendor-specific options in them. You can define option spaces for devices such as VoIP phone or wireless access
points. The NIOS appliance can filter address requests by the vendor options of a requesting host. The filter instructs
the appliance either to grant or deny an address request if the requesting host matches the filter.
To add a vendor option space and include options in it:
1. From the DHCP and IPAM Perspective, select Option Spaces -> Edit -> Add Vendor Option Space.
The Vendor Option Space editor appears. In the Option Space Name field, enter an appropriate name for the
option space (such as SUNW).
2. In the Options section, click Add.
The Option dialog box appears. Enter the name of the option, select an option code from 1 to 254, select the
option type (such as ip-address, text, Boolean, and string as described in Table 15.2) and click OK. For example,
to create an option that defines the IP address of the Solaris root servers, enter the name SrootIP4, select
option code 1, and select the type as ip-address.
The option added appears in the Options list for the Option Space.
After you define an option space and add options to it, you can create option filters so that the NIOS appliance can
filter address requests using the DHCP options of the requesting host. The NIOS appliance grants or denies an
address based on whether the requesting host matches the filter. See Configuring Option Filters on page 505 to set
up and use option filters.
Configuring DNS Updates
See Chapter 17, Configuring DDNS Updates from DHCP, on page 537 for information on how to configure DNS
updates in the DHCP properties editor.
Enabling DHCP Logging
Note: This feature is not supported on Riverbed virtual grid members.
If you have a syslog server operating on your network, you can specify in which facility you want the server to display
the DHCP logging messages. You can also select the grid member on which you want to store the DHCP lease history log.
Grid Level
To specify DHCP logging options for a grid:
2. In the Grid DHCP Properties editor, click Logging.
Syslogging Facility: Select where you want the syslog server to display DHCP logging messages.
Store Leases on: Click Select member, and then select the grid member on which you want to store the
DHCP lease history log. Infoblox recommends that you dedicate a member other than the master as a
logging member. If possible, use this member solely for storing the DHCP lease history log. If you do not
select a member, no logging can occur.
Log lease events from all DHCP servers: To enable DHCP lease logging for the entire grid, select check box.
To disable DHCP lease logging for the grid, clear check box. (You can set member overrides if you want to
enable or disable lease logging per member. For additional information on these functions, see Logging
Member and Selective Logging on page 575.
Member Level
To specify logging options for a member, follow the navigational path below and override the grid-level settings.
From the DHCP and IPAM Perspective, click DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> Logging.
Defining Filters
Defining Filters
When a host requests an IP address, the NIOS appliance draws an address from an address range associated with
the network segment for that host. Because you define that range, you can thereby control the IP address (within the
defined range) and the associated TCP/IP settings that the host receives.
In Figure 15.2, three hostseach in a different subnetrequest an IP address. Each one broadcasts a DHCPDISCOVER
message, which includes its MAC address. When the router, which also functions as a DHCP relay agent, receives the
message, it adds the IP address of the interface on which the message arrives and forwards the message to the DHCP
serveror serverspreviously configured on the router. When the NIOS appliance receives the message, it uses the
ingress interface IP address of the router to determine the network segment to which the host belongs and associates
the MAC address of the requesting host with an IP address from an address range for that network.
Figure 15.2 Requesting Addresses DHCPDISCOVER Messages
The NIOS appliance replies to DHCPREQUEST messages by sending DHCPOFFER messages through the relay agent to
the requesting hosts, as shown in Figure 15.3 on page 500.
1
2
3
Address Range
10.3.1.20 -
10.3.1.200
Address Range
10.1.1.20 -
10.1.1.200
Address Range
10.2.1.20 -
10.2.1.200
10.3.1.0/24
10.2.1.0/24
10.1.1.0/24
When the NIOS appliance
receives the DHCPDISCOVER
message, it uses the ingress
interface IP address on the relay
agent to determine the network
segment to which the host belongs.
It then assigns an address to that
host from the address range
belonging to that subnet.
Furthermore, it associates the IP
address with the source MAC
address of the host.
Router
(Relay Agent)
When the relay agent
receives the
DHCPDISCOVER message,
it adds the IP address of the
ingress interface to the
message. It then forwards
the message using IP
unicast to the DHCP server.
When each host
broadcasts a
DHCPDISCOVER
message, it includes
its MAC address.
Hosts requesting
IP addresses
DHCPDISCOVER
DHCPDISCOVER
DHCPDISCOVER
10.1.1.1
10.2.1.1 10.4.1.1 10.2.1.1
10.3.1.1
NIOS Appliance
Networks
Figure 15.3 Requesting Addresses DHCPOFFER Messages
The addressing scheme depicted in Figure 15.2 on page 499 and Figure 15.3 is fairly simple: each network has a
single address range. Consequently, address assignments are fairly straightforward. However, if you have multiple
address ranges in the same network and you want to assign addresses from specific address ranges to specific hosts,
you must screen the address assignments through the use of filters. If you do not apply a filter, the NIOS appliance
assigns addresses from the highest address range to the lowest range and within each range from the highest
address to the lowest address. That is, the appliance chooses the range with the highest addresses first (that is,
closest to 255) and begins assigning addresses exclusively from that range, starting with the highest address and
finishing with the lowest (closest to 0). When all the addresses from that range are in use, it then begins assigning
addresses from the next highest range, and so on, finishing with the range with the lowest addresses. This is shown
in Figure 15.4 on page 501.
Note: After the DHCP server runs for a while, it assigns leases based on when it last used addresses, and not just on
their positions in the range.
1
2
Address Range
10.3.1.20 -
10.3.1.200
Address Range
10.1.1.20 -
10.1.1.200
Address Range
10.2.1.20 -
10.2.1.200
10.3.1.0/24
10.2.1.0/24
10.1.1.0/24
Router
(Relay Agent)
10.4.1.1
The NIOS appliance associates the
MAC address of each requesting
host with an IP address from an
address range in the same network
segment as the ingress interface of
the relay agent.
The appliance then sends unicast
DHCPOFFER messages to the
ingress interface IP addresses of the
relay agent to return to each host.
When the relay agent receives
the DHCPOFFER messages, it
broadcasts each one from the
interface on which it originally
received the corresponding
DHCPDISCOVER message (if
the broadcast flag is set to 1).
Hosts requesting
IP addresses
DHCP OFFER
DHCP OFFER
10.3.1.1
10.1.1.1
10.2.1.1
DHCP OFFER
NIOS Appliance
Networks
Defining Filters
Figure 15.4 Multiple Address Ranges without Filters
To control the assignment of addresses from specific address ranges to specific hosts, the NIOS appliance provides
the following three filters:
MAC address or vendor prefix of the requesting host
User class, as specified in the network adapter of the requesting host (DHCP option 77)
Circuit ID and remote ID as specified by the relay agent (suboptions of DHCP option 82)
One benefit of more precise address assignments is that you can then exercise more granular access control policies
based on these assignments.
When the NIOS appliance receives an address request, it checks if the request matches a filter. If it does not, the
appliance assigns an address from the address range with the highest available IP address. If the request matches
one or more filters for a range, the appliance applies the following rules:
If there are Grant filters applied to that range, the request must match one of the filters or the NIOS appliance
does not grant an address from that range.
If there are Deny filters applied to that range, the request must not match any of the filters. If the request
matches a Deny filter, the NIOS appliance does not grant an address from that range.
If an address range has a combination of Grant and Deny filters, the request must:
Match a Grant filter
Not match a Deny filter
Note: Be careful to avoid contradictory filter combinations such as denying vendor prefixes 11:22:33 and allowing
the MAC address 11:22:33:44:55:66. The machine with MAC address 11:22:33:44:55:66 cannot get an
address from this range.
Two rules govern the behavior of the NIOS appliance in relation to DHCP filters:
1. The appliance checks if any data in an address request (the MAC address or vendor prefix of the client, or DHCP
options 77 and 82) matches any filter applied to an address range.
2. The appliance checks for available addresses in address ranges containing the highest addresses first.
(Highest here means closest to 255.255.255.255, and lowest means closest to 0.0.0.0.)
1
2
Address Range 2
10.1.1.81 -
10.1.1.200
Address Range 1
10.1.1.20 -
10.1.1.80
10.1.1.0/24
If more hosts request addresses,
the appliance continues to assign
them from address range 2 the
next address being 10.1.1.118,
then 10.1.1.117, and so onuntil
all the addresses in that range are
in use.
Then the appliance starts assigning
addresses from address range 1,
starting at 10.1.1.80, and stopping
at 10.1.1.20.
The NIOS appliance assigns
addresses to both hosts from the
same address rangefirst to Host
A, and then to Host B.
Network
NIOS Appliance
Host A
Host B
Host A receives 10.1.1.120
Host B receives 10.1.1.119
These two rules can work in coordination. For example, when the NIOS appliance receives an address request, it first
checks if the request matches any filters. If it matches more than one filter assigned to different address ranges, the
appliance first applies the filter belonging to the range with the higher IP addresses. If that address does not grant
an address lease (because the filter action is Deny or all address leases in that range are already in use), the
appliance then applies the matching filter for the range with the next higher set of IP addresses. If the appliance still
has not granted a lease from either of the address ranges whose filters match data in the request and there are
unfiltered address ranges, the appliance attempts to assign an address from one of these ranges, again beginning
with the range having the highest IP addresses. Figure 15.5 presents an example illustrating the sequence in which
the NIOS appliance assigns addresses when a request matches a vendor prefix filter. For information about vendor
prefix filters, see Configuring a MAC Address Filter on page 503.
Figure 15.5 DHCP Address Assignment with Multiple Filters
1
2
3
4
No filter, but the NIOS
appliance cannot grant
the lease because all
addresses are in use.
Vendor prefix matches a
filter with action Grant,
but the appliance cannot
grant the lease because
all addresses are in use.
Vendor prefix matches
filter, but the filter action
is Deny.
No filter and at least one
address is available, so
the appliance grants an
address from this range.
10.4.4.10
10.4.4.20
10.2.2.10
10.2.2.20
10.3.3.10
10.3.3.20
Unfiltered
10.1.1.10
10.1.1.20
Address
Request
Unfiltered
FilterIf vendor
prefix =11:22:33,
grant lease
FilterIf vendor
prefix =11:22:33,
deny lease
DHCP Client
Vendor Prefix:
11:22:33
Address
Offer
NIOS Appliance
Four Address Ranges
Defining Filters
The following explains how the NIOS appliance applies filters to DHCP address requests:
Configuring a MAC Address Filter
The NIOS appliance can filter address requests by the MAC address or vendor prefix (that is, the first six hexadecimal
characters in a MAC address) of a requesting host. The filter instructs the appliance either to grant or deny an address
request if the requesting host matches the filter.
You can also configure the filter or specific MAC addresses within a filter to expire after a certain amount of time has
passed. Filter expiration is useful in situations where you want to keep filters running against updated MAC
addresses. MAC addresses may become invalid after a certain period of time has passed. You can avoid removing
invalid addresses from address filters manually by configuring the NIOS appliance to expire filters or to expire specific
addresses within filters.
Applying a MAC address filter involves the following three steps:
1. Define a filter based on either MAC addresses or vendor prefix.
2. Add the MAC addresses or vendor prefixes to the filter.
3. Apply the filter to a DHCP address range, and specify that if the MAC address or vendor prefix of the network
adapter of a requesting host matches the filter definition, the NIOS appliance either grants or denies the address
assignment.
4. Define the access privileges of limited-access admin groups for MAC address filters.
Defining a MAC Address Filter
To define a MAC address filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> Edit -> Add FIlter -> MAC
Address Filter.
2. To define a MAC address filter, type a meaningful name for the filter. If you want to filter by department, you might
name one filter Marketing, another Finance, another Engineering, and so on.
If then
the appliance receives a request that
matches a filter for one address range,
it applies the action specified in the filter for that address range. If it
does not assign an address from that range (the action is deny or the
action is grant but all addresses in that range are in use), the
appliance then checks if it can assign an address from an unfiltered
address range (if there are any), starting with the range with the
highest addresses first, as shown in Figure 15.4 on page 501.
the same filter applies to multiple
address ranges and the appliance
receives an address request matching
that filter,
it checks the address range with the highest IP addresses matching
that filter. If the appliance does not assign an address from that range,
it checks the filtered address range with the next highest IP addresses,
and so on. If it still has not assigned an address, the appliance starts
checking unfiltered address ranges (if there are any), again beginning
with the range with the highest address first.
multiple filters for the same address
range conflict with each other (one filter
grants a lease and another denies it) and
a requesting client matches both filters,
the filter denying the lease takes precedence. For example, if a
requesting client matches both a MAC address filter (granting a lease)
and a user class filter (denying a lease) for the same address range,
the appliance denies the lease. When faced with a choice to either
allow or deny a lease based on equal but contradictory filters, the
appliance takes the more secure stance of denying it.
MAC filters are valid until you explicitly configure the filter to expire. You can configure expiration when you create a
new MAC filter. This configures the entire MAC address to expire at a certain time.
To configure expiration for a MAC address filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> Edit -> Add FIlter -> MAC
Address Filter.
2. To configure when the filter must expire, type the expiration date and time in the Default MAC Address Expiration
-> Automatically Expires field. You can specify the Days, Hours, Minutes, and Seconds value to configure the
expiration time frame. If you want the MAC filter to never expire, select the Never Expire check box. By default,
the Never Expire check box is selected.
3. To enable expiration, select the Enforce Expiration Times check box.
4. To add user comments for each expiration configuration, type your comments in the Comment field.
Adding a MAC Address or Vendor Prefix to the Filter
To add a MAC address or prefix to an existing address filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> + (for MAC Address
Filters) -> filter_name -> Edit -> Add FIlter -> Add MAC Address.
2. To add a MAC address to the selected filter, enter the hexadecimal string in the MAC Address field.
or
To add a vendor prefix, enter the first six hexadecimal characters in the MAC Address field.
Note: You can format the hexadecimal strings for MAC addresses and vendor prefixes with colons or dashes.
Both of the following formats are acceptable: 11:11:11:11:11:11 and 11-11-11-11-11-11.
MAC filters are valid until you explicitly configure the filter to expire. You can enable expiration for specific MAC
addresses added to an existing filter.
To enable expiration for specific MAC addresses within a filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> + (for MAC Address
Filters) -> filter_name -> Edit -> Add FIlter -> Add MAC Address.
2. To add a MAC address to the selected filter, enter the hexadecimal string in the MAC Address field.
3. To enable expiration, click the Expiration Time -> Automatically Expires check box. By default, the Never Expires
check box is selected.
Applying a MAC Address Filter to an Address Range
To apply a MAC Address to an address range:
1. From the DHCP and IPAM Perspective, click Network -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties.
2. In the Configure DHCP Range editor, click Filter Rules.
3. Click Add beside MAC Address Filter Rule.
4. In the MAC Address Filter Rule dialog box, click Select Filter.
5. In the Select MAC Address Filter dialog box, select the MAC address filter that you previously defined and click
OK.
Defining Filters
6. In the MAC Address Filter Rule dialog box, select either Grant lease or Deny lease.
To assign addresses from the address range to requesting hosts whose MAC address (or the vendor prefix of
their MAC address) matches an entry in the MAC address filter, select Grant lease.
To refuse an address request from a host whose MAC address (or the vendor prefix of their MAC address)
matches an entry in the MAC address filter, select Deny lease.
7. Click OK.
Note: You can add other filters in combination for the same address range. See Configuring User Class Filters on
page 510 and Configuring a Relay Agent Filter on page 511.
Configuring Option Filters
The NIOS appliance can filter address requests by the vendor options (such as root-server-ip-address or
boot-file-pathname) of a requesting host. The filter instructs the appliance either to grant or deny an address request
if the requesting host matches the filter.
To apply an option filter:
1. Configure an option filter based on either the DHCP or user-defined options.
2. Add match rules to the filter so that it filters specific predefined options.
3. Apply the filter to a DHCP address range, and specify that if the DHCP or vendor options of a requesting host
matches the filter definition, the NIOS appliance either grants or denies the address assignment.
After you define an option space and add options to it, you can set up option filters to define values for the option.
For example, to handle two different client classes such as SUNW.Ultra-5_10 and SUNW.i86pc, you can define two
option filters (vendor-class_1 and vendor-class_2) and send different option values to different clients based on the
vendor-class-identifier option that you obtain from the clients.
To add an option filter:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> Option Filters -> Edit -> Add Filter -> Option
Filter.
2. Click Option Filter Properties in the Option Filter editor.
Filter Name: Enter an appropriate name for the option filter such as Sun-Blade-1000.
Option Space: Select the option space that you want to filter. All of the option spaces defined appear in the
dropdown menu. In this example, select SUNW.
4. Click Filter Options.
5. Click Add.
The Option dialog box appears Click Select Option. The Select Option dialog box appears. It lists the option
space, option name code, and option type.
6. Select an option, enter a value, and click OK. For example, select the SUNW.SrootIP4 option and enter the value
172.124.3.0 for it.
7. Click BOOTP. Specify BOOTP properties as described in Specifying BOOTP Properties on page 492.
Adding Match Rules
After you add an option filter, you can add match rules to this filter. Each match rule can filter a specific predefined
DHCP option. When the DHCP server receives a client packet that contains the option and the matching option value,
it returns the options in the class to the client.
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> + (for Option Filters) -> OptionFilter -> Edit->
Add Filter -> Add Match Rule.
2. In the Match Rule editor:
Click Match Rule Properties.
Match Option: Select an option from the dropdown menu. In this example, select Option 60:
vendor-class-identifier.
Match Value: Enter a value for the match option (such as SUNW) you selected.
Click the Value is a Substring checkbox and enter:
Substring Offset: Enter the value of the offset at which the substring starts in the option data received from
the client. For example, enter 0.
When the DHCP server receives a client packet that contains the option and the matching option value, it returns the
options in the option filter to the client.
In the following example, the mat ch i f statement is generated from data in the Match rule object. In the match
statement:
Match option is "vendor - cl ass- i dent i f i er ".
Match value is "SUNW".
Substring offset is "0" (the match value starts at the beginning of the option data received from the client).
Substring length is "4", the length of the match value "SUNW".
Applying an Option Filter to an Address Range
To add an option filter to a DHCP address range:
3. In the Option Filter Rules section, click Add. The Option Filter Rule dialog box appears.
4. In the Option Filter Rule dialog box, click Select Filter.
5. In the Select Option Filter dialog box, select the option filter that you previously defined and click OK.
cl ass "sol ar i s- ot her " {
mat ch i f subst r i ng ( opt i on vendor - cl ass- i dent i f i er ,
0, 4) = " SUNW" ;
vendor - opt i on- space SUNW;
}
Match option
Match value
Length of the match value
Substring offset
Defining Filters
6. Select either Grant lease or Deny lease.
To assign addresses from the address range to requesting hosts whose options match the filter, select Grant
lease.
To refuse an address request from a host whose options match the filter, select Deny lease.
7. Click OK.
Note: You can add other filter types in combination for the same address range. See Configuring a MAC Address
Filter on page 503 and Configuring a Relay Agent Filter on page 511.
Viewing Option Filters
To display the filter items for an option filter:
1. From the DHCP and IPAM perspective, select View -> + (for Networks) -> + (for Option Filters) -> OptionFilterName.
2. Select View -> Ranges, Fixed Addresses and Filters.
3. Select the Match Rule from the Filter dropdown menu.
The match rule that you defined, its Type, and Comment fields appear. Double-click a match rule to edit it.
The following example shows you how to create an option space, add custom options to it, create an option filter, and
a match rule to filter the options so that the NIOS appliance can filter address requests by the vendor options of the
requesting host. It can grant or deny an address request if the requesting host matches the filter.
1. Add an option space called SUNW.
Add the following options to the SUNW option space:
2. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> Option Filters -> Edit -> Add Filter -> Option
Filter.
3. In the Option Filter editor, enter the filter name as i86pc and select the Option Space SUNW from the dropdown
menu.
4. Select an option, specify a value for it, and add it to the i86pc option filter. You can select multiple options. Add
the following options to the i86pc option filter:
5. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> + (for Option Filters) -> i86pc -> Edit -> Add
Filter -> Add Match Rule.
6. In the Match Rule editor that appears:
Match Option: Select option 60: vendor-class-identifier from the dropdown menu.
Match Value: Enter SUNW.
Click the Value is a Substring checkbox and enter the following:
Substring Offset: Enter 0
Substring Length: Enter 4.
Option name Code Type
root-mount-options 1 Text
root-server-ip-address 2 IP address
root-server-host-name 3 Text
root-server-path-name 4 Text
swap-server-ip-address 5 IP address
swap-file-path-name 6 Text
boot-file-path-name 7 Text
posix-timezone-string 8 String
boot-read-size 9 16-Bit unsigned integer
Option name Code Type
root-server-ip-address 2 IP address
root-server-host-name 3 Text
root-server-path-name 4 Text
boot-file-path-name 7 Text
7. Apply the option filter i86pc to a DHCP address range. From the DHCP and IPAM perspective, Select Networks ->
Edit > Add Network -> Network. See Configuring a DHCP Network on page 461 for instructions on how to add a
network.
8. Add a DHCP range to the network. See Adding a DHCP Range on page 469.
9. In the DHCP Range editor, click Filter Rules and under Option Filter Rules, click Add.
10. The Option Filter Rule dialog box appears. Click Select Filter and select the i86pc option filter from the list. Under
If client matches this filter, select Grant lease, and click OK. The option filter appears in the Option Filter Rules list.
When the DHCP server receives a client packet that contains the option and the matching option value, it
returns the options in the option filter to the client.
Example DHCP Configuration File
The following example shows the DHCP configuration file (dhcp.conf) after you add an option space and option filters
and match lists. See Configuring Advanced DHCP Options on page 497.
opt i on space SUNW;
opt i on SUNW. ser ver - addr ess code 2 = i p- addr ess;
opt i on SUNW. ser ver - name code 3 = t ext ;
opt i on SUNW. r oot - pat h code 4 = t ext ;
After you define an option space and the format of some options, you can set up classes (option filters) to define
values for the options. For example, to handle two different client classes, you can define two classes and send
different option values to different clients based on the vendor-class-identifier option that the clients send as
follows:
cl ass " vendor - cl ass_1" {
mat ch i f subst r i ng ( opt i on vendor - cl ass- i dent i f i er , 0, 15) = " SUNW. Ul t r a- 5_10" ;
opt i on SUNW. r oot - pat h " / expor t / r oot / spar c" ;
opt i on SUNW. ser ver - addr ess 172. 17. 65. 1;
opt i on SUNW. ser ver - name " sundhcp- ser ver 17- 1";
}
cl ass " vendor - cl ass_2" {
mat ch i f subst r i ng ( opt i on vendor - cl ass- i dent i f i er , 0, 10) = " SUNW. i 86pc" ;
opt i on SUNW. r oot - pat h " / expor t / r oot / i 86pc" ;
opt i on SUNW. ser ver - addr ess 172. 17. 65. 1;
opt i on SUNW. ser ver - name " sundhcp- ser ver 17- 1";
}
When the DHCP server receives a client packet that contains the option and the matching option value, it returns the
options in the class to the client.
Configuring User Class Filters
The NIOS appliance can filter DHCP address requests by user class filters. A user class indicates a category of user,
application, or device of which the DHCP client is a member. User class identifiers are configured on DHCP clients and
are sent during a DHCP address request operation. The client includes the user class identifier in DHCP option 77
when sending DHCPDISCOVER and DHCPREQUEST messages.
By using user class identifiers, a DHCP server can screen address requests and assign addresses from select address
ranges based on the different user class IDs it receives. For example, if you assign a user class filter named mobile to
a range of addresses from 10.1.1.3110.1.1.80, the NIOS appliance selects an address from that range if it receives
an address request that includes the user class name mobile and there are still addresses available in that range.
You might want mobile users to receive these addresses because you have given them shorter lease times than other,
more stationary DHCP clients. See Figure 15.6.
Figure 15.6 Applying User Class Filtering
If the NIOS appliance receives address requests with the user class mobile and there are no available addresses in
address range 2 but there are available addresses in ranges 1 and 3, the appliance begins assigning addresses from
address range 3 (because its addresses are higher than those in range 1). Then, if all addresses in range 3 are in use,
the appliance begins assigning addresses from address range 1. If you want the appliance to assign addresses to
mobile users (that is, those identified with the user class mobile ) exclusively from address range 2, then you must
apply user class filters for mobile to address ranges 1 and 3 that deny lease requests matching that user class.
Defining a User Class Filter
To define a user class filter:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) ->+ (for Option Filters) -> OptionFilter -> Edit
-> Add Filter -> Add Match Rule.
Match Option: Select Option 77: user-class from the dropdown menu.
Match Value: Enter a value for the match option (such as SUNW) you selected.
Click the Value is a Substring checkbox and enter:
Address Range 2
10.3.1.31 -
10.3.1.80
Address Range 1
10.1.1.20 -
10.1.1.30
10.1.1.0/24
Address Range 3
10.3.1.81 -
10.3.1.160
Note: The leases for addresses in
address range 2 are shorter than
those for more stationary
computers. The intended use for
address range 2 is to provide IP
addresses for mobile users who log
in to the network for relatively short
periods of time and, therefore, do
not require longer leases.
The user class for laptop A is mobile. When it
sends DHCPDISCOVER and DHCPREQUEST
messages, it includes its user class in the
DHCP option 77 field.
The NIOS appliance has a filter that screens
address requests by user class. If the user class
for a DHCP client is mobile, the appliance assigns
it an address from address range 2.
Laptop A
User Class =mobile
Laptop A receives 10.1.1.80
from address range 2.
NIOS Appliance
Network
Substring Offset: Enter the value of the offset at which the substring starts in the option data received from
the client. For example, enter 0.
To apply a user class filter to an address range, see Applying an Option Filter to an Address Range on page 506.
Configuring a Relay Agent Filter
The typical relationship between a DHCP client, relay agent, and server (that is, the NIOS appliance) on a network is
as follows:
1. A DHCP client broadcasts a DHCPDISCOVER message on its network segment.
2. A DHCP relay agent on that segment receives the message and forwards it as a unicast message to one or
more DHCP servers (such as NIOS appliances).
3. If the NIOS appliance accepts the address request, it responds to the relay agent with a DHCPOFFER
message. (If the appliance denies the request, it does not send any response in case other DHCP servers
that might be involved respond instead.)
4. The relay agent forwards the response to the client, usually as a broadcast message.
The situation is different for individual hosts connecting to the Internet through an ISP, usually over a circuit-switched
data network.
1. A host connects to its ISPs circuit access concentration point, authenticates itself, and requests an IP
address.
2. The circuit access unit relays the address request to a DHCP server, which responds with a DHCPOFFER
message.
3. To avoid broadcasting the DHCPOFFER over the network segment on which the host made the request, the
relay agent sends the response directly to the host over the established circuit.
The NIOS appliance can screen address requests through relay agent filters (DHCP option 82) that assist the agents
in forwarding address assignments across the proper circuit. When a relay agent receives the DHCPDISCOVER
message, it can add one or two agent IDs in the DHCP option 82 suboption fields to the message. If the agent ID
strings match those defined in a relay agent filter applied to a DHCP address range, the NIOS appliance either assigns
addresses from that range or denies the request (based on previously configured parameters; that is, the Grant lease
and Deny lease parameters).
The two relay agent filters are as follows:
Agent circuit ID: This filter identities the circuit between the remote host and the relay agent. For example,
the identifier can be the ingress interface number of the circuit access unit, perhaps concatenated with the
unit ID number and slot number). The circuit ID can also be an ATM virtual circuit ID or cable data virtual
circuit ID.
Agent remote ID: This filter identifies the remote host. The ID can be the caller ID telephone number for a
dial-up connection, a user name for logging in to the ISP, a modem ID, and so on. Because the remote ID is
defined on the relay agent, which is presumed to have a trusted relationship with the DHCP server, and not
on the untrusted DHCP client, the remote ID is also presumably a trusted identifier.
Note: For information about the relay agent options, see RFC 3046, DHCP Relay Agent Information Option.
Figure 15.7 Relay Agent Filtering
Defining a Relay Agent Filter
You can enable and define either or both of the relay agent ID types. If you apply both ID types, then a relay agent
must provide both identifiers when submitting a DHCP address request.
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> Relay Agent Filters -> Edit -> Add Filter ->
Relay Agent Filter.
2. To define a relay agent filter, enter the following:
Filter Name: Type a meaningful name for the filter, such as the IP address or name of the router acting as
relay agent.
Agent Circuit ID: Select this check box and enter the ID.
Agent Remote ID: Select this check box and enter the ID.
You can enter the agent circuit ID and remote ID as an ASCII string. Alternatively, to enter binary data, you
can enter hexadecimal values in the format \xnn, where nn is any positive hexadecimal number less than or
equal to 0xff. The following examples shows an ID represented in a 17 byte text string and 6 byte binary
string:
Text String: 001122334455
Binary String: \x00\x11\x22\x33\x44\x55
The NIOS appliance checks for a
match between the remote and
circuit identifiers in the address
request and its filters for address
ranges. When it finds a match, it
assigns the DHCP client an
address from that address range.
The relay agent adds option 82 data to
DHCPDISCOVER and DHCPREQUEST
messages that it receives from the DHCP client.
DHCP Option 82 suboptions can specify a
remote ID for the DHCP client and a circuit ID
for the connection between the client and the
access point. NIOS Appliance
DHCP Server
Switched Circuit
Internet
Remote ID
Circuit ID
Network Access
Point
Relay Agent
Remote Host
DHCP Client
The Remote ID is
set on the relay
agent to identify
the remote host.
DHCPDISCOVER
DHCPDISCOVER +
Option 82 Data
Remote ID
Circuit ID
Sample remote ID types:
User name (as prompted by
network access server)
Remote caller ATM address
Modem ID for a cable data modem
Sample client ID types:
Unit-slot-port number of network
access server
ATM virtual circuit number
Cable data virtual circuit number
Applying a Relay Agent Filter to an IP Address Range
To apply a relay agent filter to an IP address range:
3. Click Add beside Relay Agent Filter Rule.
4. In the Relay Agent Filter Rule dialog box, click Select Filter.
5. In the Select Relay Agent Filter dialog box, select the relay agent filter that you previously defined and click OK.
6. Select either Grant lease or Deny lease.
To assign addresses from the address range when one or both of the relay agent ID definitions matches an
entry in the relay agent filter, select Grant lease.
To refuse an address request when one or both relay agent ID definitions matches an entry in the relay
agent filter, select Deny lease.
Note: You can add other filters in combination for the same address range. See Configuring a MAC Address Filter
on page 503 and Configuring User Class Filters on page 510.
Managing DHCP Filters
After you apply filters to an IP Address range, you can navigate to the Filter Rules section of the Configure DHCP Range
editor and use Modify to change their settings to deny or grant leases. You can also use Remove to remove a filter
from the filter list applied to the address range. You can then delete the filter if it is not applied to an address range.
To delete a filter, select it and click Edit -> Remove.
Make sure that none of the filters that you want to delete is still in use. If it is, remove the filter from any address
ranges to which it is applied.
Instead of deleting DHCP filters individually, you can select multiple filters and then delete the entire selected group.
To select a contiguous set of filters between filter-1 and filter-n :
Press and hold down the SHIFT key and click filter-n.
or
Continue pressing the left mouse button and drag the mouse from filter-1 and filter-n .
You must restart services on the grid after you remove filters.
Configuring DHCP Failover
You can configure two NIOS appliances in a DHCP failover association for service redundancy. This pairing of a
primary and secondary server is called a peer association. The peers establish a TCP connection for their
communications. They share a pool of IP addresses which they allocate to hosts on their network. The pool of
available addresses is divided evenly between the servers. DHCP failover allows either the primary or secondary
DHCP server to assume control of DHCP services in case either of the two servers fails.
DHCP Failover Tasks
Following are the tasks and guidelines for configuring DHCP failover on two DHCP servers:
1. Configure the primary and secondary DHCP servers, as described in the preceding sections in this chapter.
You can configure a failover association with two NIOS appliances, or with a NIOS appliance and an ISC
DHCP compliant server.
Configure the same operational parameters on both servers. Both servers must be able to receive
DHCPDISCOVER messages that hosts broadcast on the network.
The servers do not have to be in the same geographic location.
An appliance can participate in more than one failover association, as long as it is with a different
appliance. Each peer association must be unique.
Do not enable DHCP until after you complete the DHCP failover configuration.
2. Create the failover association, as described in Creating a Failover Association on page 515.
Identify the primary and secondary peer.
Specify a unique name for the failover association. Enter the same DHCP failover peer association name on
both the primary and secondary DHCP servers. The failover association name is case sensitive. The names
must be exactly the same on both servers.
If you change any of the DHCP failover parameters for a peer association definition, you must make the
changes on both the primary and secondary servers.
3. Configure the network for the failover association on both the primary and secondary servers, as described in
Configuring a DHCP Network on page 461.
Assign the primary and secondary servers in the failover association to the network. You can assign other
members to the network as well.
You can configure multiple failover associations in a network.
If you configured a shared network, and the subnets in the shared network contain ranges served by a
DHCP failover association, both the primary and secondary DHCP server should have the same shared
networks defined, containing the same networks, and DHCP ranges.
WARNING: If you have multiple networks/subnets that are contained in a shared network, and plan to use
DHCP failover, you must do the following:
Use failover on all of the networks in a shared network.
Specify the same peer for all the networks in your shared network.
4. Define the IP address range for the failover association on both the primary and secondary servers, as described
in Adding a DHCP Range on page 469.
Assign the failover association to the address range. Do not assign grid members to the address range.
5. Enable DHCP on the primary and secondary servers.
Configuring DHCP Failover
Creating a Failover Association
To create the DHCP failover association, perform the following steps on the primary and secondary servers:
1. From the DHCP and IPAM perspective, click Edit -> Add Failover Association.
Peer Association Name: Enter a name for the peer association.
DHCP Failover Primary
Grid Primary Server: Click Select member and select the primary peer from the drop-down menu.
Use External Primary: Select this check box to use a primary server that is not part of the grid.
External Primary IP: Enter the IP address of the primary server.
DHCP Failover Secondary
Grid Secondary Server: Click Select member and select a secondary peer from the drop-down menu.
Use External Secondary: Select this check box to use a secondary server that is not part of the grid.
External Secondary IP: Enter the IP address of the secondary server.
Max Response Delay Before Failover: Specifies how many seconds can transpire before the primary server
assumes its peer (the secondary server) is not sending messages due to failure. The default is 60 seconds.
Max Number of Unacked Updates: Specifies how many update messages the server can send before it
should receive an ACK from the failover peer. If no ACK is received after these messages are sent, failover
occurs. The default is 10 messages.
Max Client Lead Time (MCLT): Specifies the length of time that a failover peer can renew a lease without
contacting the other peer. The larger the number, the longer it takes for the peer server to recover IP
addresses after moving to the Partner Down mode. The smaller the number, the more load your servers
experience when they are not communicating. This is specified on the primary server only. The default is
3600.
Max Load Balancing Delay: Specifies the cutoff after which load balancing is disabled. The cutoff is based
on the number of seconds since the client sent its first DHCPDISCOVER or DHCPREQUEST message. For
instance, if one of the failover peers gets into a state where it is responding to failover messages, but not
responding to some client requests, the other failover peer will take over its client load automatically as the
clients retry. The default value is 3.
Load Balancing Split: Determines which server handles IP address requests. You must specify a value from
0 through 255 on the primary server only. If you specify 0, then the secondary server responds to all IP
address requests. If you specify 255, then the primary server responds to all IP address requests. Infoblox
highly recommends that you use 128, which is the default value, to enable the primary and secondary
servers to respond to IP address requests on an equal basis.
Override lease deletion setting: Select this check box to override settings at the grid and member levels.
Keep leases from deleted ranges until one week after expiration: If you select this check box and delete
a DHCP range with active leases, the appliance stores these leases up to one week after they expire.
When you add a new DHCP range that includes the IP addresses of these active leases, the appliance
automatically restores these leases.
Monitoring the Failover Association
After you configure the failover association, the peers establish a TCP connection between themselves for their
communications. They send keepalive messages and database updates every time they grant a lease. You can view
the following to monitor the failover association:
DHCP Failover Status: Click View -> DHCP Failover Status to verify that the appliances are operating and
communicating as failover peers. For each failover association, it displays the name, the host name or IP
address of the primary and secondary servers, and the operational status of each server.
IP Address Management: Click View -> IP Address Management to view the allocation status of IP addresses. The
primary server allocates IP addresses with a status Free and the secondary server allocates IP addresses with
a status of Backup. The servers always try to maintain a 50-50 split of the available addresses. Their
individual pools adjust so they each have half of the available addresses.
Failover Association Operations
When a host broadcasts a DHCPDISCOVER message, it includes its MAC address. Both the primary and secondary
peers receive this message. To determine which server allocates an IP address to the host, they each extract the MAC
address from the DHCPDISCOVER message and perform a hash operation. Each server then compares the result of its
hash operation with the configured load balancing split. This is typically set to 128, to ensure an even split between
the two servers. If the load balancing split is 128, the primary server allocates the IP address if the hash result is
between 1 and 127, and the secondary server allocates the IP address if the hash result is between 128 and 255. As
a server allocates an IP address, it updates its peer to so their databases remain synchronized.
As shown in Figure 15.8, when a host broadcasts a DHCPDISCOVER message, both the primary and secondary servers
receive the message. They perform a hash operation on the MAC address in the DHCPDISCOVER message, and the
result is 250. The load balancing split is 128. Because the hash result is 250, the secondary server responds to the
host with a DHCPOFFER message. The secondary peer allocates an IP address from its assigned pool of IP addresses.
Figure 15.8 Allocating IP Addresses
A failover occurs when any of the timers you configured expires. (See Creating a Failover Association on page 515.)
The secondary server takes over and assigns all IP addresses with the lease time set in the MCLT field. When the
primary server comes back online, it synchronizes its database with its peer before it starts allocating IP addresses.
Primary Server
When a host broadcasts a
DHCPDISCOVER message, it
includes its MAC address.
Both servers receive the DHCP
DISCOVER message. Each
server performs a hash on the
MAC address, and the result is
250.
The load balancing split is 128,
Therefore, since the hash result
is between 128 and 255, the
secondary server responds to
the host and allocates the IP
address to the host.
Secondary Server
= 250
2
3
1
Viewing DHCP Files
Viewing DHCP Files
This section describes some of the DHCP files and logs that you can view. For additional information about monitoring
DHCP, see Chapter 18, Managing IP Data IPAM, on page 557.
Viewing a DHCP Configuration File
To view a DHCP configuration file, from the DHCP and IPAM Perspective, click DHCP Members -> grid -> member -> View
-> DHCP Configuration.
Viewing DHCP Statistics
To view statistical information about a network, from the DHCP and IPAM Perspective, click Networks -> + (for
Networks) -> network -> View -> Network Statistics. This panel displays the following information about the selected
network:
Node IP: The IP address of the grid member serving DHCP in the network.
Static Hosts: The number of hosts with fixed addresses.
Dynamic Hosts: The number of hosts that were assigned dynamic IP addresses.
Available Hosts: The number of available IP addresses.
Usage: The percent of addresses in use.

Chapter 16 Using Network Discovery
This chapter provides information about network discovery and how you can use this feature to gather and manage
information about your networks. The topics in this chapter include:
About Network Discovery on page 520
Administrative Permissions on page 521
Discovery Process on page 522
Supported Discovery Methods on page 523
ICMP on page 523
NetBIOS on page 523
TCP on page 523
Full on page 524
Configuring Network Discovery on page 525
Updating the Database on page 526
Starting a Discovery on page 527
Monitoring Discovery Status on page 528
Viewing Discovered Data on page 529
Attributes of Discovered Data on page 529
Types of Discovered Data on page 529
Display of Discovered Data on page 530
Filtering Discovered Data on page 530
Searching Discovered Data on page 531
Managing Discovered Data on page 531
Managing Unmanaged Data on page 531
Adding to Existing Host on page 531
Converting Unmanaged Data on page 532
Clearing Unmanaged Data on page 532
Resolving Conflicting Addresses on page 533
Resolving a MAC Address Conflict on page 533
Resolving a DHCP Range Conflict on page 533
Configuring DNS and DHCP for a Host on page 534
Clearing the Discovered Timestamp on page 535
Using Network Discovery
About Network Discovery
Network discovery is a process of detecting active hosts on a network using protocols such as ICMP (Internet Control
Message Protocol), NetBIOS (Network Basic Input/Output System), and TCP (Transmission Control Protocol). You can
use network discovery to obtain and manage information about your networks. When you use network discovery, the
NIOS appliance detects all active hosts on the networks that you specify for a discovery. Active hosts are IP addresses
that respond to at least one request or probe in a discovery. Infoblox network discovery provides the following
discovery methods:
ICMP
NetBIOS
TCP
Full
Depending on which discovery method you use, the appliance returns some or all of the following information for the
detected hosts after a discovery is complete:
IP address
MAC address
OS (operating system)
NetBIOS name
For information about the discovery methods that the appliance supports and what information each method returns,
see Supported Discovery Methods on page 523.
The appliance then updates the database with the discovered data. You can request the appliance to update only the
unmanaged data. Unmanaged data is information that is not known to the appliance before the discovery. For
information about the guidelines that the appliance uses to update the database, see Updating the Database on
page 526
You can initiate a discovery only from the grid master using the Discovery Manager dialog box in the Infoblox GUI. The
grid master sends a discovery request to a selected grid member. The discovery request contains required
information that you configure, such as target networks and discovery method, to perform a discovery. The selected
grid member then runs a discovery on the specified networks, and reports the discovered results to the grid master.
For information on how to configure and start a discovery, see Starting a Discovery on page 527.
After a discovery, you can view and manage the discovered data in the IP Address Management panel in the DHCP
and IPAM perspective of the Infoblox GUI. For information about how you can manage the discovered data, see
Viewing Discovered Data on page 529 and Managing Discovered Data on page 531.
Figure 16.1 shows a high-level perspective of the discovery process.
Figure 16.1 High-Level Network Discovery Process
Administrative Permissions
You can initiate a discovery and manage discovered data based on your administrative permissions and
authorization. For information about administrative permissions, see Chapter 3, Managing Administrators, on page
65.
You must have read/write permission for network discovery to initiate and control a discovery. The following are
permission guidelines for initiating and controlling a discovery:
Superusers can initiate and control a discovery on all networks.
Administrators with read/write access to network discovery can initiate and control a discovery on one or more
networks to which they have read/write or read-only permission.
After a discovery is complete, the following permission guidelines apply for viewing and managing discovered data:
Superusers can view and manage all discovered data.
Administrators with read/write permission to the network can view all discovered data. They can also add
unmanaged data to existing hosts, and resolve conflicting IP addresses.
Only administrators with read/write permission to a DNS zone or specific record type can convert unmanaged
data to a host, fixed address, reservation, A record, or PTR record.
Administrators with read-only permission to the network can only view discovered data. They cannot change any
discovered data.
Note: The appliance records all discovery operations in the audit log.
Grid member returns
information about
detected active hosts.
Active hosts respond to the
discovery.
User configures a
network discovery.
Grid master sends
discovery request to grid
member that runs the
discovery.
Grid member scans the
networks.
Grid master
updates database
with discovered
data.
User views and
manages discovered
data.
2
4
5
6
7
Grid Master
10.1.1.11
Database
Discovered
Data
Discovery
Request
Network
10.0.0.0/24
Network
Devices
Grid Member
10.1.1.16
1
3
Discovery Process
Once a discovery starts, the grid member reports to the grid master the ongoing status of the discovery. It reports
discovery status such as In Progress, Paused, Ended, or Error. In the status report, the grid member also reports the
timestamp when the discovery status was last updated, and the numbers of the different types of discovered IP
addresses.
When a discovery starts, the appliance divides the IP addresses in a network into chunks, with each chunk containing
64 contiguous IP addresses. The discovery process probes each IP address in parallel and in ascending order, reports
the detected information, updates the progress report, and then moves on to the next chunk until it hits the last
chunk of IP addresses. The appliance then updates the database with the discovered data.
The discovery scans the selected networks in the order the networks appear in the Networks section of the Discovery
Manager dialog.
Figure 16.2 illustrates how a discovery works.
Figure 16.2 Discovery Process
10.0.0.130
10.0.0.131
10.0.0.132
.
.
10.0.0.194
10.0.0.65
10.0.0.66
10.0.0.67
.
.
10.0.0.129
10.0.0.1
10.0.0.2
10.0.0.3
.
.
10.0.0.64
10.0.1.130
10.0.1.131
10.0.1.132
.
.
10.0.1.194
10.0.1.65
10.0.1.66
10.0.1.67
.
.
10.0.1.129
10.0.1.1
10.0.1.2
10.0.1.3
.
.
10.0.1.64
Network 10.0.0.0/24
Network 10.0.1.0/24
Grid Master
10.1.1.11
1st IP Chunk
2nd IP Chunk
3rd IP Chunk
1st IP Chunk
2nd IP Chunk
3rd IP Chunk
Grid member scans
networks using a
splitting mechanism.
Each IP chunk in a
network contains 64
contiguous IP
addresses.
Grid member probes each IP address
in each chunk, reports detected
information, updates the progress
report, and then moves on to the next
chunk until the last IP chunk in the
last discovered network.
Grid member reports discovery
status and discovered data. Grid
master displays discovery status in
the Discovery Manager dialog, and
updates database with discovered
data.
Discovery
Request
Discovered
Data
Grid Member
10.1.1.16
Supported Discovery Methods
The two general types of network discovery are passive discovery and active discovery.
Passive discovery: Consists of methods that monitor existing network activities on a specific location by
detecting events that occur on IP addresses.
Active discovery: Consists of methods that actively scan networks and probe IP addresses. It listens for
responses from IP addresses as proof of activities.
Infoblox network discovery provides the following active discovery methods:
ICMP
NetBIOS
TCP
Full
You can run a discovery on one or more networks. The discovery scans through the specified network ranges and
probes IP addresses in each network, except for the /31 and /32 subnets as well as the network, broadcast, and
multicast address types.
ICMP
This method detects active hosts on a network by sending ICMP echo request packets (also referred to as pings) and
listening for ICMP echo responses. The ICMP discovery is a simple and fast discovery that detects whether an IP
address exists or not. It returns only the IP address and MAC address (only if the grid member running the discovery
is on the same discovered network) of a detected host. The ICMP discovery might miss some active hosts on the
network due to security measures that are put in place to block ICMP attacks.
You configure the timeout value and the number of attempts in the Discovery Manager dialog box. The ICMP discovery
method returns the following information for each detected host:
IP address
MAC address : The discovery returns the MAC address only if the grid member that is running the discovery is on
the same discovered network.
To use the ICMP discovery method, the ICMP protocol between the grid member that is performing the discovery and
the target networks must be unfiltered.
NetBIOS
The NetBIOS method queries IP addresses for an existing NetBIOS service. This method detects active hosts by
sending NetBIOS queries and listening for NetBIOS replies. It is a fast discovery that focuses on Microsoft hosts or
non-Microsoft hosts that run NetBIOS services.
You configure the timeout value and the number of attempts in the Discovery Manager dialog. This method returns
the following information for each detected host:
IP address
MAC address: Only if the discovered host is running Microsoft.
OS: This value is set to Microsoft for active hosts that have a MAC address in the NetBIOS reply.
NetBIOS name: This value is set to the name that is returned in the NetBIOS reply.
To use the NetBIOS discovery method, ports 137 (UDP/TCP) and 139 (UDP/TCP) between the grid member that is
performing the discovery and the target networks must be unfiltered.
TCP
The TCP discovery probes each active host on a list of TCP ports using TCP SYN packets. This method detects all active
hosts that generate SYN ACK responses to at least one TCP SYN. The discovery can determine the OS that is running
on a host by analyzing how the host reacts to the requests on opened and closed ports. It then uses the TCP
fingerprints to guess the OS. To obtain a TCP fingerprint, the Infoblox network discovery provides two scanning
techniques, Syn and Connect.
With the Syn technique, the discovery sends a TCP SYN packet to establish a connection on a TCP port. If the port is
open, the host replies with a SYN ACK response. The discovery does not close the port connection.
The Connect technique is a three-way TCP handshake. The discovery starts with the same process as the Syn
technique by sending the TCP SYN packet. If the host replies with a SYN ACK response, the discovery then sends a
RST packet to close the connection. If the response contains a RST flag, it indicates that the port is closed. If there is
no reply, the port is considered as filtered. The TCP discovery is a deliberate and accurate discovery method. It can
basically detect all active hosts on a network provided that there are no firewalls implemented on the network.
You can select the TCP ports, the TCP scanning technique, and configure the timeout value and the number of
attempts in the Discovery Manager dialog box. This method returns the following information for each detected host:
IP address
MAC address: The discovery returns the MAC address only if the grid member that is running the discovery is on
the same discovered network.
OS: This is set to the highest probable OS that is reported in the response.
To use the TCP discovery method, the TCP and a specific set of ports between the grid member and the discovered
networks must be unfiltered. The default set of ports is defined by the factory settings.
Full
The full discovery method is a combination of an ICMP discovery, a NetBIOS discovery, and a TCP discovery. This
method starts by sending an ICMP echo request. If no IP address on the network responds to the ICMP request, the
discovery ends. If there is at least one response to the ICMP echo request, a NetBIOS discovery starts. A TCP discovery
then follows by skipping through the active hosts that the NetBIOS discovery detects. The TCP discovery also handles
the NetBIOS detected hosts that have no MAC addresses.
You configure the timeout value and the number of attempts in the Discovery Manager dialog box. The full discovery
method returns the following information for each detected host:
IP address
MAC address
OS
NetBIOS name
To use the full discovery, all the filter and firewall requirements in the ICMP, NetBIOS, and TCP discovery methods
apply.
The following is a summary of the supported discovery methods:
Discovery Type Returned Data Considerations Mechanism
ICMP
IP address
MAC address
Use the ICMP discovery for a
rough and fast discovery.
ICMP echo request and reply
NetBIOS
IP address
MAC address
OS
NetBIOS name
Use the NetBIOS discovery for
discovering Microsoft networks
or non-Microsoft networks that
run some NetBIOS services.
NetBIOS query and reply
TCP
IP address
MAC address
OS
Use the TCP discovery for an
accurate but slow discovery.
TCP SYN packet and SYN ACK
packet
Full
IP address
MAC address
OS
NetBIOS name
Use the Full discovery for general
purposes.
1. ICMP echo request and
reply
2. NetBIOS query and reply
3. TCP SYN packet and SYN
ACK packet
Configuring Network Discovery
You select the discovery method in the Discover Manager dialog box. The method that you select to run a discovery
determines the kind of information that the discovery returns and the time that it takes to complete a discovery. For
information about how to configure the discovery method, see Starting a Discovery on page 527.
Discovery Method Considerations
The type of discovery method that you choose can affect the time that an appliance takes to complete a discovery.
If time is a concern, the following are some additional factors that you might want to consider when configuring a
discovery:
The timeout value
The number of attempts
The number of ports the discovery scans
The type of network that you want to discover
You initiate and configure a network discovery on the grid master. You can configure, start, pause, resume, or end a
discovery from the Discovery Manager dialog box in the DHCP and IPAM perspective of the Infoblox GUI. You can run
only one discovery at a time from a specified grid member. You cannot configure two grid members to run multiple
discovery jobs simultaneously. You must also predefine the networks on which you want to run the discovery.
To run a discovery, perform the following tasks:
1. Select the grid member from which you want to run the discovery. The grid member does not need to be assigned
to the discovered network or within a DHCP range.
2. Select a discovery method and the networks on which you want to run the discovery.
3. Configure the appliance to update the database with all discovered data or with only unmanaged data.
4. Start the discovery. You can view the status of the current discovery or the last discovery.
5. Select or add the TCP ports on which you want to run a TCP or Full discovery.
6. Configure the timeout value and number of attempts for the discovery.
To initiate a discovery on specific networks and manage discovered data after a discovery, do the following:
1. Configure the networks on which you want to run a discovery. For information on how to configure networks, see
Managing DHCP Data on page 459.
2. Configure a discovery using the Discovery Manager dialog box. For information on how to configure a discovery,
see Starting a Discovery on page 527.
3. View the discovered data after a discovery. For information on how to view discovered data, see Viewing
Discovered Data on page 529.
4. Manage the discovered data. For information on what you can do to manage the discovered data, see Managing
Discovered Data on page 531.
Updating the Database
When you initiate a discovery, you configure all the required information to start a discovery. After a discovery, the
appliance updates the database with the discovered data. You can configure whether to update the database with all
the discovered data or with only the unmanaged data. Unmanaged data is the information that the appliance does
not previously know about. For information about how to set this configuration, see Starting a Discovery on page
527.
When the grid master receives discovery data from the grid member, it integrates the discovered data in the database
based on the following rules:
For a discovered host that has a new IP address, the discovery creates an address labeled unmanaged.
For a discovered host that is associated with one of the following, the discovery updates the data of the
associated object:
A fixed address or host address reservation.
A host address that is not configured to serve DHCP..
A fixed address or host address with the same MAC address as the discovered host.
An A or PRT record.
For a discovered host that is associated with one of the following, the discovery updates all data except for the
MAC address, and it assigns a MAC address conflict to the IP address.
A DHCP fixed address with a different MAC address as the discovered host.
A DHCP lease with a different MAC address as the discovered host.
An Infoblox host address that is configured to serve DHCP and has a different MAC address as the
discovered host address.
For a discovered host that is part of a DHCP range but does not have a fixed or leased address or an exclusion,
the discovery assigns a DCPH range conflict to the IP address.
Database Capacity Considerations
When the grid master database reaches its maximum capacity (the maximum capacity varies based on the appliance
model), the grid master stops updating the database and requests that the grid member stop the discovery. When
the discovering grid member database reaches its capacity, the grid member pauses the discovery. The appliance
displays a dialog to inform you that the discovery pauses. The grid member resumes the discovery once the database
falls below its capacity. When a discovery pauses because of capacity issues, you cannot resume the discovery or
start a new discovery. You can check the capacity of your appliance database before starting a discovery.
To check the database capacity:
1. From the Grid perspective, click grid -> View -> Detailed Status.
or
From the Grid perspective, click + (for grid) -> + (for Members) -> member -> View -> Detailed Status.
2. The appliance displays the Detailed Status panel. You can view the status of individual grid members and
services by selecting them in the Grid panel.
For information about the database capacity, see Viewing Detailed Status on page 160.i
HA Failover Considerations
In an HA pair, if the grid master fails over to the passive node, the passive node takes over and continues with the
discovery from the last known status. If a single appliance fails, the appliance stops the discovery process and keeps
the discovery in a pause state. The appliance resumes the discovery once it starts up again.
Starting a Discovery
To initiate a discovery, you configure the settings of a discovery from the Manager tab in the Discover Manager dialog
box. The discovery request, shared by both the grid master and the grid member, contains all the required
information to run a discovery. The following is a list of requirements for configuring a discovery:
You can change a discovery configuration only on the grid master.
You must have read/write permission for network discovery in order to initiate a discovery.
Once you start a discovery, you cannot change the configuration of the discovery.
The appliance saves the configurations of the last discovery.
To start a discovery:
From the DHCP and IPAM Perspective, click Networks -> Networks -> Tools -> Manage Discovery.
From the DHCP and IPAM Perspective, click Networks -> + (for Networks) -> network, right-click the selection,
and then select Manage Discovery.
When you select a specific network and right click, the appliance populates the list of networks for the
specified network. The appliance displays the list of networks for the discovery in the Networks section.
Note: The appliance saves the network configuration of the last discovery. When you select new networks in the
Networks section, the appliance overwrites the previous list of networks that you configured for the last
discovery.
2. Click the Manager tab, and do the following:
Discovery Member: Click Select Member, and then select the grid member from which you want to run the
discovery.
Mode: Select the discovery method that you want to use for this discovery. For information about each
method and what information each method returns, see Supported Discovery Methods on page 523. If you
select TCP or Full, ensure that you configure TCP ports in the Advanced tab. The default is Full.
Networks: Select the networks on which you want to run the discovery. You can also do the following in
setting the networks:
Click Add to add new networks. In the Select Networks dialog box, select the networks (you can
multi-select more than one network) that you want to add , and then click OK.
Select a specific network in the Networks section and click Delete to delete a network in the list.
Click Move Up or Move Down to reorder the list of the networks.
Note: The appliance shows only the networks that are in the database. The discovery scans the networks
according to the order that they appear in the Networks section.
Update database with discovered data: Select this check box if you want the appliance to update the data
of existing A records, PTR records, host records, and fixed addresses. If you do not select this check box, the
appliance updates only the unmanaged objects.
Discovery Status: View the status of the current or last discovery job. This section displays information such
as the time of the last discovery update, the number of discovered address, pending addresses,
unprocessed addresses, managed addresses, unmanaged addresses, and conflicts. You can click Refresh
Status to view the latest information about the discovery status.
3. If you select TCP or Full as the discovery method in Mode, click the Advanced tab and do the following:
TCP Ports: Click Add in the TCP ports section, and then do the following in the Port dialog:
Number(1-65535): Enter the port number that you want to add to the list. You must enter a number
between 1 and 65535.
Comment : Enter the name of the port or other comments.
Click Modify to modify the existing TCP ports.
Select a TCP port and click Delete to delete a specific TCP port in the list.
TCP Scan Technique: Select the TCP technique that you want to use for the discovery. The default is Syn. For
information about what a Syn and Connect scan technique is, see TCP on page 523.
4. If you want to configure the timeout value and number of attempts for a discovery, do the following in the
Advanced tab:
Timeout (millisecs): Enter the timeout value in milliseconds for the discovery. The timeout value determines
how long the discovery waits for a response from an IP address after probing it. The minimum is 5 and
maximum is 4000. The default is 1000.
Attempts: Enter the number of times that you want the discovery to probe an IP address when scanning a
network. The minimum is 1 and the maximum is 5. The default is 2.
5. Click Start to start a discovery.
Note: Once you start a discovery, you cannot change the discovery configuration. After you click Start, the button
changes to Pause. You can click Pause to pause a discovery. When the discovery is paused, the button changes
to Resume. You can click Resume to continue the paused discovery.
You can do the following to control a discovery after you start it:
Pause: The appliance pauses the discovery at the current chunk of IP addresses.
Resume: The appliance continues the discovery from the last Pause state. It resumes the discovery at the
beginning of the first unprocessed chunk of IP addresses on the network.
End: The appliance stops and terminates the discovery. It marks the operation as complete. You cannot resume
this discovery. All discovered data remains intact in the database.
Monitoring Discovery Status
You can monitor the discovery status through the Discovery Manager dialog box. The grid member reports ongoing
discovery status to the grid master. The appliance displays the discovery status in the Discovery Status section in the
Manager tab of the Discovery Manager dialog box.
The appliance displays the following information:
Status Last Updated. This is the timestamp of the last discovery status.
Current Status. Displays the current discovery status.
Current Network: Displays the network on which the discovery is running.
Discovery was started by. Displays who initiates the discovery.
The numbers of discovered, pending, managed, unmanaged, and conflicting addresses.
The number of existing objects that are updated with the discovered data.
You can click Refresh Status any time during a discovery to view the latest discovery status.
Viewing Discovered Data
Viewing Discovered Data
After a discovery, you can view the discovered data in the IP Address Management panel in the DHCP and IPAM
perspective.
During a discovery, the grid member collects discovered data from active hosts on the networks. It then delivers the
data to the grid master. When a discovery is complete, the appliance updates the database with the discovered data
according to the configuration that you set for the discovery update.
Attributes of Discovered Data
Each discovered record has the following attributes:
IP Address
NetBIOS Name: The NetBIOS name that was discovered or a name that you manually register for the discovered
host.
MAC Address: The unique identifier of a network device. You can acquire the MAC address for hosts that are
located on the same network as the grid member that is running the discovery.
OS: The operating system of the detected host. The OS value can be one of the following:
Microsoft for all discovered hosts that has a non-null value in the MAC address using the NetBIOS discovery
method.
A value that a TCP discovery returns.
Last Discovered: The timestamp that the active host was last detected by a discovery. This data is read only.
Note: If you have read/write permission, you can edit all the attributes of the managed data (not unmanaged), except
for Last Discovered. You cannot update the attributes if you have read-only permission.
Types of Discovered Data
The following is a list of the different types of discovered IP addresses:
Used: An IP address that is known to the appliance, and has an A record, PTR record, fixed address, host
address, lease, or is within a DHCP range.
Used, Unmanaged: An IP address that is not previously known to the appliance, and does not have an A record,
PTR record, fixed address, host address, lease, or is not within a DHCP range. A used and unmanaged address
has no DNS records, no DHCP fixed or lease address, and it is not part of the DHCP range.
You can change an unmanaged address to a host, a DHCP fixed address, an A record, or a PTR record. You can
also delete an unmanaged address. All existing administrator permissions apply to the unmanaged addresses.
Used, Conflict: When a discovery detects an IP address that has either a MAC address conflict or a DHCP
conflict, it assigns a Used, Conflict status to this discovered address. The discovery displays a warning symbol
next to the IP address to indicate a conflict status.
There are two kinds of conflicts: MAC address conflict and DHCP range conflict. For information about what
constitutes a MAC address or DHCP conflict, see Updating the Database on page 526.
Unused: An IP address that has not been detected and is not associated with any network device or active host
on the network.
Note: A discovery creates only the Used, Unmanaged and Used, Conflict data.
Display of Discovered Data
For each discovered record, the appliance displays the following information in the IP Address Management panel.
Filtering Discovered Data
You can filter discovered data by the following:
All IP Addresses
Used IP Addresses
Unused IP Addresses
Unmanaged IP Addresses
Conflicting IP Addresses
Discovered Last 24 hours
The default is All IP Addresses. To filter discovered data:
1. From the DHCP and IPAM Perspective, select the Networks tab -> + (for Networks) -> network -> View -> IP Address
Management.
2. In the IP Address Management view, select the filter that you want from the Filter menu.
The appliance displays the filtered data in the IP Management panel.
IP Address The IP address on the discovered network.
Name The domain name of the IP address.
Type The type of record that the IP address represents, for example, A record or fixed address.
Status The type of discovered data. The data type can be Used; Used, Unmanaged; Used, Conflict;
and Unused. For information about the data types, see Types of Discovered Data on page
529.
Usage Shows whether the IP address is configured for DNS or DHCP.
MAC Address The discovered MAC address for the host.
NetBIOS Name The discovery returns the NetBIOS Name if you run a NetBIOS or Full discovery. For more
information, see Supported Discovery Methods on page 523.
OS The operating system of the host.
Last Discovered The time when the IP address was last discovered.
Managing Discovered Data
Searching Discovered Data
You can search discovered data using either Global Search or the search function in the IP Address Management
panel. The two search functions have different criteria and they behave differently.
Performing a global search for discovered data is the same as searching for other data in the database, except that
you cannot search for unmanaged data using the global search function. For information on how to use Global Search,
see Infoblox GUI on page 37.
To search in the IP Address Management view:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> View -> IP Address
Management.
2. Click the Search icon on the top-right corner of the IP Address Management panel. DHCP Data
3. In the Search dialog box, enter the following and then click Search.
Search for: Enter the text that you want to find in these three attributes: OS, NetBIOS name and MAC
address.
Restrict Search to: Select one of the following to restrict the search: All IP Addresses, Unused IP Addresses,
Unused IP Addresses, Unmanaged IP Addresses, or Conflicting IP Addresses.
In addition to viewing the discovered data, you can also do the following to manage the discovered data:
Manage a discovered unmanaged address by adding it to a host, converting it into managed data, or clearing its
unmanaged status. For information about why you want to convert an IP address into another type of address,
see Managing IP Data IPAM on page 557.
Resolve conflicting addresses.
Enable or disable DNS for a discovered host.
Configure the MAC address for a discovered host to be served by DHCP.
Clear discovered timestamp.
Managing Unmanaged Data
You can manage unmanaged addresses by doing one of the following:
Add to an existing host.
Convert to a fixed address, host, A record, or PTR record.
Clear the unmanaged status.
Adding to Existing Host
You can add an unmanaged address, including all its information, to an existing host. You can select the desired host
to which you want to add the unmanaged address.
To add an unmanaged address to an existing host:
Management.
2. In the IP Address Management view, select an unmanaged address that you want to add to an existing host, and
then right click.
3. Select Add to Existing Host.
4. In the Add To Existing Host dialog, click Select Host. to select the desired host to which you want to add the
unmanaged address.
5. In the Host Search dialog, enter the host name or comment, and then click Search. You can use regular
expressions, such as .*, to search for all hosts.
Note: Depending on the page size configuration, the search results are limited to the page size that you set. If
the search results exceed the page size limit, the appliance displays an error message to inform you to
refine your search criteria or to change the page size limit.
6. Select the desired host from the list, and then click OK.
7. In the Add To Existing Host dialog, select the Configure for DHCP check box if you want DHCP to serve this
address.
Note: The Configure for DHCP check box appears only if a MAC address is discovered.
8. Click OK.
Converting Unmanaged Data
You can convert an unmanaged address to a fixed address, a host, an A record, or a PTR record.
To convert an unmanaged address:
Management.
2. In the IP Address Management panel, select an unmanaged address that you want to convert, and then right
click.
3. Select Convert to.
4. In the drop-down menu, select the type of address to which you want to convert the unmanaged address. You
can select Host, A Record, PTR Record, or Fixed Address.
Depending on which type of managed object you want to convert the unmanaged address to, the appliance
displays the corresponding editor. The appliance also populates the attributes of the unmanaged address in the
editor. Enter the appropriate information in the corresponding editor.
Note: After the conversion, the status of the unmanaged address changes to Used.
Clearing Unmanaged Data
You can clear the status of unmanaged data. When you clear an unmanaged address, the status of the IP address
changes to Unused. You can clear unmanaged data at a global, per network, and per address level.
To clear an unmanaged address:
Management.
2. In the IP Address Management view, do one of the following:
Select + (for Networks) for the entire network.
Select + (for Networks) -> network for a specific network.
Select an unmanaged address in the IP Address Management panel.
3. Right click the selection.
4. Select Clear Unmanaged Data.
The appliance displays a confirmation dialog to verify that you want to clear the unmanaged address.
5. Click OK to confirm.
Note: If you select an entire network or a specific network, all the unmanaged addresses in the networks will be
cleared. After you clear the unmanaged data, the status of the IP address changes to Unused.
Resolving Conflicting Addresses
Depending on the kind of conflict that the discovered IP address has, you can do one of the following to resolve the
conflict:
For a MAC address conflict, you can choose to use the existing MAC address or the discovered MAC address.
For a DHCP range or lease conflict, you can convert the address to a fixed address, create a reservation for the
address, or remove the discovered address.
Note: Once the conflict is resolved, the status of the IP address changes to Used.
Resolving a MAC Address Conflict
You can resolve a MAC address conflict by either keeping the existing MAC address or using the newly discovered
MAC address of the discovered host.
To resolve a MAC address conflict:
Management.
2. In the IP Address Management panel, select the address that has the Used, Conflict status, and then right click
the address.
3. Select View Conflict.
The appliance displays the View Conflict dialog.
4. In the View Conflict dialog, do the following:
Description: The discovery displays the nature of the conflict.
IP Address: The discovery displays the IP address that has the conflict.
Select a MAC address: Select the MAC address that you want to use for this IP address.
Click here for conflict details: Click this link to review the conflict details. The discovery displays the
following in the Conflict Details dialog box:
Description: A description of the conflict
IP Address: The IP address that has a conflict
NetBIOS Name: The NetBIOS name of the IP address.
OS: The OS of the IP address.
Last Discovered: The timestamp of the data when it was last discovered
5. Click Resolve.
Resolving a DHCP Range Conflict
You can resolve a DHCP range conflict by doing one of the following:
Convert the address to a fixed address.
Create a reservation for the address.
Clear the discovered data.
To resolve a DHCP range conflict:
Management.
2. In the IP Address Management panel, select the address that has the Used, Conflict status, and then right click.
3. Select View Conflict.
The appliance displays the Conflict Resolution dialog box.
4. In the Resolution Options section of the View Conflict dialog box, select one of the following options to resolve
the conflict:
Create a fixed address.
Create a reservation.
Clear discovered data.
Note: When you select Clear discovered data, the discovered data is removed.
5. Click Resolve.
Note: If you make changes to a discovered address that previously had a conflict status, and the address no longer
has a conflict, the appliance displays a message to confirm that it is going to clear the non-conflict status of
this address.
Configuring DNS and DHCP for a Host
You have the option to add a discovered host to a DNS zone. If you do not add the host to a DNS zone, all the related
DNS functions, such as the host aliases, are disabled for that host. When you disable DNS for a host that was
previously in a DNS zone, other DNS information, such as time to live and host aliases, is retained but the data is not
editable or functional.
To configure a host for DNS:
Management.
2. In the IP Address Management panel, select an unmanaged address that you want to add as a new host.
3. Select Edit -> Add Resource Records -> Add Host.
4. In the Add Host editor, select the Configure for DNS check box. The check box is selected by default.
5. Click Select zone.
6. In the Select Forward Mapping Zone dialog, click the desired DNS zone.
7. Click OK.
If you want to configure the MAC address for a host address to be served by DHCP, continue on with the following
steps:
1. In the IP address section of the Add Host editor, select the IP address, and then click Add.
2. In the Host Address dialog, do the following:
IP Address: Enter the IP address that you want to be served by DHCP.
Configure for DHCP: Select this check box if you want DHCP to serve this IP address.
Match On
MAC Address: Select this to assign the IP address to a host, provided that the MAC address of the
None (reserved): Select this to reserve this particular IP address for future use, or if the IP address is
statically configured on a system (the Infoblox server does not assign the address from a DHCP
request).
MAC Address: Enter the MAC address of this IP address.
3. Click OK.
Clearing the Discovered Timestamp
You can reset the discovered timestamp for discovered data. When you clear the discovered timestamp, the IP
addresses no long appear as being detected through a discovery. You can reset the discovered timestamp at a global,
per network, and per address level. When you clear the discovered timestamp on a network, you reset the discovered
timestamp for all the IP addresses and objects that are associated with that network.
The following are some reasons for clearing the discovered timestamp:
The network topology has changed (due to addition or deletion of devices) since the last time you ran a
discovery on the network. In this case, you might want to start a discovery on a regular basis from a clean state.
You were able to reach some networks in the past, but they are now firewalled. Therefore, you can no longer
reach those networks through a discovery. In this case, you might want to remove these networks from the
discovery list as well as reset the discovered status of the IP addresses on those networks. This way, you can
prevent these IP addresses from being reclaimed if they have a discovered timestamp, and if they are no longer
discovered in the future.
A network has been re-assigned to a new site.
To clear the discovered timestamp:
1. From the DHCP and IPAM perspective, select the Networks tab -> + (for Networks) -> network -> View -> IP Address
Management.
2. In the IP Address Management panel, do one of the following:
Select + (for Networks) for the entire network.
Select + (for Networks) -> network for a specific network.
Select an IP address in the IP Address Management panel.
3. Right click the selection.
4. Select Clear Discovered Timestamp.
The Clear Discovered Timestamp confirmation dialog is displayed to verify whether you want to reset the
selected IP addresses or not.
5. Click OK.
Note: The appliance does not clear the discovered timestamp for unmanaged data.
The clear discovered timestamp operation might take a few minutes to complete if you have a large database and you
choose to clear discovered timestamps for all the networks. The operation runs in the background and the appliance
displays a confirmation dialog when the operation is completed.

Chapter 17 Configuring DDNS Updates
from DHCP
DDNS (Dynamic DNS) is a method to update DNS data (A, TXT, and PTR records) from sources such as DHCP servers
and other systems that support DDNS updates (for example, Windows 2000, 2003, and XP). This chapter provides
conceptual information about DDNS and explains how to configure NIOS appliances running DHCP and DNS to
support DDNS updates. It contains the following main sections:
Understanding DDNS Updates from DHCP on page 538
Configuring DHCP for DDNS on page 541
Specifying a Domain Name for DHCP Clients on page 542
Sending Updates to DNS Servers on page 544
Client FQDN Option (Option 81) on page 545
Generating Host Names for DNS Updates on page 547
Updating DNS for Clients with Fixed Addresses on page 548
Resending DNS Updates on page 548
Configuring DNS Update Verification on page 549
Configuring DNS for DDNS on page 552
Forwarding Updates on page 554
Authenticating Updates with TSIG on page 555
Configuring DDNS Updates from DHCP
Understanding DDNS Updates from DHCP
DHCP supports several DNS-related options (such as options 12, 15, and 81). With DDNS (Dynamic DNS) updates, a
DHCP server or client can use the information in these options to inform a DNS server of dynamic domain name-to-IP
address assignments.
To set up one or more NIOS appliances for DDNS updates originating from DHCP, you must configure at least one
DHCP server and one DNS server. These servers might be on the same appliance or on separate appliances. Three
possible arrangements for a DHCP server to update a DNS server are shown in Figure 17.1.
Figure 17.1 Relationship of DHCP and DNS Servers for DDNS Updates
1
1 2
1
2
3
2
DDNS when the DHCP server and primary DNS server
are on the same NIOS appliance.
Primary DNS
Server
DDNS Update
DDNS when the DHCP server and primary DNS server are on the different
NIOS appliances and the DHCP server updates the primary DNS server.
DDNS Update
DDNS Update Forwarded DDNS Update
Zone Transfer
Zone Transfer
Zone Transfer
Router Router
Router Router
Router
Primary DNS
Server
Secondary DNS
Server
Secondary DNS
Server
Secondary DNS
Server
DHCP
Server
DHCP
Server
DHCP Server and
Primary DNS Server
DDNS when the DHCP server and primary DNS server are on the different
appliances and the DHCP server updates a secondary DNS server.
Understanding DDNS Updates from DHCP
Here is a closer look at one setup for performing DDNS updates from a DHCP server (the steps relate to Figure 17.2):
1. When a DHCP client requests an IP address, the client sends its host name (DHCP option 12). The client also
includes its MAC address in the ethernet frame header.
2. When the DHCP server responds with an IP address, it also provides a domain name (DHCP option 15).
3. The combined host name (from the client) and domain name (from the server) form an FQDN (fully qualified
domain name), which the NIOS appliance associated with the IP address in the DHCP lease.
4. The DHCP server sends the A, TXT, and PTR records to the primary DNS server to update its resource records with
the dynamically associated FQDN + IP address.
5. The primary DNS server notifies its secondary server or servers of a change. After confirming the need for a zone
transfer, the primary server sends the updated zone data to the secondary server, completing the update.
Note: For information about zone transfers, see Allowing Zone Transfers for a Zone on page 436.
Figure 17.2 DDNS Update from a DHCP Server
Update for reverse-mapping zone
2.1.10-in-addr.arpa
PTR record: 90 jsmith-xp.corp100.com
1
2
3
4
Ethernet
Frame
Source MAC
11:11:11:11:11:11
Destination MAC
ff:ff:ff:ff:ff:ff (broadcast)
DHCP REQUEST
Option:12, host name =jsmith-xp
Update for forward-mapping zone corp100.com
A record: jsmith-xp - 10.1.2.90
TXT record: jsmith-xp -
31995a5ea0681ee5d2f6e06ad0d0477e84
Update for reverse-mapping zone
2.1.10.in-addr.arpa
PTR record: 90 - jsmith-xp.corp100.c0m
DHCP
Client
Switch
DHCP
Server
Router
Primary DNS
Server
ns1.corp100.com
Secondary DNS
Server
ns2.corp100.com
Router
DHCP OFFER
Option: 15, domain name: corp100.com
DHCP Range
10.1.2.10 -
10.1.2.100
Network
10.1.2.0/24
When the update reaches the
primary server, it updates its
zone data, increases the
corp100.com zone serial
number, and sends a NOTIFY
to ns2.
When the secondary server
receives the NOTIFY, it checks
ns1 to see if the serial numbers
for corp100.com match.
Because the serial numbers
are different, ns2 requests an
incremental zone transfer
(IXFR).
ns1 sends the changed
zone data to ns2.
Note: The DHCP server attempts to update DNS for a
particular lease before sending the DHCP ACK to the client
requesting the lease. However, if the DNS update is
unsuccessful, the DHCP client still gets its lease. The
DHCP server then continues its DNS update attempts at
predefined or user-defined intervals.
To enable a DHCP server to send DDNS updates to a DNS server, you must configure both servers to support the
updates. First, configure the DHCP server to do the following:
Provide what is needed to create an FQDN: add a server-generated host name to a server-provided domain
name, add a server-provided domain name to a client-supplied host name, or permit the client to provide its
own FQDN
Send updates to a DNS server
Then, configure the following on the DNS server:
Accept updates from the DHCP server, a secondary DNS server, or a DHCP client
If the DHCP server sends updates to a secondary DNS server, configure it to forward updates to the primary DNS
server
When setting up DDNS, you can determine the amount of information that DHCP clients provide to a DHCP server
and vice versaand where the DDNS updates originate. A summary of these options is shown in Figure 17.3.
Figure 17.3 DHCP Clients and Server Providing DNS Information and Updates
DHCPDISCOVER
DHCPOFFER with an IP address and
configuration parameters, and a domain
name (option 15) to combine with a DHCP
server-generated host name when the
server sends a DNS update.
DHCPDISCOVER with a host name
(option 12)
configuration parameters, and a domain
name (option 15) to combine with the
client-provided host name when the server
sends a DDNS update
OR
OR
OR
DHCPDISCOVER with an FQDN and
DDNS update instructions (option 81)
configuration parameters.
Setting the DHCP server to update all
resource records ensures that new A
records do not overwrite existing A records,
which can happen if two hosts send the
same FQDN.
Optionally, you can set the DHCP server to
update PTR records and allow clients to
update their own A records.
DHCP Client DHCP Server DNS Server
For DHCP to update DNS dynamically, a
DHCP client must have an FQDN. The
DHCP server can assign one or work
with the client to create one, or the client
can provide an FQDN itself.
Because clients send a DHCP server
varying amounts of DNS-related
information (nothing, a host name, or an
entire FQDN), you can configure the
server to provide whatever missing
information is necessary to construct an
FQDN, depending on how much or how
little each client provides.
You can also configure the DHCP server
to disregard DNS-related information
from clients and apply its own settings.
For example, you might want the DHCP
server to always assign the domain name
(even when a client provides its own
FQDN), or you might want only the
DHCP server to update the DNS server
(even when a client requests to make its
own updates).
DHCP server updates the DNS server with
A, TXT, and PTR records.
DHCP server updates the DNS server with
a PTR record (option 81).
DHCP client updates the DNS server with its own A record (option 81).
Configuring DHCP for DDNS
You can make the DHCP and DNS settings for DDNS at the grid level, member level, and network and zone level. By
applying the inheritance model in The NIOS appliance, settings made at the grid level apply to all members in the
grid. Settings you make at the member level apply to all networks and zones configured on that member. Settings
made at the network and zone level apply specifically to just that network and zone. When configuring independent
appliances (that is, appliances that are not in a grid), do not use the member-level settings. Instead, configure DDNS
updates at the grid level to apply to all zones and, if necessary, override the grid-level settings on a per zone basis.
To configure the DHCP server to send DDNS updates, you must perform the following tasks:
Specify the domain name that the DHCP server provides to DHCP clients for DDNS updates.
For information, see Specifying a Domain Name for DHCP Clients on page 542
Enable the DHCP server to send DDNS updates.
For information, see Configuring DDNS on the DHCP Server on page 543.
Specify the DNS servers to which the DHCP server sends the updates.
For information, see Sending Updates to DNS Servers on page 544
You can also enable the following features for DDNS updates:
The DHCP server can support option 81, the Client FQDN option. The DHCP client sends this option which
contains either the host name or FQDN of the client, and instructions on whether the client or the server should
perform the update.
For information, see Client FQDN Option (Option 81) on page 545
The DHCP server can generate an FQDN and update DNS with this FQDN when a client does not send a host
name.
For information, see Generating Host Names for DNS Updates on page 547
The DHCP server can send DDNS updates for clients with fixed addresses.
For information, see Updating DNS for Clients with Fixed Addresses on page 548
The DHCP server can make repeated attempts to sends DDNS updates.
For information, see Resending DNS Updates on page 548
The DHCP server can handle DDNS updates differently. You can configure the DHCP server to update records
only after authentication. You can adjust this so the DHCP server updates records with less stringent
authentication, or without any type of verification.
For information, see Configuring DNS Update Verification on page 549
You can define the settings for dynamic DNS at the grid level, member level, network, shared network and address
range level. Settings you define at the grid level apply to all members in the grid. Settings you make at the member
level apply to all networks on that member. Settings made at the network, shared network or address range level
apply specifically to just that network, shared network or address range. You can also enable DDNS for a fixed address
and specify a domain name for it.
Note: Whether you deploy NIOS appliance in a grid or independently, they send updates to UDP port 53. Grid
members do not send updates through a VPN tunnel; however, grid members do authenticate updates
between each other using TSIG (transaction signatures) based on an internal TSIG key.
Specifying a Domain Name for DHCP Clients
Before a DHCP server can update DNS, the DHCP server needs to have an FQDN-to-IP address mapping. When a DHCP
client requests an IP address, it typically includes its host name in option 12 of the DHCPDISCOVER packet. You can
configure the NIOS appliance to include a domain name in option 15 when it responds with a DHCPOFFER packet. The
appliance then combines the host name from the client and the domain name you specify to create the FQDN that it
uses to update DNS.
You can enter a domain name for a grid, member, network, shared network, address range and fixed address.
Grid Level
To add the domain name at the grid level:
2. In the General Properties section of the Grid DHCP Properties editor, enter the Domain Name in the text field.
Member Level
To override the grid-level settings and add the domain name at the member level:
Properties.
2. Click General Properties and enter the member level Domain Name in the text field.
Network Level
To add the domain name for a network or shared network, follow the navigational path below and override the
member-level settings.
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> General DHCP Options.
Address Range Level
To add the domain name for a range of IP addresses, follow the navigational path below and override the
network-level settings.
addr_range -> Edit -> DHCP Range Properties -> General DHCP Options.
Fixed Address Level
To add the domain name for a fixed address, follow the navigational path below and override the address range-level
settings.
ip_addr -> Edit -> Fixed Address Properties -> General Properties.
Configuring DDNS on the DHCP Server
You can enable DDNS on a grid, member, shared network, network, address range and fixed address.
Grid Level
To enable DDNS on a grid:
3. In the DNS Updates section, select Enable dynamic DNS updates.
Member Level
To enable DDNS for a member, follow the navigational path below and override the grid-level settings. Restart service
after you save the settings.
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid ) -> member -> Edit -> Member DHCP
Properties -> DNS Updates.
Network Level
To enable DDNS on a network, follow the navigational path below and override the member-level settings. Restart
service after you save the settings.
Network Properties -> Network Properties -> DNS Updates.
Address Range Level
To enable DDNS for a range of IP addresses, follow the navigational path below and override the network-level
settings. Restart service after you save the settings.
addr_range -> Edit -> DHCP Range Properties -> DNS Updates.
Fixed Address Level
To enable DDNS for a fixed address, follow the navigational path below and override the address range-level settings.
Restart service after you change the settings.
ip_addr -> Edit -> Fixed Address Properties -> DNS Updates.
Sending Updates to DNS Servers
The DHCP server can send DDNS updates to DNS servers in the same grid and to external DNS servers. You specify
the DNS servers at the grid level only.
Sending Updates to DNS Servers in the Grid
When you enable the appliance to send updates to grid members, you must specify the zones and views to be
updated. For information about views, see Using Infoblox DNS Views on page 337. To configure the DHCP server to
send updates to DNS servers in the same grid:
2. Click DNS Updates.
Grid Forward-Mapping Zones to Update: Specify the zones to be updated.
Internal updates to: Click Select View to open the Select DNS View dialog box. Select the view to receive
updates and click OK.
Enable dynamic DNS updates: Select check box.
Sending Updates for Zones on an External Name Server
The DHCP server can send dynamic updates to an external name server that you specify. You can specify the zone to
be updated and the IP address of the primary name server for that zone. You can add information for a forward and
reverse zone. The DHCP server updates the A record in the forward zone and the PTR record in the reverse zone. You
can also use TSIG (transaction signatures) to secure communications between the servers. For information about
TSIG, see Authenticating Updates with TSIG on page 555.
To send updates to a DNS server that is external to your grid:
2. Click DNS Updates.
3. To update a forward zone, click Add beside External Forward Zones to Update.
4. In the External Forward Zone dialog box, enter the following:
Zone Name: Enter the name of the zone that receives the updates.
Name Server Address: Enter the IP address of the primary name server for that zone.
Use TSIG: Select if you want to use TSIG. You can either specify an existing key or generate a new key.
To specify an existing key:
Key name: Enter the domain name for the zone of this TSIG key. The Key Name entered here must
match the TSIG key name on the external name server.
Key: Type or paste the key.
To generate a new key, click Generate.
5. Click OK to close the External Forward Zone dialog box.
6. To update a reverse zone, click Add beside External Reverse Zone.
7. In the External Reverse Zone dialog box, enter the following:
Zone Name: Enter the name of the zone that receives the updates.
Name Server Address: Enter the IP address of the primary name server for that zone.
Use TSIG: Select if you want to use TSIG. You can either specify an existing key or generate a new key.
To specify an existing key:
Key name: Enter the domain name for the zone of this TSIG key. The Key Name entered here must
match the TSIG key name on the external name server.
Key: Type or paste the key.
To generate a new key, click Generate.
8. Click OK to close the External Reverse Zone dialog box.
9. Select Enable dynamic DNS updates.
Client FQDN Option (Option 81)
When a DHCP client sends DHCP DISCOVER and DHCP REQUEST messages, it can include option 81, the Client FQDN
option. This option contains either the host name or FQDN (fully qualified domain name) of the client, and
instructions on whether the client or the server performs the DDNS update.
The DHCP server can support this option and use the host name or FQDN that the client provides for the update. It
can also allow or deny the clients request to update DNS, according to the administrative policies of your
organization. The DHCP server indicates its response in the DHCP OFFER message it sends back to the client.
Sending Updates with Option 81 Enabled
When you enable the DHCP server to support option 81, it uses the information provided by the client to update DNS
as follows:
When a DHCP client sends a DHCP request with option 81, it can include either the FQDN or only the host name
of the client.
If the request includes the FQDN, the DHCP server uses this FQDN to update DNS.
If the request includes the host name, the DHCP server provides the domain name. It combines the host
name of the client and the domain name to create an FQDN for the client. It then updates DNS with the
FQDN it created. (You can enter the domain name in the General page of the DHCP Properties window. For
information, see Specifying a Domain Name for DHCP Clients on page 542.)
When a DHCP client sends a DHCP request with its host name (option 12), the DHCP server adds the domain
name you specified to create an FQDN for the client. It then updates DNS with the FQDN it created. For
information about entering the domain name, see Specifying a Domain Name for DHCP Clients on page 542.
When a DHCP client does not send a host name, the DHCP server provides a lease but does not update DNS.
You can configure the DHCP server to generate a host name and update DNS as described in Generating Host
Names for DNS Updates on page 547.
If multiple DHCP clients specify the same FQDN or host name, the DHCP server allocates leases to the clients,
but updates DNS only for the client that first sent the request. When it tries to update DNS for the succeeding
clients, the update fails.
Sending Updates from DHCP Clients or Server
When you enable the DHCP server to support option 81, you must decide if you want the DHCP server to allow clients
to update DNS. If you allow the client to update DNS, then the client updates its A record only. The DHCP server always
updates the PTR records. You can configure the DHCP server as follows:
The DHCP server can allow clients to update DNS when they send the request in option 81. This is useful for
small sites where security is not an issue or in sites where clients move from one domain to another and want to
maintain the same FQDN regardless of administrative domain.
If you configure the DHCP server to allow clients to perform DNS updates, you must also configure the DNS
server to accept these updates from clients. Note that multiple clients can use the same name, resulting in
multiple PTR records for one client name.
When a lease expires, the DHCP server does not discard the A record if it was added by the client.
The DHCP server can refuse the DHCP clients request to update DNS and always perform the updates itself.
When the DHCP server updates DNS, it uses the FQDN provided by the DHCP client. Select this option if your
organization requires tighter control over your network and does not allow clients to update their own records.
If you do not enable support for option 81 and a client includes it in a DHCP request with its FQDN, the DHCP server
does not use the FQDN of the client. Instead, it creates the FQDN by combining the host name from the client with the
domain name specified in the DHCP Properties dialog box.
Configuring Support for Option 81
You can define the settings for option 81 at the grid level, member level, network and shared network level.
To enable support for option 81 at the grid level:
Enable option 81 support: Select check box.
DHCP server updates DNS only if requested by client: Select this check box to allow clients to update DNS
when they request it.
Or
DHCP server always updates DNS: Select this check box to allow only the DHCP server to update DNS,
regardless of the requests from the DHCP clients.
To configure option 81 settings for a member, follow the navigational path below and override the grid-level settings:
To configure option 81 settings for a network or shared network, follow the navigational path below and override the
member-level settings:
Network Properties -> DNS Updates.
When a lease expires, the DHCP server removes the A and PTR records that it updated. It does not remove any records
that the client updated.
Generating Host Names for DNS Updates
Some clients do not send a host name with their DHCP requests. When the DHCP server receives such a request, its
default behavior is to provide a lease but not update DNS. You can configure the DHCP server to generate a host name
and update DNS with this host name when it receives a DHCP REQUEST message that does not include a host name.
It generates a name in the following format: DHCP-WWW-XXX-YYY-ZZZ, where WWW-XXX-YYY-ZZZ is the IP address of
the lease. For example, if this feature is enabled and the DHCP server receives a DHCP REQUEST from a DHCP client
with IP address 10.1.1.1 and no host name, the DHCP server generates the name dhcp-10-10-10-1 and uses this
name for the DDNS update.
You can define the host name settings at the grid level, member level, network, shared network, and DHCP address
range level.
Grid Level
To allow the DHCP server to generate a host name at the grid level:
Generate hostname if not sent by client: Select check box.
Member Level
To allow the DHCP server to generate a host name at the member level, follow the navigational path below and
override the grid-level settings:
Network Level
To allow the DHCP server to generate a host name for a shared network or network, follow the navigational path below
and override the member-level settings:
Address Range Level
To allow the DHCP server to generate a host name for an address range, follow the navigational path below and
override the network-level settings:
addr_range -> Edit -> DHCP Range Properties -> DNS Updates.
Updating DNS for Clients with Fixed Addresses
By default, the DHCP server does not update DNS when it allocates a fixed address to a client. You can configure the
DHCP server to update the A and PTR record of clients with a fixed address. When you enable this feature and the
DHCP server adds A and PTR records for a fixed address, the DHCP server never discards the records. When the lease
of the client terminates, you must delete the records manually.
You can define the fixed address settings at the grid level, member level, network and shared network level.
To send dynamic updates for fixed addresses at the grid level:
Update fixed addresses: Select check box.
To send dynamic updates for fixed addresses at the member level, follow the navigational path below and override
the grid-level settings:
To send dynamic updates for fixed addresses in a network or shared network, follow the navigational path below and
override the member-level settings:
Resending DNS Updates
You can enable the DHCP server to make repeated attempts to send DDNS updates to a DNS server. The DHCP server
first tries to update DNS for a particular lease before sending the DHCP ACK to the client requesting the lease. If the
update fails, the DHCP server still provides the lease and sends the DHCP ACK to the client. The DHCP server then
continues to send the updates until it is successful or the lease of the client expires. You can change the default retry
interval, which is five minutes.
You can enable this feature at the grid and member level only.
To enable the DHCP server to resend DNS updates at the grid level:
Retry updates when the DNS server becomes available: Select check box.
Retry interval (minutes): You can optionally set the retry interval. The default is five minutes.
To enable the DHCP server to resend DNS updates at the member level, follow the navigational path below and
override the grid-level settings:
Configuring DNS Update Verification
The DHCP server can handle DNS updates differently, depending on how stringently you configure record handling.
You can configure the DHCP server to update records only after passing verification. You can adjust the way DHCP
handles updates so the DHCP server updates records after passing less stringent verification requirements, or
without any type of verification.
To provide a measure of protection against unintentional changes of DNS data, NIOS appliances support the
generation and use of DHCID (TXT) records, as described in IETF draft, draft-ietf-dhc-dhcp-dns-12.txt and by the ISC
(Internet Systems Consortium). When DHCP updates or deletes an A record, the corresponding TXT record is checked
first to verify the authenticity of the update. The TXT record is based on a hash of the DHCID which is unique to each
client, usually based in part on the MAC address. If the client requests an update to DNS, the DHCP server first checks
the TXT record to verify that it matches the client that originally inserted the record. This process provides assurance
that the updates are from the same client. These security checks are based upon inserting a cryptographic hash of
the DHCID (DHCP Client Identifier) into a DNS TXT RR and then verifying that value before updating. For example, a
sample client update adds the following records in DNS:
However, your DNS configuration might require that the NIOS appliance handle DNS record updates differently than
described in draft-ietf-dhc-dhcp-dns-12.txt. Your specific requirements might benefit from less-stringent verification
of the DHCID, or might require skipping verification entirely. Verification checks might cause complications in some
specific cases described below:
Mobility: The TXT record is based on the DHCID unique to each client and is usually based on the MAC address
of the interface. Devices such as laptops that connect from both the wired and wireless networks have different
MAC addresses and different DHCID values for each interface. In this scenario, after either one of the network
interfaces inserts a DNS record, updates are allowed from that interface only. This results in a disruption of
service for DDNS updates when roaming between wired and wireless networks.
Migration: The second problem occurs during a migration from non-ISC based systems to ISC systems. For
example, if the user is migrating from a Microsoft-based system, the clients have A and PTR records in the DNS
updates but no TXT records. As a result, new DNS updates fail after the migration. Past workaround of this issue
was to delete DDNS records from the appliance after migration was complete.
Mixed Environments: The final problem occurs in mixed ISC and non-ISC environments. For example, assume
that both Microsoft and ISC DHCP servers update DNS records on the appliance. Since the Microsoft DHCP
server does not insert the TXT records, updates from ISC-based systems fail while updates from the Microsoft
DHCP server are committed into the database.
oxcart.lo0.net. 21600 IN A 172.31.1.20
oxcart.lo0.net. 21600 IN TXT "313ce164780d34b91486b7c489ed7467e6"
20.1.31.172.in-addr.arpa. 21600 IN PTR oxcart.lo0.net.
The NIOS appliance offers four modes to handle DNS updates as described in Figure 17.4 on page 550:
Figure 17.4 DNS Update Verification Mode
Depending on your expected usage, you must carefully consider the various options for update verification. The
following section illustrates recommendations for each verification option:
Standard ISC: This method is the most stringent option for verification of updates. This is the default.
ISC Transitional: This method is useful during migrations from systems that do not support the TXT record to
systems that are ISC-based.
Check TXT only: This method is useful for the roaming laptop scenario. The NIOS appliance checks that a TXT
record exists, but does not check the value of the TXT record.
No TXT record: This method should be used with caution because anyone can send DNS update and overwrite
records. This method is useful when both ISC and non-ISC-based DHCP servers and clients are updating the
same zone. Infoblox recommends that you allocate a separate DNS zone for this authentication method, as a
precaution.
Note: In certain situations, when a DHCP lease expires, the DHCP server might remove the TXT record even if there is
no A record.
Mode
A Record at Lease
Grant
TXT Record at Lease
Grant
Lease Grant Action Lease Expire Action
Standard ISC Exists Must match Delete A
Add A
Add PTR
Delete PTR
Delete A, TXT if TXT
matches and no
other A RRs
No A record No check Add A, TXT
Add PTR
Check TXT only Exists Must exist Delete A, TXT
Add A, TXT
Add PTR
Delete PTR
Delete A if TXT exists
and no other A RRs
Add PTR
ISC Transitional Exists No check Delete A, TXT if
exists
Add A, TXT
Add PTR
Delete PTR
Delete A, TXT if TXT
matches and no
other A RRs
Add PTR
No TXT record Exists No check Delete A
Add A
Add PTR
Delete PTR, A
No A record No check Add A
Add PTR
You can enable this feature at the grid level. To configure TXT record handling on the DHCP server:
1. From the Grid perspective, click Grid -> + (for grid) -> + (for Services) -> DHCP -> Edit -> Service Properties.
3. In the DNS TXT (DHCID) record handling section, do the following:
ISC: Select this check box to enable standard ISC (Internet Standards Consortium) handling for DNS
updates. Specifically, A records are modified or deleted only if the TXT records match. This option is the
default setting on the appliance.
ISC Transitional: Select this check box to enable less stringent handling of DNS updates. Specifically, the
NIOS appliance enables you to add or modify A records whether or not TXT records exist. It checks whether
a TXT record exists and then processes the DDNS. If the appliance does not find a TXT record, it adds the
record.
Check Only: Select this check box to enable minimal checking of DNS updates. Specifically, A records are
modified only if a TXT record exists. The NIOS appliance checks that a TXT record exists, but does not check
its value.
No TXT Record: Select this check box to disable TXT record checking. Specifically, A records are added,
modified, or deleted whether or not the TXT records match. No TXT records are added, and existing TXT
records are ignored.
Configuring DNS for DDNS
For security reasons, a DNS server does not accept DDNS updates by default. You must specify the sources from which
you want to allow the DNS server to receive updates. For protection against spoofed IP addresses, you can use TSIG
(transaction signatures) to authenticate and verify updates (see Authenticating Updates with TSIG on page 555).
Enabling the DNS Server to Receive Updates
In addition to enabling the DHCP server to send DDNS updates (see Configuring DHCP for DDNS on page 541), you
must also enable the DNS server to receive them. You can enable the DNS server to receive updates at the grid,
member, and zone levels. Applying the Infoblox inheritance model, settings at the grid level apply to all zones on all
members, settings at the member level apply to all zones on that member, and settings at the zone level apply
exclusively to that zone.
Note: Whether you deploy NIOS appliances in a grid or independently, they send updates to UDP port 53. Grid
members do not send updates through a VPN tunnel. Grid members do, however, authenticate updates
Receiving Updates Grid-Level Settings
You can configure the DNS server at the grid level to control the DHCP servers from which all grid members are allowed
to receive DDNS updates. Likewise, you can configure a DNS server receiving forwarded updates from another DNS
server. These are the DNS servers from which the grid members are allowed to receive forward updates (see
Forwarding Updates on page 554).
If you configure an independent (single) appliance or independent HA pair (an appliance or pair of appliances not
part of a grid), do not use the member-level settings. Instead, configure updates at the grid level so they apply to all
zones. If necessary, override the grid-level settings on a per zone basis.
Note: To authenticate DDNS updates see Authenticating Updates with TSIG on page 555.
To allow or deny the DNS server to receive updates for all zones:
2. In the Grid DNS Properties editor, click Updates.
3. Click the Override Grid Update Settings check box, and then in the Allow dynamic updates from section, click
Add.
4. Choose from the following information, and then click OK.
IP Address: Select IP Address and enter the IP address from which you want to allow or deny updates. If this
is the IP address of a DHCP server on a single NIOS appliance, enter the IP address of its LAN interface. If the
DHCP server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS
servers on the same NIOS appliance, you must still enter the IP address of the interface that serves DHCP
(which, by the way, is the same interface that also serves DNS).
Network and Subnet Mask: Select Network, enter the IP Address the network and choose a Subnet mask
from the drop-down list. This might be a subnet containing DHCP clients thatafter receiving their address
leasessends updates directly to the DNS server. For details, see Client FQDN Option (Option 81) on page
545.
Any: Select this option to allow all updates.
Permission: Select Allow to permit updates from the specified IP address or network. Select Deny to deny
updates from the specified IP address or network.
Configuring DNS for DDNS
Receiving Updates Member-Level Settings
You can control the DHCP servers from which each grid member is allowed to receive DDNS updates.
To allow or deny the DNS server to receive updates at the member level:
1. From the DNS perspective, click DNS Members -> grid -> member -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Updates.
3. Click the Override Grid Update Settings check box, and then in the Allow dynamic updates from section, click
Add.
4. Choose from the following information, and then click OK.
Network: Select Network, and enter the network IP Address the network. Then choose a Subnet mask from
the drop-down list. This might be a subnet containing DHCP clients thatafter receiving their address
545.
Receiving Updates Zone-Level Settings
You can control the DHCP servers from which an individual zone is allowed to receive DDNS updates.
To allow or deny the DNS server to receive updates at the zone level:
1. From the DNS perspective, click Infoblox Views -> view -> + (for Forward Mapping Zones or Reverse Mapping
Zones) -> zone -> Edit -> Zone Properties.
2. In the Zone Properties editor, click Updates.
3. Click the Override member Update settings check box, and then in the Allow dynamic updates from section, click
Add.
4. Choose from the following information, and then click OK:
Network and Subnet Mask: Select Network, enter the IP Address the network and choose a Subnet mask
from the drop-down list. This might be a subnet containing DHCP clients thatafter receiving their address
545.
Forwarding Updates
When a secondary DNS server receives DDNS updatesbecause it cannot update zone data itselfit must forward
the updates to the primary server. In such situations, you must enable the secondary server to receive updates from
the DHCP server, and then forward them to the primary DNS server.
To configure the secondary server to receive and forward updates for all zones:
1. From the DNS perspective, click DNS Members -> grid -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Updates.
3. In the Allow dynamic updates from section, click Add.
IP Address: Select IP Address and enter the IP address from which you want to allow updates. If this is the IP
address of a DHCP server on a single NIOS appliance, enter the IP address of its LAN interface. If the DHCP
server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS servers
on the same NIOS appliance, you must still enter the IP address of the interface that serves DHCP (which, by
the way, is the same interface that also serves DNS).
Network: Select Network and enter the network IP Address. Then choose a Subnet mask from the
drop-down list. This might be a subnet containing DHCP clients thatafter receiving their address leases
sends updates directly to the DNS server. For more information, see Client FQDN Option (Option 81) on
page 545.
Permission: Select Allow to permit updates from the specified IP address or network.
5. Click the Override Grid Updates Forward Settings check box, and click the Forward updates from secondary name
servers check box.
6. To add a secondary name server to the list, click Add, specify server information similar to step 4, and then click
OK.
To forward updates for a single zone:
1. From the DNS perspective, click Infoblox Views -> view -> + (for Forward Mapping Zones or Reverse Mapping
Zones) -> zone -> Edit -> Zone Properties.
2. In the Zone Properties editor, click Updates, and then click the Override member updates settings check box.
3. In the Allow dynamic updates from section, click Add.
IP Address: Select IP Address and enter the IP address from which you want to allow updates. If this is the IP
address of a DHCP server on a single NIOS appliance, enter the IP address of its LAN interface. If the DHCP
server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS servers
on the same NIOS appliance, you must still enter the IP address of the interface that serves DHCP (which, by
the way, is the same interface that also serves DNS).
Network: Select Network and enter the network IP Address. Then choose a Subnet mask from the
drop-down list. This might be a subnet containing DHCP clients thatafter receiving their address leases
sends updates directly to the DNS server. For details, see Client FQDN Option (Option 81) on page 545.
Permission: Select Allow to permit updates from the specified IP address or network.
5. Click the Override Grid Updates Forward Settings check box, and click the Forward updates from secondary name
servers check box.
6. To add a secondary name server to the list, click Add, specify server information like that in step 4, and then click
OK.
Authenticating Updates with TSIG
Authenticating Updates with TSIG
The NIOS appliance can use TSIG (transaction signature) keys to authenticate DDNS updates. TSIG uses the MD5
(Message Digest 5) algorithm and a shared secret key to create an HMAC (hashed message authentication code)
sometimes called a digital fingerprintof each update. Both the DHCP server sending the update and the DNS server
receiving it must share the same secret key. Also, it is important that the time stamps on the TSIG-authenticated
updates and update responses be synchronized, or the participants reject them. Therefore, use an NTP server to set
the time on all systems involved in TSIG authentication operations.
The TSIG key that you use can come from several places:
You can use the key generation tool described in this section to create a new TSIG key to authenticate updates
from the DHCP server.
You can enter (copy and paste) a TSIG key that you previously generated for another purpose, such as for zone
transfers.
If the DHCP server is on a separate appliance and a TSIG key was previously generated on that appliance, you
can enter (copy and paste) that TSIG key onto the local DNS server.
Although the TSIG key value that the DHCP and DNS servers use must be the same, the name of the key can be
different. However, to avoid confusion, the rule of thumb is to use the same key name for both DHCP and DNS.
Note: Whether you deploy NIOS appliance in a grid or independently, they send updates to UDP port 53. Grid
members do not send updates through a VPN tunnel. However, grid members do authenticate updates
This section describes how to generate a TSIG key and where to apply it to authenticate updates between the DHCP
and DNS servers.
To generate a TSIG key at the grid, member, or zone level:
1. Open the DNS perspective, and do one of the following:
For a grid:
Click DNS Members -> grid -> Edit -> Grid DNS Properties. Then, click Updates and in the Allow TSIG dynamic
updates for section, click Add.
For a member:
Click DNS Members -> grid -> member -> Edit -> Member DNS Properties. Then, click Updates, Override id grid
update settings, and in the Allow TSIG dynamic updates for section, click Add.
For a zone:
Click Infoblox Views -> view -> + (for Forward Mapping Zones or Reverse Mapping Zones) -> zone -> Edit ->
Zone Properties. Then, click Updates -> Override Grid Settings, and in the Allow TSIG dynamic updates for
section, click Add.
Note: Although generating a key in the same part of the GUI where you want to use it is an efficient approach,
you can copy a key generated in any TSIG Key dialog boxor, for that matter, a key generated on a
completely different applianceand paste it in any part of the GUI where you want to use it.
2. In the TSIG Updater Item dialog box, enter the following:
Key name: Type a useful name for the key, such as the name of the grid or grid member using the key, or the
name of the zone being updated. The Key Name entered here does not have to match the TSIG key name on
the DHCP server sending the updates, but using the same name can ease coordination when setting up the
DHCP and DNS servers.
Key: Enter a key in the text field, or click the Generate to generate a TSIG key.
Note: Copy the key value for use when configuring TSIG on the DHCP and DNS servers.
To apply TSIG authentication for updates that the DHCP server sends:
1. From the DHCP and IPAM perspective, click DHCP -> grid -> Edit -> Grid DHCP Properties.
3. In the External Forward Zones to Update section, click Add, specify the following information, and click OK:
Zone Name: Type the name of the zone for which you want to authenticate updates using TSIG.
Name Server Address: Type the IP address of the DNS server to which you want the DHCP server to send the
updates.
Use TSIG: Select check box to activate the next two options.
Key name: Type the name of the TSIG key that you previously generated. It is not necessary to type the same
name, but using the same name helps simplify key management.
Key: Paste the key value that you previously copied, or click Generate to create a new key.
4. In the External Reverse Zones to Update section, click Add, specify the following information, and click OK:
Network Address: Type the IP address for the network in the reverse-mapping zone for which you want to
authenticate updates using TSIG.
Subnet Mask: Enter the netmask of the network address.
Name Server Address: Type the IP address of the DNS server to which you want the DHCP server to send the
updates.
Use TSIG: Select check box to activate the next two options.
Key name: Type the name of the TSIG key that you previously generated. It is not necessary to enter the
same name, but using the same name helps simplify key management. You can use the same TSIG key for
authenticating updates from the forward-mapping zone and the reverse-mapping zone, or you can use
different keys.
Key: Paste the key value that you previously copied, or click Generate to create a new key.
5. Click the Save and Restart Services icon.
To apply TSIG authentication for updates that the DNS server receives:
2. Click Updates, and in the Allow TSIG dynamic updates for section, click Add.
3. In the TSIG Updater Item dialog box, enter the following:
Key name: Type a useful name for the key, such as the name of the grid or grid member using the key, or the
name of the zone being updated. The Key Name entered here does not have to match the TSIG key name on
the DHCP server sending the updates, but using the same name can ease coordination when setting up the
DHCP and DNS servers.
Key: Enter a key in the text field, or click the Generate to generate a TSIG key.
Note: Copy the key value for use when configuring TSIG on the DHCP and DNS servers.

Chapter 18 Managing IP Data IPAM
IPAM (IP address management) provides an IP address-based approachas opposed to one that is protocol-based
for tracking and managing IP address usage for DHCP and DNS services. The Infoblox IPAM implementation provides
three distinct views of IP address usage: a high-level overall network view, a run-time view that allows you to zoom in
and out to varying levels of detail, and a view of historical records. In addition, it also provides a simple mechanism
for modifying Infoblox host, DHCP, and DNS settings associated with an address and for promoting currently active
dynamic addresses to static addresses, reserved addresses, or Infoblox hosts. To use IPAM functionality, you must
install a Keystone license key.
This chapter contains the following topics that explain how to configure IPAM settings and monitor IPAM data:
Viewing and Modifying IP Address Data on page 558
Classifying an IPAM Device on page 558
Configuring IPAM Device Types on page 560
Adding, Modifying, and Removing Host Objects on page 564
Adding, Modifying, and Removing DNS Records on page 564
Modifying DHCP Options on page 564
Converting DHCP Leases, Fixed Addresses, and Reserved Addresses on page 564
Monitoring Overall DHCP Address Usage on page 567
Viewing IPAM Status on page 571
Viewing IPAM Data on page 571
Viewing DHCP and DNS Usage and Device Details on page 572
Searching and Sorting IPAM Data on page 572
Viewing Historical DHCP Lease Records on page 575
Logging Member and Selective Logging on page 575
Searching DHCP Lease Event Records on page 577
Viewing Lease Event Details on page 578
Exporting and Importing on page 579
Managing IP Data IPAM
Viewing and Modifying IP Address Data
IPAM uses the IP address as the entry point to the data set containing Infoblox host, DNS, DHCP, and device
information related to that address. You can view the data, modify it, and convert DHCP lease types (such as changing
a currently active dynamic lease to a fixed address, reserved address, or Infoblox host). With the increasing number
of network devices, the varied types of network access (wired, wireless, VoIP, VPNs), and the shifting network
boundaries needed to accommodate mobile remote access users, network management and security have become
increasingly complex. IPAM offers an IP address-centric approach to network management to face these challenges.
Figure 18.1 IP Address Data Set
Classifying an IPAM Device
The device classification feature takes the anonymity out of IP networks by allowing you to describe the devices on
your network. You can classify devices in DHCP ranges and devices defined as Infoblox hosts and as fixed addresses.
For convenience, the NIOS appliance includes a set of predefined device types such as routers, firewalls, printers,
and so on. You can create your own device types for devices that do not fit in the predefined set. Each device type,
whether predefined or user-defined, provides labels for attributes such as device location, owner, manufacturer, and
model, as well as custom labels that you can define to meet the unique needs of your organization. In addition, you
can select labels for inclusion in the audit log file. When you select labels for audit, they are included in all the audit
log entries of the device type. (For information about the audit log, see Using the Audit Log on page 170.)
10.1.1.25
10.1.1.24
10.1.1.23
10.1.1.22
10.1.1.21
10.1.1.20
10.1.1.29
10.1.1.28
10.1.1.27
10.1.1.26
10.1.1.30
10.1.1.34
10.1.1.33
10.1.1.32
10.1.1.31
10.1.1.35
Select an IP address and click Modify to view information about its host, DHCP, DNS, and device setting, and
lease details if the address is being currently leased. You can also modify these settings or convert the type of
a currently active lease from dynamic to fixed, reserved, or Infoblox host.
Host Information
Network data
- IP address
- (optional) MAC address
Zone data
- Host and bulkhost name
- Zone name
- Aliases
- TTL (for DNS caching)
Device data
- Type
- Labels
Comment
Additional DHCP information
MAC address information: editable for fixed
IP addresses, viewable for active dynamic
leases
DHCP options for fixed addresses
Current DHCP Lease Details and
Lease Conversion
Active dynamic lease ->fixed address,
reserved address, or Infoblox host
Fixed address ->reserved address or host
Reserved address ->Infoblox host
Additional DNS information
A and PTR records
TTL
IP Address Data Set for 10.1.1.25
Figure 18.2 on page 559 shows a network with a number of classified and unclassified devices. For each classified
device, there is a set of attributes or details that provide useful information about it. The illustration shows a close-up
view of the details for a printer. The details make use of the following predefined and user-defined labels:
Figure 18.2 Device Types in a Network
Predefined Labels User-Defined Labels
Location Contact e-mail address
Owner Purchase date
Manufacturer Warranty expiration date
Model Service telephone number
P
rinter
Laptop
S
erver
D
esktop
N
AT D
evice
R
outer
Firew
all
D
e
v
ice
Typ
e

P
rin
te
r
Lo
ca
tio
n
*
C
u
b
e
3
.1
.1
1
4
O
w
n
e
r*
IT
M
a
n
u
fa
ctu
re
r*
H
P
M
o
d
e
l*
7
2
0
0
La
se
rJe
t
A
sse
t Ta
g

8
4
7
2
3
B
P
u
rch
a
se
D
a
te

7
/1
5
/2
0
0
5
W
a
rra
n
ty E
xp
.
7
/1
5
/2
0
0
8
S
e
rv
ice

8
0
0
-5
5
5
-2
2
2
2
For example, you classify one device type as a
printer, and provide details about it using
predefined labels (identified by asteriks) and
user-defined labels. These details provide
valuable information for network, asset, and
service management.
For each classified device in the network, you can
provide equally informative notes.
Network with an
assortment of classified
and unclassified device types
Configuring IPAM Device Types
Complete the following tasks to configure device classification types to provide additional information about the
devices in your network:
1. Define device types, as described in the next section.
2. Assign device types to address ranges, fixed addresses, Infoblox hosts, and reserved addresses. For more
information, see Assigning Device Types to DHCP Ranges, Fixed Addresses, and Hosts on page 560 and
Assigning Device Types to DHCP Range and Fixed Address Templates on page 561.
Defining Device Types
Although Infoblox provides a set of predefined device classification types and labels, you can define your own device
types to describe more accurately the devices in your network and your own labels to provide the type of information
you need. You can also flag labels for audit to include them in the audit log entries for the device type.
To define a device type:
1. From the DHCP and IPAM perspective, click the DHCP Members tab -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, select IPAM Device Types.
3. You can either add a new device type or select a predefined device type:
Click Add to add a new device type,
or
Select a predefined device type and click Modify.
4. In the Device Type dialog box, do the following, and then click OK to close the dialog box:
Name: You can enter the name of a device type, modify the displayed device type, or leave it as is.
Audit: Select this check box to include a field in all entries for this device type in the audit log.
Custom1 through Custom20: To name the custom fields, click a field (Custom1, for example) and type the
name of an attribute in the Device Label field. For example, you could name the field Asset Tag. The
Device Label field displays up to 17 characters.
Assigning Device Types to DHCP Ranges, Fixed Addresses, and Hosts
To assign a device type to a DHCP range:
1. From the DHCP and IPAM perspective, select Networks -> + (for Networks) -> network, and then select the DHCP
range to which you are assigning a device.
2. Click Edit -> DHCP Range Properties.
3. In the DHCP Range Properties editor, click IPAM Device Info.
4. Do the following:
Device Type: Choose the device type for this address range from the drop-down list.
Value: Type relevant information in the Value fields. It is not necessary to enter information in every field.
Only use the ones that you want. For example, you could select the Model field and enter the value AT&T.
You cannot check or clear the Audit field, or overwrite a value in the Device Label field.
To assign a device type to a fixed address or reserved address:
1. From the DHCP and IPAM perspective, select Networks -> + (for Networks) -> network, and then select the IP
address to which you are assigning a device type.
2. In the Configure Fixed Address editor, click IPAM Device Info, and then do the following:
Device Type: Choose the device type for this fixed or reserved address from the drop-down list.
Only use the ones that you want. For example, you can select the Model field and enter a model number.
To assign a device type to an Infoblox host:
1. From the DNS perspective, select the Infoblox Views tab -> Infoblox Views -> zone -> host.
2. In the Records tab, select host -> Edit -> Properties.
3. In the Host editor, click IPAM Device Info.
Device Type: Choose the device type from the Device Type list.
For example, you could select the Model field and enter a model number.
Assigning Device Types to DHCP Range and Fixed Address Templates
You can assign device types to DHCP range and fixed address templates, and then use those templates for particular
groups of devices. For example, you can define a fixed address template for all printers in your organization and
assign the Printer device type to that template.
To assign a device type to a DHCP range template or a fixed address template:
1. From the DHCP and IPAM perspective, select the Networks tab + (for Templates) -> fixed_address_template or
range_template.
If you selected a DHCP range template, click Edit -> DHCP Range Properties,
or
If you selected a fixed address template, click Edit -> Fixed Address Properties.
3. In the DHCP Range Properties editor or the Fixed Address editor, click IPAM Device Info.
Device Type: Choose a device type from the Device Type list.
For example, you can select the Model field and enter a model number.
Deleting a Device Type Definition
You can delete device types that you do not use, so that the list displays only the applicable device types. When you
delete a device type definition, all device labels, values, and audit selections are deleted.
To delete a device type:
2. In the Grid DHCP Properties editor, click IPAM Device Types.
3. Select an IPAM device type, and click Delete to delete the device name and all fields to be written to the audit log.
Configuration Example: Configuring a Device Type
This example illustrates how to configure the device type, Printer. In this example, you modify the Custom1 label for
the Printer device type and select the Name, Location and Asset Tag fields for auditing. After you configure the Printer
device type, you assign it to a fixed address in the 10.10.10.0/24 network and enter values for some of its labels.
Configure a Device Type for Printers
To configure a device type for printers in your network:
1. In the DHCP and IPAM perspective, click the DHCP Members tab -> Infoblox -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, select IPAM Device Types.
3. Select the Printer device type, and click Modify.
4. In the Device Type dialog box, do the following as shown in Figure 18.3, and then click OK to close the dialog box:
Select the Audit check boxes beside Name and Location.
Click the Custom1 field, and type Asset Tag in the Device Label field.
Select the Audit check box next to Asset Tag to include this field in the audit log.
Figure 18.3 Printer Device Type

Select Name and
Location for audit.
Rename Custom1 to Asset
Tag and select it for audit.
Assign the Device Type to a Fixed Address
To assign the Printer device type to a fixed address that you previously configured in the 10.10.10.0/24 network:
1. From the DHCP and IPAM perspective, select the Networks tab + (for Networks) -> 10.10.10.0/24.
2. In the Ranges, Fixed Addresses and Filters tab, select 10.10.10.10 -> Edit -> Fixed Address Properties.
3. In the Fixed Address editor, click IPAM Device Info.
4. From the Device Type list, choose the Printer device type.
Figure 18.4 Add Values for Device Labels
5. In the Value fields, type the following, as shown in Figure 18.4:
Click the Owner field and type Sales Dept.
Click the Location field and type Sunnyvale.
Click the Manufacturer field and type HP.
Click the Model field and type 4200.
Click the Asset Tag field, and type HP4200PP13.
Following is an entry from the audit log file for the fixed address, 10.10.10.10. It includes the device type fields
that you selected for audit: device name, location and asset tag.
2008- 02- 26 21: 47: 34. 418Z [ admi n] : Modi f i ed Fi xedAddr ess 10. 10. 10. 10
Devi ce=" Pr i nt er " , Locat i on=" Sunnyval e" , Asset Tag=" HP4200PP13", : Changed
over r i de_r out er s: " f al se" - >" t r ue" , Rout er s [ ] - >[ 10. 10. 10. 1]
In the Asset Tag field, click the Value
column and type HP4200PP13.
Adding, Modifying, and Removing Host Objects
An Infoblox host object is a data model that contains both DNS and DHCP data for a device. When you select an IP
address that does not already belong to an Infoblox host, you can define a host for it. If there already is a host that
uses the selected IP address, you can modify its properties or remove the host object.
Note: Infoblox does not recommend defining multiple hosts for the same IP address. If you want to link multiple host
names to a single IP address, use the alias option.
For information on adding, modifying, and removing hosts and bulk hosts, see and Managing Hosts and Resource
Records on page 408.
Adding, Modifying, and Removing DNS Records
If you change any element in an Infoblox host object, the NIOS appliance automatically adjusts the other elements in
that object to preserve their relationship. The DNS protocol represents these host object elements as A (address)
records, PTR (pointer) records, and CNAME (Canonical name) records. Accordingly, whenever a change occurs to an
element in an Infoblox host object, the NIOS appliance ensures that the relationship of the corresponding A, PTR, and
CNAME records (from a DNS perspective) remains intact.
Infoblox also provides the flexibility to add and maintain A and PTR records for an IP address manually. However, by
doing so, you lose the ability of the NIOS appliance to maintain these records automatically. For information about
adding, modifying, and removing A and PTR records, see Adding Resource Records on page 394 and Managing Hosts
and Resource Records on page 408.
Modifying DHCP Options
When the NIOS appliance assigns an IP address dynamically from a DHCP range, the address uses the DHCP
properties for that range. When the IP address is a fixed or reserved address, you can either use the DHCP properties
for the network to which the address belongs or override them with custom settings. For information about DHCP
properties, see Chapter 15, Configuring DHCP Services, on page 483.
Converting DHCP Leases, Fixed Addresses, and Reserved Addresses
The NIOS appliance provides a simple mechanism for converting the active lease of a dynamically assigned IP
address to a fixed IP address, reserved IP address, or Infoblox host. The appliance can also convert a fixed address
to a reserved address or host. Finally, it can also convert a reserved address to a host.
A fixed address represents a persistent link between an IP address and a MAC address, so that every time the DHCP
client with that MAC address requests an IP address, the DHCP server assigns it the same one. To create a fixed
address, you bind an IP address to a MAC address. You can make that binding in a fixed address definition, an
Infoblox host object definition (see Adding Hosts on page 387) or by converting an active dynamically leased address
to a fixed address. The lease conversion transforms the temporary binding between the IP address and MAC address
in the dynamic lease to a persistent one. The lease must be active so that the NIOS appliance has an IP-to-MAC
address binding to convert into a fixed address.
Adding, Modifying, and Removing Host Objects
Figure 18.5 Converting a Dynamic Lease to a Fixed Lease
An advantage of converting an active dynamic lease is that you do not need to learn the MAC address of the device
to which you want to assign an IP address and manually enter it in the fixed address configuration.
A reserved address is an address that you exclude from DHCP use because you intend to configure that address
manually on a device, such as a firewall, router, or printer. To create a reserved address, you can define a fixed
address with an IP address and a MAC address of all zeroes (00:00:00:00:00:00). You can also convert a fixed
address or a dynamic address with an active lease to a reserved address.
Note: When you convert an address in a DHCP range to a reserved address, you reduce the total number of
dynamically assignable addresses in that range by one. Correspondingly, this reduces the number of allocated
addresses needed to exceed a high or low watermark threshold for that range.
1 2
3
4
6
5
7
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
NIOS Appliance NIOS Appliance
MAC: 01:01:01:01:01:01
DHCP Server DHCP Client DHCP Server
DHCP Client
MAC: 01:01:01:01:01:01
Address Assignment
Address Request Address Request
DHCP Range
Appliance dynamically
chooses an address
from a DHCP range.
Appliance always assigns
the client the same IP address.
Subsequent Dynamic
Address Assignments
Convert Lease
Dynamic -->Fixed
01:01:01:01:01:01
to 10.1.1.27
10.1.1.20 -
10.1.1.30
10.1.1.22
10.1.1.25
10.1.1.27
10.1.1.27
10.1.1.27
10.1.1.27
Dynamic Address Leasing Fixed Address Leasing
Figure 18.6 Converting a Dynamic Lease or Fixed Address to a Reserved Address
Converting a Dynamic Lease to a Fixed Address, Reserved Address, or Infoblox Host
To convert an active dynamically leased IP address:
1. From the DHCP and IPAM perspective, click the Networks tab -> + (for Networks) -> network -> View -> IP Address
Management -> ip_addr -> Edit -> Convert Dynamic Lease.
2. In the Convert Dynamic Lease dialog box, select Fixed Address, Reserved, or Host, and then click OK.
3. When converting a dynamic lease to an Infoblox host, also enter its host name and select a zone.
Note: To return an IP address to its place in a DHCP range after converting it from an active dynamic lease to a fixed
address, reserved address, or Infoblox host, delete the fixed address, reserved address, or host to which you
previously converted the IP address. The IP address then becomes part of the DHCP range to which it first
belonged.
Converting a Fixed Address, Reserved Address, or Infoblox Host
Following is the procedure to convert a fixed IP address to a reserved address or Infoblox host, and to convert a
reserved address to an Infoblox host:
1. From the DHCP and IPAM perspective, click the Networks tab -> + (for Networks) -> network -> View -> IP Address
Management -> ip_addr -> Edit -> Convert Fixed Address.
2. In the Convert Fixed Lease dialog box, select Reserved or Host, and then click OK.
3. When converting a fixed lease to an Infoblox host, also enter its host name and select a zone.
1
2
3
5
4
NIOS Appliance
DHCP Server DHCP Client
DHCP Addresses
10.1.1.20
10.1.1.21
10.1.1.22
10.1.1.23
10.1.1.24
10.1.1.25
10.1.1.25
...
10.1.1.30
Address Request
DHCP Range
Appliance assigns
an address to the
DHCP client.
Statistically Configured
Device
DHCP Server
NIOS Appliance
MAC: 01:01:01:01:01:01
MAC: 01:01:01:01:01:01
IP: 10.1.1.25
Convert 10.1.1.25
to a reserved
address with a null
MAC address:
00:00:00:00:00:00
10.1.1.20 -
10.1.1.30
10.1.1.25
Appliance excludes
10.1.1.25 from
DHCP use and
marks its status
as Used.
or
Fixed Address
10.1.1.25
Appliance chooses an
address from a DHCP
range or from a fixed
address definition.
DHCP Client and Server Statically Configured Device and DHCP Server
Monitoring Overall DHCP Address Usage
IPAM can provide a view of the current overall DHCP address usage for the networks and DHCP ranges defined on each
grid member. The view is in the form of a percent: address leases in use/total addresses for each network. Such
information can indicate if there is a sufficient number of available addresses at each of these levels. It can also
provide information about the distribution of address resources, indicating if there are too many unused addresses
in one location while all the addresses in another are in use.
In addition to viewing the percent of addresses in use, you can also apply high and low watermarks for each DHCP
range. These watermarks represent thresholds above or below which address usage is unexpected and might warrant
your attention. For example, usage falling below a low watermark might indicate network issues preventing the
renewal of leases. When usage for a DHCP range crosses a watermark, the NIOS appliance makes a syslog entry and
if configured to do sosends the administrator alerts as SNMP traps and e-mail notifications. Figure 18.7 illustrates
the relationship of allocated and available addresses to high and low watermarks in a DHCP range.
Figure 18.7 Overall DHCP Address Usage for a DHCP Range
Setting Watermark Properties
You can define watermarks at grid, member, network, and DHCP range levels, but the NIOS appliance applies them
solely to DHCP ranges. Because the appliance applies settings hierarchically in a parent-child structure, by defining
watermarks once at a higher level, DHCP ranges can then inherit these settings without your needing to redefine them
for each range. For example, if you set high and low watermarks for a grid, then each grid member, each network, and
each DHCP range inherits these settings. However, if you override these settings at the member level, then the
network and DHCP ranges for that member inherit its settings. If you override the grid member settings at the network
level, then that network and any DHCP ranges within that network inherit the network-level settings. Finally, you can
set high and low watermarks for an individual DHCP range, which override anything set at a higher level. The system
of inheritance works as follows:
Grid Top of hierarchical structure and, therefore, there is nothing above it from which it can inherit settings.
Grid member Inherits grid settings unless you override them at the grid member level.
100%
80%
70%
20%
0%
Low
Watermark
If usage crosses thresholds in either direction,
the NIOS appliance can send e-mail and
SNMP warnings to the administrator.
Available Leases
Allocated Leases
Available
Leases
High
Watermark
DHCP Range
70% of the DHCP
range is in use.
Allocated
Leases
Administrator
Low Watermark
High Watermark
Network Inherits grid settings, unless you override them at the grid member or network levels. Then the
network either inherits the grid member settings or uses the network override.
DHCP range Inherits grid settings, unless you override them at the grid member, network, or DHCP range
levels. Then the DHCP range inherits either the grid member or network settings or uses the DHCP range
override.
Figure 18.8 shows different high and low watermark settings at different levels. Although you can set thresholds at
four levels (grid, grid member, network, and DHCP range), the NIOS appliance applies them to DHCP ranges.
Figure 18.8 High and Low Watermarks
Address usage in a DHCP range triggers an event when it crosses a watermark. The following are actions that do and
do not trigger an address usage event:
Address usage triggers an event when it
Initially exceeds the low watermark (no event) and then dips below it again (event)
Initially exceeds the low watermark (no event), dips below it (first event), and then exceeds the low
watermark again (second event)
Exceeds the high watermark
Dips below the high watermark
Address usage does not trigger an event when it
Never exceeds the low watermark
Initially exceeds the low watermark
Reaches a watermark but does not cross it
Note: You can effectively disable address usage events for a DHCP range by setting its high watermark at 100% and
the low watermark at 0% (default setting for the low watermark). Because address usage cannot cross these
watermarks, no events can occur.
80%
65%
20%
75%
50%
25%
90%
40%
10%
70%
50%
30%
Watermarks at
Different Levels
Low Watermark
High Watermark
You can set IP address usage
thresholds (watermarks) for
grids, grid members,
networks, and DHCP ranges.
The thresholds that you set at
more narrowly defined levels
override thresholds set at the
more generic levels that
contain them. For example, if
address usage exceeds the
70% high watermark or dips
below the 30% low watermark
for the DHCP range shown
here, the NIOS appliance generates e-mail and
SNMP alerts, even though address usage is
within acceptable ranges at all higher levels.
There is a parent-child relationship among different levels.
If you do not set a watermark at a more specific level, it
inherits the setting from a higher level that contains it.
Note: You can set watermarks at different levels, but the appliance
applies only watermarks that are set or inherited at the DHCP range.
Grid
Grid Member
Network
DHCP Range
Available Leases
Allocated Leases
You can set high and low watermarks at different levels:
Grid level (see Grid Level on page 569)
Grid Member level (see Grid Member Level on page 569)
Network level (see Network Level on page 570)
DHCP Range level (see DHCP Range Level on page 570)
Grid Level
2. In the Grid DHCP Properties editor, click Thresholds, and then enter the following:
Enable DHCP Thresholds: Select to enable the feature.
High Water Mark: Enter a number between 0 and 100. If the percent of allocated addresses in a DHCP
range exceeds this watermark, the NIOS appliance makes a syslog entry andif configured to do so
sends an SNMP trap and an e-mail notification to a designated destination. The default high watermark
number is 95.
Low Water Mark: Enter a number between 0 and 100. If the percent of allocated addresses in a DHCP
range drops below this watermark, the NIOS appliance makes a syslog entry andif configured to do
sosends an SNMP trap and an e-mail notification to a designated destination. The default low
watermark number is 0. Note: Address usage must initially exceed the low watermark threshold and
then dip below it before the appliance considers low address usage an event requiring an alert.
Enable e-mail warnings: Select so that the NIOS appliance sends an e-mail notification to an
administrator if DHCP address usage crosses a high or low watermark threshold.
Enable SNMP warnings: When DHCP address usage crosses a watermark threshold, the appliance
sends an SNMP trap to the trap receiver that you defined for the grid.
Override grid admin e-mail notification: Select this option to specify an e-mail address for alerts related
to DHCP address usage crossing a high or low watermark. This e-mail address is different from the
address for other grid-level notifications.
E-mail Addresses: Type an e-mail address to which you want the NIOS appliance to send e-mail
notifications when the DHCP address usage for the grid crosses a threshold, and then click Add. You
can create a list of several e-mail addresses.
Grid Member Level
To configure high and low watermarks for a grid member, follow the navigational path below and override the
grid-level settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click the DHCP Members tab -> + (for grid) -> member -> Edit -> Member
DHCP Properties -> Thresholds.
1. In the Thresholds editor, enter the following:
Override grid DHCP threshold settings: Select this to make changes to all of the fields in the Thresholds
editor.
number is 95.
range drops below this watermark, the appliance makes a syslog entry andif configured to do so
sends an SNMP trap and an e-mail notification to a designated destination. The default low watermark
number is 0. Note: Address usage must initially exceed the low watermark threshold and then dip
below it before the appliance considers low address usage an event requiring an alert.
Network Level
To configure high and low watermarks for a network, follow the navigational path below and override the
member-level settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click the Networks tab -> + (for Networks or Shared Networks) -> network ->
Edit -> Network Properties -> Thresholds.
Follow the instructions in steps 2 and 3 in the Grid Level section.
DHCP Range Level
To configure high and low watermarks for a DHCP range, follow the navigational path below and override the
network-level settings. Restart services after you save the settings.
From the DHCP and IPAM Perspective, click the Networks tab -> + (for Networks or Shared Networks) -> network ->
1. In the DHCP Range tab, select the Thresholds editor.
Override network DHCP threshold settings: Click this selection to enable changes to the existing settings.
number is 95.
range drops below this watermark, the appliance makes a syslog entry andif configured to do so
sends an SNMP trap and an e-mail notification to a designated destination. The default low watermark
number is 0. Note: Address usage must initially exceed the low watermark threshold and then dip
below it before the appliance considers low address usage an event requiring an alert.
Viewing IPAM Status
Viewing IPAM Status
After setting high and low watermarks and the NIOS appliance has been actively serving DHCP, you can view the
current state of address usage. You can view address usage at the network level for each grid member.
To view DHCP address usage, from the DHCP and IPAM perspective, click the DHCP Members tab -> + (for grid) ->
member -> View -> DHCP Statistics. The DHCP Statistics Panel displays the information about the current state of
address usage for all the networks belonging to that member. The panel provides a snapshot of DHCP address usage
at one point in time for each grid member.
Table 18.1 DHCP Statistics Panel
Downloading IPAM Status Data
You can download the IPAM status log to keep as a record of address usage at a specific moment in time. Gathering
this information at different times of day, or at the same time on different days can help you establish a baseline of
typical address usage on your network.
To download IPAM status data:
1. From the DHCP and IPAM perspective, click the DHCP Members tab -> + (for grid) -> member -> Tools -> Download
DHCP Statistics.
2. Navigate to the directory where you want to save the file, type a file name (the default name is ipamStats.tar.gz),
and then click OK.
3. To view the file, you must first use a compression tool such as gzip or WinZip to decompress it, and then a text
editor to open and read it.
Viewing IPAM Data
The NIOS appliance provides a simple means for viewing IPAM data, searching for specific types of addresses, and
sorting information. With IPAM, you can see how the appliance is using an IP address for both DHCP and DNS
services, as well as the type of device to which the address belongs. You can search by IP address, MAC address,
device type, and device location. You can also sort used from unused addresses (see Searching and Sorting IPAM
Data on page 572). Superusers and non-superusers with read-only permissions to all networks, all zones and all
members can view IPAM data.
Network The IP address and netmask defining a network
Static The number of static addresses in the network.
Dynamic The number of currently assigned addresses/total number of addresses in all the
DHCP ranges belonging to the network. The NIOS appliance also displays the
percentage of dynamic addresses with active leases.
Total The number of currently assigned addresses/total number of addresses in the
network. The NIOS appliance also displays the percentage of addresses currently in
use.
High Water The high watermark threshold for address usage in the network.
Low Water The low watermark threshold for address usage in the network.
DNS Records The number of DNS records associated with each DHCP range in the network
Viewing DHCP and DNS Usage and Device Details
The NIOS appliance uses the concept of an IPAM address to provide a single reference point for both the DHCP and
DNS services associated with that IP address. Although you can see DHCP data for an IP address when viewing
networks and DNS data when viewing zones, IPAM provides a convenient single view of both services for an IP
address. IPAM can also provide information about the physical device to which the IP address belongs.
Figure 18.9 IPAM View of DHCP Data, DNS Data, and Device Type
Searching and Sorting IPAM Data
You can search through IPAM data and sort it in different ways. IPAM supports searches on several types of objects.
You can search by IP address, MAC address, device type, and device location. In fact, you might consider some types
of searches to be acts of sorting. For example, by performing a search for a specific device type, such as a printer, you
find all of the devices of that type, thereby sorting printers from all other defined (and undefined) device types. In
short, IPAM provides you with several different approaches to finding information quickly. You can search in either
networks or DHCP ranges.
To perform a search through IPAM data in a DHCP range:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> View
-> IP Address Management.
2. Click the Search icon on the top-right corner of the IP Address Management panel.
D
H
C
P

D
a
t
a
D
e
v
i
c
e

C
l
a
s
s
i
f
i
c
a
t
i
o
n
D
N
S

D
a
t
a
IPAM provides a single IP-centric
view that can show DHCP data,
DNS data, and the type of device
associated with an IP address.
IP Address
IP Address
10.1.1.5
IP Address
IP Address
IP Address
IP Address
IP Address
IP Address
IP Address
Indicates the place of an IP
address in the network
Provides information about
the physical device to which
an IP address belongs
Indicates the place of an IP
address in a zone
IP Address: 10.1.15
MAC Address: aa:11:bb:22:cc:33
DHCP Lease Details
Network
10.1.1.0/24
Host Name: server1
Zone Name: mk.infoblox.com
Host Record Details
Device Type: Server
Device Details:
IPAM View
DHCP Data
DNS Data
Device Classification
Zone
mk.infoblox.com
Viewing IPAM Data
3. In the Search dialog box, enter the following and then click Search.
Search for: Enter the text you want to find. The text can be for an IP address, MAC address, device type, or
device location.
Restrict Search to: Select either All Types or one of the following to restrict the search: Fixed Address, DHCP
Range, or host.
By using a specific search parameter, you can gather information about addresses that are related in some wayby
address, vendor prefix, device type, or location. For example, see Figure 18.10 for an illustration that shows how you
can search the same body of information by type versus location. It shows the network space for three buildings at
the site of a corporate headquarters (HQ) office.
Figure 18.10 Searching by Device Type and Location
You can also sort addresses into used and unused categories.
Used address An IP address for which there is some DHCP or DNS usage. This can be an Infoblox host, bulk
host, fixed address, reserved address, dynamic address in a DHCP range, or an address with associated A or PTR
records.
Unused address An IP address for which there is no associated DHCP or DNS usage.
Note: You can also display both used and unused addresses simultaneously by selecting All IPAM Addresses in
the Filter drop-down list in the IP Address Management panel.
For example, you can easily find an available IP address in a network by sorting out all the unused addresses.
To find the unused addresses on a network:
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> View
-> IP Address Management, and then choose Unused IP Addresses from the Filter list.
A list of all unused addresses appears, beginning with the lowest IP address (that is, the IP address closest to
0.0.0.0) at the top. If the results extend beyond the viewable area, you can use the scroll bar to scroll down and
click the right and left arrow keys to navigate through the pages.
Three segments of a corporate network that spans three buildings
on its campus: HQ-West, HQ-Main, and HQ-East.
The results of this search
produce all the devices
with the location defined
as HQ-Main.
The results of this
search produce all the
devices with the type
defines as firewall.
Search Results for
Device Type: Firewalls
Search Results for
Device Location: HQ-Main
HQ-West
HQ-Main
HQ-East
Viewing DHCP Lease Details
You can view DHCP lease details for any dynamic IP address that is currently in use. Through the GUI, you can see
dynamic lease details for an active IP address by navigating to any of the following panels:
-> DHCP Leases -> ip_addr -> View -> Properties.
-> IP Address Management -> ip_addr -> View -> Properties.
From the DHCP and IPAM Perspective, click View -> DHCP Lease History -> ip_addr -> View -> Properties. A
limited-access admin group can view the DHCP lease history only if the group has read only permission to it. For
information on setting permissions for the DHCP lease history, see Administrative Permissions for the DHCP
Lease History on page 97.
The content on these pages differs slightly, but the common details are as follows:
IP Address: The IP address that the NIOS appliance assigns a DHCP client for this lease.
MAC Address: The MAC address of the DHCP client that receives this lease for an IP address.
DHCP Client Identifier: The DHCP client identifier (option 61) in the lease. The client sends the client identifier
as option 61 in the DHCP DISCOVER and REQUEST packets, as described in RFC2132, DHCP Options and BOOTP
Vendor Extensions. The client identifier is either the MAC address of the network interface card requesting the
address or any string uniquely identifying the client.
Host Name: The host name that the DHCP client sends to the NIOS appliance using DHCP option 12.
Grid Member: The grid member that serves DHCP for this lease.
Start Time: The day, date, and time when the state of the lease starts. Note that the number that appears at the
beginning of each start time indicates the day of the week (1=Monday, 2=Tuesday, and so on).
User Name: The name of the user who receives the lease for the IP address. The user name enables you to
differentiate between guest users and authenticated users.
The User Name column displays the name of the user who receives the lease for the IP address. The user name
enables you to differentiate between guest users and authenticated users.
If you log in as an authenticated user, your user name is whatever you choose when you log in. If you log in as a
guest, your user name is First: first_name Last: last_name.
For example, if your first name is John and last name is Doe and your user name is jdoe:
If you log in as an authenticated user, your user name is jdoe.
If you log in as a guest user, your user name is First: John, Last: Doe.
End Time: The day, date, and time when the state of the lease ends. Note that the number that appears at the
beginning of each timestamp indicates the day of the week (1=Monday, 2=Tuesday, and so on).
Option 82 information: A relay agent can append DHCP option 82, relay agent information, to a message that it
forwards from a DHCP client to a DHCP server. If it does, the appliance displays the following information: relay
agent ID, circuit ID, and remote ID.
Binding State: The binding state for the current lease. The lease state can be one of the following:
Free: The lease is available for clients to use.
Active: The lease is currently in use by a DHCP client.
Expired: The lease was in use, but the DHCP client never renewed it, so it is no longer valid.
Released: The DHCP client returned the lease to the appliance.
Abandoned: The NIOS appliance cannot lease this IP address because the appliance received a response
when pinging the address.
Next Bind State: The subsequent binding state when the current lease expires.
UID: (User ID) The client identifier that the DHCP client sends the NIOS appliance (in DHCP option 61) when it
acquires the lease. Not all DHCP clients send a UID.
TSFP: (Time Sent From Partner) The timefrom the point of view of a remote DHCP failover peerwhen the
current lease state ends.
Viewing Historical DHCP Lease Records
CLTT: (Client Last Transaction Time) The time of the last transaction with the DHCP client for this lease.
TSTP: (Time Sent To Partner) The timefrom the point of view of the local DHCP failover peerthat the current
lease state ends.
Option: Agent circuit ID and remote ID data sent by a DHCP relay agent in DHCP option 82 fields.
Note: The dates and timestamps in the DHCP Leases viewer are determined by the time zone setting of the
admin account that you use to log in to the NIOS appliance.
Historical DHCP lease records complement the real-time DHCP lease viewer by allowing the NIOS appliance to store
and correlate DHCP lease information over the lifetime of a lease. You can see critical information such as when the
NIOS appliance issued or freed an IP address, the MAC address and host name of the device that received the IP
address, and the grid member that supplied the lease. You can view this information in the NIOS GUI. You can also
export the DHCP lease history log to separate systems for archival purposes and import records from separate
systems for reporting purposes. The NIOS appliance merges imported data with existing data. It is prudent to export
the DHCP lease history log regularly to back up records so that they do not get overwritten. See Exporting and
Importing on page 579.
Powerful search capabilities allow you to retrieve information for specific hosts, MAC addresses, and IP addresses,
and for specific time ranges. These capabilities are crucial for security auditing and for meeting new compliance
regulations such as SOX and HIPAA.
Logging Member and Selective Logging
Logging DHCP lease events makes significant CPU demands, especially when there is heavy DHCP activity. Therefore,
Infoblox strongly recommends that you designate a grid member other than the master as a logging member
whenever possible.
Another way to manage the increased load that logging introduces is to log selectively per grid member. For example,
you might want to log DHCP leases for members serving critical parts of your network and not keep historical logs for
members serving other parts.
By default, DHCP lease logging is disabled. You can enable and disable it at the grid and member levels, the
member-level setting overriding the grid setting.
Figure 18.11 DHCP Lease History Logging with Member Overrides
To enable or disable DHCP lease event logging for a grid:
1. From the DHCP and IPAM perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click Logging, and then enter the following:
Store leases on: Click Select Member and in the Select Grid Member dialog box, select the grid member on
which you want to store the DHCP lease history log. Infoblox recommends that you dedicate a member
other than the master as a logging member. If possible, use this member solely for storing the DHCP lease
history log. If you do not select a member, no logging can occur.
Log lease events from all DHCP servers: To enable DHCP lease logging for the entire grid, select check box.
To disable DHCP lease logging for the grid, clear check box. You can set member overrides if you want to
enable or disable lease logging per member.
Note: When you change the logging member, the change takes effect immediately. However, when you enable or
disable logging for the grid or for an individual member, that change takes effect only after you restart DHCP
service.
To enable or disable DHCP lease logging for a grid member, follow the navigational path below and override the
grid-level settings. Restart services after you save the settings.
Properties -> Logging.
Lease Logging
Disabled
Lease Logging
Disabled
Grid Master Grid Members
Logging Member
Grid
You can enable DHCP lease logging at the grid level, and then
disable it for select members. In this grid, four members send
DHCP lease events to the master, which forwards them to a
designated logging member. Two grid members do no log
DHCP lease events.
Searching DHCP Lease Event Records
The NIOS appliance offers several options for searching through the DHCP lease history log. You can perform basic
searches by text string and by timestamp. You can also perform advanced searches that use a set of parameters for
IP address, MAC address, host name, and grid member IP address, with each search parameter introducing an
additional requirement for finding a match. You can also limit your basic searches by specifying one of a set of
predefined time ranges in which to conduct the search. For an advanced search, you can either use a predefined
range of time or a custom range that you define. Both basic and advanced searches support regular expressions (see
Appendix B, "Regular Expressions", on page 693).
Note: After each search, you must clear the search to exit search mode.
Defining the Viewing Range
By default, the DHCP lease history log viewer (View -> DHCP Lease History) displays a single page of current lease
events, listing them in sequential order of occurrence. To improve search performance, you can filter the view of DHCP
leases by different intervals or ranges of time. The predefined ranges are All (default; shows all lease records), Last
Week, Last Day, Last 12 Hours, Last 4 Hours, and Last Hour.
Note: The dates and timestamps in the DHCP Lease History viewer are determined by the time zone setting of the
admin account that you use to log in to the NIOS appliance.
You can jump to any point in time by entering a new date (optionally date + time) in the Time field and then pressing
the ENTER key. You can also use the arrow buttons on both sides of the Time field to view pages of recorded leases
that occurred before or after the time displayed in the current view.
Using Advanced Find Options
You can perform advanced searches of the DHCP lease history log, using one or more of the following search
parameters to make your search more precise: IP address, MAC address, host name, and grid member IP address.
The NIOS appliance also supports a set of regular expressions to provide flexibility and to help refine your search even
more. For a list of some of the regular expressions that the NIOS appliance supports, see Appendix B, "Regular
Expressions", on page 693.
You can search within the time range that you specify either in the DHCP lease history log view or within the advanced
search itself. After you perform an advanced search, the time range and criteria specified in your search persist so
that you can page left and right within your search results.
Note: To exit the search results and return to the DHCP lease history log view, click Clear.
To perform an advanced search:
1. Click View -> DHCP Lease History, and then click the Search icon on the top right corner of the panel.
2. In the Search Lease History dialog box, enter the following:
Match all fields: Enter search terms in one or more of the following fields. Each term is additive, so that the
more terms you enter, the more focused your search becomes. It is not necessary to enter data in every
field.
IP address: Enter part or all of an IP address.
MAC address: Enter part or all of a MAC address.
Host Name: Enter part or all of a host name.
Member IP address: Enter part or all of the IP address of a grid member that provides DHCP service.
Predefined range: Select to perform the search in the predefined time range that you set in the DHCP lease
event view. There are six predefined ranges: All (default; shows all lease records), Last Week, Last Day, Last
12 Hours, Last 4 Hours, and Last Hour.
Custom range: Select to override the time range setting and perform the search in a range that you define.
Start from: Define the starting point of the time range in which you want to conduct your search.
Earliest event: Select this option to start your search from the earliest lease event in the log.
Specify: Select this option and then enter the date and time to start your search from that point.
End at: Define the ending point of the time range in which you want to conduct your search.
Latest event: Select this option to end your search at the last lease event in the log.
Specify: Select this option and then enter the date and time to end your search at that point.
Viewing Lease Event Details
You can select any entry in the DHCP lease history log and click View -> Properties to see information about the lease.
For information about these fields, see Viewing DHCP Lease Details on page 574. The fields that are unique in the
Lease Event Details viewer are as follows:
Timestamp: The date and time (to the millisecond) when the event occurs.
Event: Dynamic lease events are binding state transitions and can be one of the following:
When the NIOS appliance leases a fixed address, the data appears as a fixed event.
Comment: The text you entered for a fixed address.
Event Binding State Transition
Issued not active -> active
Renewed active -> active
Freed { active | expired | released | reset } -> { free | backup }
Abandoned not abandoned -> abandoned
Exporting and Importing
The DHCP lease history log holds a maximum of 100,000 entries. After that maximum is reached, the NIOS appliance
begins deleting entries, starting with the oldest. To archive DHCP lease history logs, you can export them and save
them as CSV (comma separated variables) files. You do not need to export the entire log. You can selectively export
a section of the log, such as the lease events for a single day.
As a conservative approach to archiving DHCP lease data, Infoblox recommends exporting the log on a daily basis,
perhaps through API (application programming interface) scripting. By exporting the daily log entries every day over
a certain period of time and then opening the exported files with a spreadsheet program, you can see the number of
entries for each day. You can then estimate how often you need to export the log to ensure that you save all of the
entries before the log fills up (at 100,000 entries). As a result, you might discover that you need to export the log more
or less frequently than once a day to archive all the records. For information about the NIOS appliance API, see
Chapter 24, Infoblox DMAPI, on page 665.
You can also import a previously exported DHCP lease history log into the NIOS appliance. The appliance merges the
imported data into its existing lease event log, adding new data and omitting duplicate entries. You might want to
export and then import a lease event log when changing the logging member. In this case, you export the data from
the first logging member, designate a different grid member for logging, and then import the data into the new logging
member. Note that only superusers can import a DHCP lease history file.
A limited-access admin group can view and export the DHCP lease history if it has read-only permission to the DHCP
lease history. For information on setting permissions for the DHCP lease history, see Administrative Permissions for
the DHCP Lease History on page 97.
To export a DHCP lease history log:
1. From the DHCP and IPAM perspective click Edit -> Export Lease History.
2. In the Export Lease History dialog box, enter the following:
Start Time: You can select Earliest event, which begins the exported log with the earliest DHCP lease event
in the log, or you can select Specify and then enter the year, month, day, hour, and minute to specify the
point at which you want the exported log to begin.
End Time: You can select Latest event, which concludes the exported log with the last DHCP lease event in
the log, or you can select Specify and then enter the year, month, day, hour, and minute to specify the point
at which you want the exported log to conclude.
3. Click OK.
The Export Lease History dialog box closes and another dialog box appears for navigating to the directory where
you want to save the exported file.
4. Navigate to the directory where you want to save the exported file, modify the file name (by default it is
dhcpLeaseHistory.csv.gz), and then click OK.
When exporting a file, the NIOS appliance adds double quotation marks (field) around the content of each
field and adds a header row identifying all the columns in which data appears. The appliance saves the file in
CSV format, compressed in gzip format.
To import a DHCP lease history log:
1. From the DHCP and IPAM perspective click Edit -> Import Lease History.
A dialog box appears that allows you to navigate to the file that you want to import.
2. Navigate to the file that you want to import, select it, and then click OK.

Chapter 19 NAC Foundation
The NAC (Network Access Control) Foundation module provides the ability to separate authorized from unauthorized
clients by putting them into separate network segments. Unauthorized clients are quarantined in one segment until
they successfully complete the authentication process, at which time they move to the authorized segment.
This chapter provides an overview of the NAC Foundation module and its components, and describes how to set
operational parameters and configure various security functions.
It includes the following sections:
About the NAC Foundation Module on page 583
DHCP Authentication Process on page 583
Configuring the NAC Foundation Module on page 586
Configuring DHCP Ranges for Authorization on page 587
Quarantined DHCP Range on page 587
Guest DHCP Range on page 587
Authorized DHCP Range on page 587
Binding DHCP Ranges to the Quarantined and Authorized Levels on page 588
Uploading Files for Customization on page 589
Uploading Files on page 589
Creating Subdirectories on page 589
Managing the Image Files on page 590
Configuring the Captive Portal on page 590
About Client Validation on page 591
Configuring the McAfee Service on page 591
Enabling Validation on page 592
About Authentication on page 592
Managing the Local User Database on page 592
Configuring the Self Service Portal on page 593
Importing Accounts from an Active Directory Server on page 594
Configuring Active Directory Services on page 594
Configuring LDAP/LDAPS Authentication Services on page 594
Configuring the Authentication Policy on page 595
Specifying an External Authentication Home RADIUS Server on page 596
NAC Foundation
About Guest Access on page 596
Configuring Guest Access on page 597
Viewing Guest and Authenticated Users on page 598
Configure a Loopback Interface on page 600
Configure a Network on page 600
Create DHCP Address Ranges in the Network on page 601
Configure AD Servers for Authentication on page 601
Bind DHCP Ranges to the Quarantined and Authorized Levels on page 601
Configure the Captive Portal on page 602
Configure Authentication on page 603
Configure Authentication on page 603
Enable DHCP on page 603
Verifying Your Configuration on page 603
About the NAC Foundation Module
The NAC Foundation module provides the ability to divide your network into different segments for unauthorized,
authorized and guest users. Based on a number of parameters, including MAC address, user credentials, and the
status of the client systems, the NAC Foundation module automatically assigns users to one of the defined network
segments. You can then use Access Control Lists (ACLs) on your routers and firewall policies to define the appropriate
services for each access level.
For example, you can divide the network into one or more production segments for valid employees and systems, a
guest segment with access only to the Internet and/or limited public servers, and a quarantined segment with access
only to the NIOS appliance.
On the NIOS appliance, you configure DHCP ranges and services for each access level: quarantined, authorized, and
guest. When you create DHCP ranges for the guest and authorized levels, the appliance automatically creates MAC
address filters for these levels. When users sign in as guests or successfully pass the security checks that you
configure, the NIOS appliance automatically adds the MAC addresses to the appropriate MAC address filters and
assigns addresses out of the appropriate address ranges. For information about MAC address filters, see Defining
Filters on page 499.
The NAC Foundation module includes built-in integration with McAfee ePolicy Orchestrator (ePO) for a
pre-authentication client check. It also provides a captive web portal that you can customize. The appliance directs
all requests from unauthorized clients to the captive web portal where users can request guest access or can log in
using their credentials. This module also supports a number of user authentication methods, including local user
authentication and external servers running Active Directory and Lightweight Directory Access Protocol (LDAP).
DHCP Authentication Process
This section describes the DHCP authentication process. It assumes that you have configured all the features of the
NAC Foundation module, including the optional client validation check and guest access features.
As illustrated in Figure 19.1, the DHCP authentication process begins when a DHCP client attempts to connect to the
network. The NIOS appliance checks if the MAC address of the DHCP client matches a MAC address in the guest or
authorized MAC address filters. If the appliance does not find a match, it assigns an IP address from the quarantined
range to the DHCP client and redirects the client to the captive portal page when the client opens a web browser to
access any web page. A captive portal is a web page to which unauthorized users are directed. It provides options to
log in and register as a guest user. No matter what domain name a quarantined DHCP client tries to reach, the NIOS
appliance resolves that name to the captive portal IP address. In this way, a quarantined DHCP client is not allowed
to contact another part of the network.
NAC Foundation
Figure 19.1 Stage 1: Quarantining an Unauthorized DHCP Client
When the client connects to the captive portal IP address through its web browser, you can either log in and
authenticate to obtain an IP address from the authorized DHCP range, or sign in as a guest and obtain an IP address
from the guest DHCP range.
3
1
2
NIOS Appliance
DNS and DHCP
Server
DHCP
Client
DHCP client sends DHCP request to the
NIOS appliance.
The MAC address filters for the authorized
and guest IP address ranges do not
contain the MAC address of the DHCP
client.
MAC Address Filter
- Authorized
MAC Address Filter
- Guest
authorized
192.168.1.50 -
192.168.1.150
guest
192.168.1.151 -
192.168.1.170
quarantined
192.168.1.225 -
192.168.1.254
The NIOS appliance assigns an IP address
from the quarantined range.
Quarantined
192.168.1.250
No Filter
If you choose to continue the authentication process, the appliance runs a pre-authentication check. It validates the
client system against a server running McAfee ePolicy Orchestrator, as shown in Figure 19.2. After the client is
successfully validated, the appliance authenticates the user with the authentication services that you configured.
The NIOS appliance supports user authentication through its local database, RADIUS servers, Active Directory
servers, and LDAP/LDAPS servers. You can configure the appliance to use one or more of these authentication
services.
Figure 19.2 User Authentication
After the client successfully passes the authentication stage, the appliance stores the MAC address of the client in
the MAC address filter for the authorized range. When the client tries to renew its IP address, it receives a new IP
address from the authorized DHCP range.
1 2
5
4
6
3
Quarantined
DHCP Client
NIOS Appliance
DNS and DHCP
Server
McAfee
Server
HTTP Connection
The quarantined DHCP client
opens its web browser and
connects to the captive portal.
If the user chooses to continue
authentication, the appliance
validates the client system
against the McAfee server.
After the client system is
successfully validated, the
appliance displays the login
page.
The user enters login information,
such as user name and password.
The device authenticates
the user through the
methods that you
configured.
Local user store
RADIUS server
Active Directory
LDAP/LDAPS
MAC Address Filter -
Authorized
After the user is authenticated,
the appliance adds the MAC
address of the client to the MAC
address filter for the authorized
range and assigns the client
system an IP address in the
authorized range.
Authorized
192.168.1.75
authorized
192.168.1.50 -
192.168.1.150
NAC Foundation
If you choose to sign in as a guest, as shown in Figure 19.3, the appliance displays the guest registration page, which
the user fills in.
Figure 19.3 Guest Registration
After you sign in as a guest, the appliance stores the MAC address of the client in the MAC address filter for the guest
range. When the DHCP client tries to renew its IP address, it receives a new IP address from the guest DHCP range.
Configuring the NAC Foundation Module
You configure DHCP authentication parameters on the grid member that serves DHCP for the network. You can
customize many aspects of this feature, from the interface to the various security checks the NIOS appliance
performs before allowing a user to access the network. Following are the tasks to configure the features of the NAC
Foundation module:
1. Configure the network and the DHCP ranges for quarantined, authorized, and optionally, guest users. For
information on configuring network and ranges, see Chapter 14, Managing DHCP Data, on page 459.
2. Enable DHCP authentication and bind the DHCP ranges for the quarantined and authorized levels. For
information, see Configuring DHCP Ranges for Authorization on page 587.
3. Upload the files you need to customize the captive portal, self service portal and guest registration page. For
information, see Uploading Files for Customization on page 589.
4. Configure the captive portal. For information, see Configuring the Captive Portal on page 590.
5. Optionally, configure the pre-authentication check. For information, see About Client Validation on page 591.
6. Configure the authentication services you want to use. For information, see About Authentication on page 592.
7. Optionally, configure the guest access feature. For information, see About Guest Access on page 596.
8. Enable the DHCP service. For information, see Enabling DHCP and Setting Member Properties on page 489.
1
2
3
4
Infoblox Appliance
DNS and DCHCP
Server
Quarantined
DHCP Client
HTTP Connection
The quarantined DHCP client
connects to the captive portal.
If the user chooses to
register as a guest,
the appliance
displays the guest
registration page.
The user enters information on
the guest registration page.
The appliance adds the MAC
address of the client to the MAC
address filter for the guest range
and assigns an IP address from
the guest DHCP range.
Guest
192.168.1.65
MAC Address Filter -
Guest
guest
192.168.1.151 -
192.168.1.170
Configuring DHCP Ranges for Authorization
Configuring DHCP Ranges for Authorization
When you configure a NIOS appliance to provide DHCP services and authentication, you must first define the network
that it serves, and then define the DHCP ranges and services for each access level:
Quarantined
Authorized
Guest
For information about configuring DHCP networks, ranges and services, seeChapter 14, Managing DHCP Data, on
page 459 and Chapter 15, Configuring DHCP Services, on page 483.
Quarantined DHCP Range
You must configure a DHCP range for the quarantined level, so the appliance can assign IP addresses within that
range to unauthorized DHCP clients. An unauthorized client is allowed to access the captive portal (a Web page that
a user must view and interact with before access is granted) and must successfully pass the authentication process
before it can receive an IP from the authorized range.
Infoblox recommends 30-second leases for addresses in the quarantined DHCP range. This provides enough time for
the user authentication process, so when the client attempts to renew the lease at the midpoint of its lease time, the
appliance can then assign the client a new IP address, depending on the result of the authentication process.
To ensure that clients can reach the captive portal, you must specify a route to the captive portal. On a network where
all systems can reach each other without going through a router, that is, all IP addresses are on the same subnet, you
must configure Option 33 for the quarantine DHCP range. This option specifies a list of static routes that the client
should install in its routing cache. The routes consist of a list of IP address pairs. For clients to reach the captive portal,
specify the portal IP address first (destination address), and the LAN address of the NIOS appliance second. When
the appliance assigns an IP address from the quarantined DHCP range, it also includes the static route that you
specified in option 33. For information about configuring DHCP options, see Specifying Custom DHCP Options on
page 494. On a routed network, you must configure a default route via the router on the subnet.
Guest DHCP Range
Configure a guest DHCP range if you want to provide guest access privileges. You can limit guest user access to only
authorized resources, such as the Internet, while denying access to restricted resources, such as the corporate
network. When you enable guest access, you can configure a guest registration page as well. For information about
this feature, see About Guest Access on page 596.
Authorized DHCP Range
You must configure a DHCP range for authorized users so the NIOS appliance can assign IP addresses within that
range to authorized DHCP clients. Users that receive an IP address in this range are allowed full access to the network.
When you configure a DHCP range for authorized users, the appliance automatically generates a MAC address filter
for the authorized DHCP range. When a client successfully passes authentication, the appliance automatically stores
its MAC address in the corresponding MAC address filter. When the client attempts to renew the lease at the midpoint
of its lease time, the appliance matches the source MAC address in the request with a MAC address in the filter for
the authorized DHCP address range. The appliance then assigns the client a new IP address from the authorized
DHCP range.
NAC Foundation
User Class Assignments
If you are using Microsoft Active Directory (AD) to store user accounts, you can use the User Class Assignments (UCA)
feature to determine the DHCP range for any previously defined AD user that belongs to a group. Using UCA, the
appliance can assign an authorized user class for individual users based on the AD group to which each user belongs.
When you create a DHCP range for a UCA, the NIOS appliance automatically creates a corresponding MAC address
filter. When a user that belongs to a specified UCA attempts to connect to the network and the user is successfully
authenticated, the appliance stores the MAC address of the client in the MAC address filter for the UCA and assigns
it an IP address from the range defined for that particular UCA. If a user belongs to more than one group, then the
appliance assigns it an IP address from the first group listed. If you have multiple groups, you can use the Move Up
and Move Down functions to list the UCAs in the order in which the appliance must match users.
Binding DHCP Ranges to the Quarantined and Authorized Levels
After you configure the DHCP ranges for each access level; quarantine, authorized and optionally, guest; you must
then bind each range to its access level. For information about configuring guest access, see About Guest Access on
page 596.
In addition, you must specify a prefix that the appliance prepends to MAC address filters it automatically generates
for the guest and authorized DHCP ranges. You can configure the MAC addresses in the guest and authorized MAC
address filters to expire after a certain amount of time has passed. Filter expiration is useful in situations where you
want to keep filters running against updated MAC addresses. MAC addresses may become invalid after a certain
period of time has passed. You can avoid removing invalid addresses from address filters manually by configuring
the NIOS appliance to expire filters or specific addresses within filters.
To bind DHCP ranges to the quarantined and authorized levels:
1. From the AAA perspective, click AAA Members -> + (for grid) -> member -> Edit -> Member AAA Properties -> + (for
DHCP Authentication).
Enable DHCP authentication: Select this check box.
MAC Filter Name Prefix: Enter the prefix that the appliance prepends to the MAC address filters for the guest
and authorized DHCP ranges. This prefix must be unique within the grid, if multiple grid members are using
this feature.
2. Click + (for DHCP Authorization).
Quarantine DHCP Range
Quarantine DHCP Range: Click Add to select the IP address range that the appliance uses for quarantined
addresses. The appliance assigns IP addresses from this range to unauthorized clients.
Enforce quarantine lease time: Select this check box to override the lease time for the DHCP range.
Quarantine Lease Time (seconds): Infoblox suggests 30-second leases for addresses in the quarantined
DHCP range.
Authorized MAC Address Expiration:
Never Expires: Select this option for the appliance to store MAC addresses in the MAC address filter
until they are manually removed.
Automatically Expires: Select this option for the appliance to store MAC addresses in the MAC address
filter for the specified period of time.
Expires In: Specify the duration of time the appliance stores MAC addresses in the MAC address filter.
Enable User Class Assignment: Select this check box to enable UCA (user class assignment). You can use
AD groups to determine the DHCP range for any previously defined AD user that belongs to a group.
Uploading Files for Customization
Authorized DHCP Range: Click Add to add an IP address range that the appliance uses for authorized
addresses. The appliance assigns IP addresses from this range to users that are authorized to access the
network.
If you enabled UCA, enter the UCA group name for each DHCP range. If you specified multiple groups, you
can use the Move Up and Move Down functions to list the groups in the order in which the appliance must
match the users groups.
Uploading Files for Customization
You can customize the captive portal, and if configured, the self service portal and guest registration page as well.
You can upload image files to the appliance and display your own logo, header and footer. In addition, you can upload
upload the acceptable use policies that are displayed on the captive portal and guest registration page.
Perform the following tasks to customize the captive portal, self service portal, and guest registration page:
1. Upload the logo, header and footer images to the grid master, as described in this section.
2. Configure the captive portal as described in Configuring the Captive Portal on page 590. Configure the self
service portal, as described in Configuring the Self Service Portal on page 593. Configure the guest registration
page, as described in About Guest Access on page 596.
Uploading Files
To upload image files and the acceptable use policy file:
1. From the AAA perspective, click View -> Customized Captive Portal Files.
2. In the Customized Captive Portal Files panel, click Root Directory -> right-click -> Add File. Following are the
requirements for each file:
Logo Image: The maximum size is 200 pixels x 55 pixels, and the images can be in the following
formats: GIF, JPEG, TIF, and PNG. It displays on top of the header image.
Header Image: The optimal size is 600 pixels wide by 137 pixels high. The image can be in the
following formats: GIF, JPEG, TIF, and PNG. The header displays at the top of the page.
Footer Image: The optimal size is 600 pixels wide by 20 pixels high. The image can be in the
following formats: GIF, JPEG, TIF, and PNG. The footer displays at the bottom of the page.
Acceptable Use Policy: The policy must be saved as an UTF-8 encoded file. It appears below the
welcome message in the Captive Portal. Users can scroll through the policy when they review it.
This is used in the captive portal and guest registration page.
3. Navigate to the image or text file you want to upload to the appliance, and then click OK.
You can create subdirectories under the root directory and store the files in different subdirectories. For example, you
might want to store files for the captive portal and the self service portal in different folders.
Creating Subdirectories
To create a subdirectory under the root directory:
1. From the AAA perspective, click View -> Customized Captive Portal Files.
2. In the Customized Captive Portal Files panel, click Root Directory -> right-click -> Add Directory.
3. In the Add Directory editor, enter the name of the directory you are adding.
NAC Foundation
Managing the Image Files
You can view the files that you uploaded, click View -> Customized Captive Portal Files. Expand the root directory and
subdirectories to navigate through the files. To remove a file, select it, right-click -> Remove file name.
Configuring the Captive Portal
All DNS queries from clients are resolved by the NIOS appliance comparing a quarantined address to the captive
portal IP address. A captive portal is a web page to which unauthorized users are directed. It provides options to
register and login as a guest user. In a grid, you must configure a grid member to host the captive portal. On this grid
member, you configure an additional IP address on the loopback interface. This IP address is the captive portal IP
address. To configure an IP address on the loopback interface, see Configuring IP Addresses on the Loopback
Interface on page 450.
In addition, in order for clients to reach the captive portal, you must specify a route to the captive portal. In a network
where all IP addresses are on the same subnet, you can configure Option 33 for the quarantined DHCP range. For
additional information, see Quarantined DHCP Range on page 587. On a routed network, you must configure a
default route on the router for the subnet.
To configure the captive portal on a NIOS appliance:
Portal IP Address: Select the IP address of the captive portal server. The NIOS appliance resolves all DNS
queries from clients with a quarantined address to this portal IP address. You must first configure this
address on the loopback interface of a grid member. To configure this IP address, see Configuring IP
Addresses on the Loopback Interface on page 450.
Comment: Enter pertinent information about the captive portal.
3. Customize the portal by entering the following information in the Authentication Page Customization section of
the editor:
Company Name: Enter the name of your company. The company name displays on the title bar of the
browser. You can enter a maximum of 200 characters.
Welcome Message: Type the message that displays on the captive portal. The message can contain a
maximum of 200 characters.
Help Desk Message: Type a message that provides Helpdesk information, such as contact information for
technical assistance. The message can contain a maximum of 200 characters.
Logo Image, Header Image, Footer Image, Acceptable Use Policy: To display the image files and the
acceptable use policy, click Browse beside each and navigate to the image and text files that you previously
uploaded. Select the files you want to display. For information on file requirements and uploading files, see
Uploading Files for Customization on page 589.
The appliance automatically adds the portal IP address to the DNS server list of the quarantined DHCP range. To
view this IP address, access the DHCP Range editor of the quarantined DHCP range by selecting the DHCP and
IPAM perspective -> Networks -> addr_range -> Edit -> DHCP Range Properties.
About Client Validation
About Client Validation
You can configure the NIOS appliance to run a pre-authentication check for client systems attempting to connect to
the network. The appliance can connect to a server running McAfee ePolicy Orchestrator version 3.6 to validate the
MAC address of client systems requesting authorization. The appliance provides additional support for the McAfee
Policy Enforcer version 2.0.
You can configure the NIOS appliance to connect to multiple McAfee servers for failover purposes. When you enable
this feature, the appliance tries to connect to and query the first server on the list. if it fails, then it tries the next server
on the list, and so on.
Perform the following tasks to configure the NIOS appliance to validate client systems through the McAfee server:
1. Specify the properties of the McAfee service, as described in Configuring the McAfee Service.
2. Enable McAfee validation, as described in Enabling Validation on page 592.
Configuring the McAfee Service
To configure the properties of the McAfee service:
1. From the AAA perspective, click External Servers -> McAfee Validation Services -> Edit -> Add McAfee Validation
Service.
2. In the McAfee Validation Service editor, enter the following:
Name: Enter a name for the McAfee service that you are configuring.
Data Source Name (DSN): Enter the name of the MS SQL Database instance to which the appliance
connects.
Comment: Enter pertinent information about the server.
Disable this McAfee authentication service: Select this check box to retain an inactive McAfee server
profile.
Username: Enter a user name that is authorized to access the database on the McAfee server.
Password: Enter the password for the McAfee server.
Retype Password: Retype the password.
ePolicy Orchestrator Verification Addition(s)
With McAfee policy enforcement: Select this check box if you want the server to check if McAfee Policy
Enforcer is installed on the client system.
Max days since last update: If support for McAfee Policy Enforcer (MPE) is not enabled, enter the maximum
number of days that a client system is allowed to access the network before it must be validated again by
the McAfee server.
If support for McAfee Policy Enforcer is enabled, enter the maximum number of days that a client system is
allowed to access the network before it must be scanned by the MPE agent to ensure policy enforcement.
McAfee Validation Server Failover List: Click Add, and in the McAfee Validation Server dialog box, enter the
IP address and port of the McAfee server. Click OK to close the dialog box. The NIOS appliance tries to
connect with the first server on the list. If it is unable to connect, it tries the next server on the list, and so
on. You can change the order in which the servers are listed by selecting a server and clicking Move up or
Move down.
Connect timeout (sec.): The number of seconds that the NIOS appliance waits to connect to the server.
Query timeout (sec.): The number of seconds that the NIOS appliance waits for a response from the McAfee
server.
NAC Foundation
Enabling Validation
To enable client system validation as a pre-authentication check:
2. In the DHCP Authentication section, enter the following:
Enable McAfee validation: Select this check box to enable client system validation through the McAfee
server.
McAfee Name: From the drop-down list, select the McAfee validation service the appliance uses for client
validation.
About Authentication
After a client system passes the pre-authentication check, the user authentication process begins. A user must be
successfully authenticated before the NIOS appliance assigns it an IP address from the authorized range. The
appliance supports the following authentication services:
Local user database
Replicated Active Directory accounts
Active Directory service
LDAP (Lightweight Directory Access Protocol)/LDAPS (LDAP over SSL) service
RADIUS (Remote Authentication Dial-In User Service) service
To configure authentication:
1. Configure the authentication service you want to use. You can configure multiple authentication services.
To add and manage users on the local database, see Managing the Local User Database on page 592.
To import accounts from Active Directory, see Importing Accounts from an Active Directory Server on page
594.
To configure an Active Directory authentication service, see Configuring LDAP/LDAPS Authentication
Services on page 594.
To configure an LDAP/LDAPS authentication service, see Configuring LDAP/LDAPS Authentication Services
on page 594.
To configure an external RADIUS authentication server, see Specifying an External Authentication Home
RADIUS Server on page 596.
2. Enable authentication and specify the authentication policy of the appliance. The authentication policy defines
which authentication services the appliance should use and whether logging is enabled. For information, see
Configuring the Authentication Policy on page 595.
Managing the Local User Database
You can configure the NIOS appliance to authenticate users against its local database. You can enter user names and
passwords through the GUI and the appliance stores the user information on its local database. When you use local
authentication, you can allow users to manage their own user credentials as well. You can create a self service portal
where users can change their passwords.
To authenticate users from the local database of the appliance:
1. Add user accounts to the database. See Adding User Accounts.
2. Select In-Grid User Authentication as the authentication method. See Configuring the Authentication Policy on
page 595.
3. Optionally, configure the self service portal. See Configuring the Self Service Portal on page 593.
Adding User Accounts
To add a user account to the local database:
1. From the AAA perspective, click Local User Store -> In-Grid User Accounts -> Edit -> Add User.
2. In the Add User editor, enter the following:
Disable this user account: Select this check box to retain an inactive profile for this user.
Username: Enter the name that the user enters to log in to the network.
Comment: Enter information about the user, such as location or department.
Password: Enter the password for the user to enter when logging in.
Retype password: Enter the password.
To view user accounts, from the AAA perspective, click User Store -> View -> User Accounts. You can select a user
account and view and edit its properties, or remove it by clicking Edit -> Remove.
Configuring the Self Service Portal
When you store user credentials on the local database, users can change their passwords on a self service portal that
you configure. (Note that this is different from the captive portal described in Configuring the Captive Portal on page
590.)
When the self service window displays, the user can then enter the new password. When the user changes the
password in the self service portal, the appliance automatically updates its local database.
To configure a self service portal:
Self Service Portal).
Enable Self Service Portal: Select this check box to activate the self service portal. Users with user names
and passwords stored in the local database can access this portal to change their passwords.
Welcome Message: Enter the message that displays on the self service portal. You can enter a maximum of
200 characters.
Help Desk Message: Enter a message that provides Helpdesk information, such as contact information for
technical assistance. You can enter a maximum of 200 characters.
For users to access the self service portal, they must open a browser window and enter the IP address of the grid
member that hosts the self service portal and append /self-service to the IP address. For example, if the IP address
of the self service portal is 10.34.10.253, the user must open a browser window and enter the following to access
the self service portal: https://10.34.10.253/self-service
NAC Foundation
Importing Accounts from an Active Directory Server
Infoblox provides the Infoblox Grid Connector for Active Directory that you can download from the Infoblox support
site and install on a Microsoft Active Directory (AD) server. You can configure a NIOS appliance to communicate with
the grid connector and import user names and passwords from the AD server. The appliance can then authenticate
users against the replicated user accounts.
Importing User Accounts
To configure a NIOS appliance to import user accounts from an Active Directory server, see Importing Users From a
Microsoft Active Directory Server on page 620.
Configuring Active Directory Services
You can configure the appliance to authenticate users against an Active Directory service. Active Directory is a
distributed directory service that authenticates network users and provides the location and authorizes access to
services running on devices in a Windows network.
To configure an Active Directory service:
1. From the AAA perspective, click External Devices -> AD Authentication Services -> Edit -> Add AD Authentication
Service.
2. In the AD Authentication Service Properties editor, enter the following:
Name: Enter a name for the service.
Port: Enter the port number on the AD server to which the appliance sends authentication requests.
Transport Encryption: Select SSL to transmit through an SSL (Secure Sockets Layer) tunnel. Infoblox
strongly recommends that you select this option to ensure the security of all communications between the
NIOS appliance and the AD server. If you select this option, you must upload a CA certificate from the AD
server. For information about uploading a CA certificate, see Uploading Certificates to the Appliance on
page 627.
Comment: Enter pertinent information about the service.
Disable this AD authentication service: Select this check box to retain an inactive AD service profile.
AD Domain: Enter the DNS style name of the domain in which the user credentials are located.
AD Domain Controller Failover List: Enter the IP address of the AD server to which the NIOS appliance
connects. You can add multiple servers for failover purposes. The appliance tries to connect with the first
server on the list. If it is unable to connect, it tries the next server on the list, and so on. You can change the
order in which the servers are listed by selecting a server and clicking Move up or Move down.
Configuring LDAP/LDAPS Authentication Services
You can configure the NIOS appliance to authenticate users against an LDAP (Lightweight Directory Access Protocol)
or LDAPS (Lightweight Directory Access Protocol over SSL) server. LDAP/LDAPS is a distributed directory service used
to locate organizations, individuals, and other resources on the public Internet or on a corporate intranet. The
properties you specify on the appliance must match the parameters on the LDAP/LDAPS server.
To configure LDAP/LDAPS authentication, see Configuring LDAP Authentication on page 625.
Configuring the Authentication Policy
After you configure the properties of each authentication service you want to use, you can then specify the
authentication policy. It defines which authentication services to use and in what order. In addition, the NIOS
appliance can log authentication success and failure events to its internal syslog server and (if configured) to an
external syslog server as well. If you have configured a RADIUS accounting server, you can enable RADIUS accounting
to track the activities of each user on the network. To configure a RADIUS accounting server, see Configuring a RADIUS
Accounting Home Server Object on page 638.
To specify the authentication policy:
Enable DHCP authentication: Select this check box to enable the appliance to authenticate users through
the methods you specify.
Authentication: Click Add and when the Select Authentication Method dialog box opens, do the following:
Select the authentication method you want to apply.
Select which action the appliance performs when authentication through this method succeeds and
when it fails.
Click OK to close the dialog box and view the list of selected authentication methods.
The NIOS appliance performs the authentication methods in the order they are listed. After you add
authentication methods, you can use the Move up and Move down buttons to change the order of the list.
To change an authentication method or to change the action the appliance takes when authentication fails
through the selected method, click Modify.
You can change the action of the appliance when authentication fails.
You can replace the selected authentication method. Select the new service and click OK.
Optionally change the action of the appliance when the newly selected authentication method
fails, and then click OK. The new authentication service appears in the Authentication list box.
Enable RADIUS accounting: Select this check box to enable RADIUS accounting to track a users activities
during a session.
RADIUS Accounting Name: Select the name of the RADIUS accounting server you configured.
Log authentication success: Select this check box to log syslog messages when clients are successfully
authenticated. The appliance logs messages to its internal syslog and to external syslog servers that you
configured for the grid or grid member.
Level: Select the severity level of the messages that are logged to the external syslog servers that you
configured. When you choose a severity level, the appliance logs messages for that severity level plus
all messages for all severity levels above it. The lowest severity level is debug (at the top of the
drop-down list), and the highest severity level is emerg (at the bottom of the list).
Log authentication failure: Select this check box to log syslog messages when clients fail authentication.
The NIOS appliance logs messages to its internal syslog and to external syslog servers that you configured
for the grid or grid member.
Level: Select the severity level of the messages that are logged to the external syslog servers that you
configured. When you choose a severity level, the appliance logs messages for that severity level plus
all messages for all severity levels above it. The lowest severity level is debug (at the top of the
drop-down list), and the highest severity level is emerg (at the bottom of the list).
NAC Foundation
Specifying an External Authentication Home RADIUS Server
You can configure the NIOS appliance to authenticate users against an external RADIUS server. RADIUS servers
provide authentication, authorization, and accounting (AAA) services.
To enable the NIOS appliance to communicate with a RADIUS authentication server:
1. From the AAA perspective, click External Servers -> RADIUS Authentication Home Servers -> Edit -> Add RADIUS
Authentication Home Server.
2. In the Authentication Home Server editor, enter the following:
Disable this server: Select check box to disable the ability of the NIOS appliance to communicate with this
RADIUS server. Clear check box to enable communication with this particular server.
Name: Type a name for the RADIUS authentication home server that is meaningful for you. This does not
have to be the FQDN of the server.
Hostname: Type the IP address of the RADIUS authentication home server to which the NIOS appliance
connects.
Comment: You can type a useful note for yourself such as the location or owner of the RADIUS
authentication home server or the contact information of the remote RADIUS administrator.
Port: Enter the port number on the RADIUS server to which the NIOS appliance sends authentication
requests.
About Guest Access
When you enable guest access, the NIOS appliance displays a guest registration option on the captive portal. When
users select the guest registration option, they are prompted to enter information that you specify, such as the
following:
Name
E-mail
From
Visiting
After a user registers as a guest, the appliance stores the MAC address of the client system in the MAC address filter
for the guest range. When the client tries to renew its IP address, the appliance assigns it an IP address from the guest
DHCP range.
Setting up guest access involves the following steps:
1. Configure the DHCP range for guest users, so the appliance can assign IP addresses within that range to the client
systems of users that register as guests. For information about configuring DHCP ranges, see Chapter 14,
Managing DHCP Data, on page 459.
When you configure a DHCP range for guest access, the NIOS appliance automatically generates a MAC address
filter for the guest DHCP range. When a client registers as a guest, the appliance automatically stores its MAC
address in the corresponding MAC address filter. When the client attempts to renew the lease at the midpoint of
its lease time, the appliance matches the source MAC address in the request with a MAC address in the filter for
the guest DHCP address range. The appliance then assigns the client a new IP address from the guest DHCP
range.
2. Enable guest access and set the properties for the guest registration page. See Configuring Guest Access.
About Guest Access
Configuring Guest Access
Configuring guest access involves the following tasks:
Enable guest authentication.
Specify which fields are required on the guest registration page.
Customize the registration page to reflect your corporate identity.
Specify the MAC filter properties for the guest DHCP range.
Specify the DHCP range for guest users.
To configure guest access:
Guest Authentication:
Enable guest authentication: Select this check box to enable guest access privileges. When you enable this
feature, the appliance displays a guest registration option on the captive portal page.
The appliance displays certain fields on the guest registration page. Select the check boxes of the fields
that users are required to complete: Require First Name, Require Middle Name, Require Last Name, Require
Email, and Require Phone.
Custom Field 1 Custom Field 4: You can display up to four additional fields on the guest registration page.
To add a field to the guest registration page, enter a label for that field. Select Require to require users to
complete the field.
Authentication Page Customization:
Welcome Message: Enter the message that first displays. You can enter a maximum of 200 characters.
Help Desk Message: Enter a message that provides Helpdesk information, such as contact information for
technical assistance. You can enter a maximum of 200 characters.
Guest DHCP Range
Guest MAC Address Expiration:
Never Expires: Select this option for the appliance to store MAC addresses in the MAC address filter
until they are manually removed.
Automatically Expires: Select this option for the appliance to store MAC addresses in the MAC address
filter for the specified period of time.
Expires in: Specify the duration of time the NIOS appliance stores MAC addresses in the MAC address filter.
Guest DHCP Range: Click Add to add an IP address range that the appliance uses for guest addresses. The
appliance assigns IP addresses from this range to users that access the network as guests.
NAC Foundation
Viewing Guest and Authenticated Users
You can view the authenticated and guest users in the User Name column of the DHCP leases panel, IPAM panel, and
the DHCP lease history panel by navigating to any of the following panels:
-> DHCP Leases -> ip_addr -> View -> Properties.
-> IP Address Management -> ip_addr -> View -> Properties.
From the DHCP and IPAM Perspective, click View -> DHCP Lease History -> ip_addr -> View -> Properties.
The User Name column displays the name of the user who receives the lease for the IP address. The user name
enables you to differentiate between guest users and authenticated users.
If you log in as an authenticated user, your user name is whatever you choose when you log in. If you log in as a guest,
your user name is First: first_name Last: last_name.
For example, if your first name is John and last name is Doe and your user name is jdoe:
If you log in as an authenticated user, your user name is jdoe.
If you log in as a guest user, your user name is First: John, Last: Doe.
Figure 19.4 shows the DHCP Leases panel for an authorized user with the user name testuser1.
Figure 19.4 DHCP Leases Panel for an Authorized User
Viewing Guest and Authenticated Users
Figure 19.5 shows the DHCP leases panel for a guest user with the user name TestUser1.
Figure 19.5 DHCP Leases Panel for a Guest User
Figure 19.6 shows the DHCP lease history panel for authorized users.
Figure 19.6 Authorized User Names in the DHCP Lease History Panel
NAC Foundation
The following example shows how to configure the NAC Foundation module features. In this example, you:
1. Configure the IP address 10.31.10.222 on the loopback interface to host the captive portal (to which the NIOS
appliance resolves DNS queries from quarantined clients). See Configure a Loopback Interface on page 600
2. Configure a network with the IP address 10.10.10.0 and assign a member to it. See Configure a Network on page
600.
3. Add the DHCP address ranges 10.10.10.1 to 10.10.10.10 and 10.10.10.11 to 10.10.10.20 in your network. See
Create DHCP Address Ranges in the Network on page 601.
4. Bind the range 10.10.10.11 to 10.10.10.20 to the quarantine level and the range 10.10.10.11 to 10.10.10.20 to
the authorized level. See Bind DHCP Ranges to the Quarantined and Authorized Levels on page 601.
5. Configure the captive portal server and assign it the loopback interface IP address: 10.31.10.222. Configure the
Captive Portal on page 602.
6. Configure Active Directory authentication to authenticate users accessing the authorized DHCP range. See
Configure Authentication on page 603.
7. Enable the grid member to serve DHCP. See Enable DHCP on page 603.
Configure a Loopback Interface
On a grid member, configure an additional IP address on the loopback interface to host the captive portal.
To configure an IP address on the loopback interface:
3. In the Advanced IP Configuration section, click Add to open the Advanced IP Configuration dialog box so you can
configure a new IP address for the interface.
Network Address: Enter the IP address you want to configure on the interface as 10.31.10.222. You must
configure a static IP route to forward all queries to the loopback interface.
Bound Interface: Select the loopback interface as the physical interface to bind with the configured IP
address.
Netmask: Leave the default netmask value /32 as is.
Comments: Enter the text string: Loopback IP to help identify this interface and IP address.
5. Click OK.
Note: If you are configuring the interface on a grid master, the grid is temporarily disrupted when you save the
configuration and restart appliance services. The grid automatically reconnects and the appliance regains its
role as grid master after this short delay automatically.
Configure a Network
1. From the DHCP and IPAM Perspective, select Networks -> Networks -> Edit -> Add Network -> Network.
2. In the Add Configure Networks editor, enter the following the Network Properties section:
Address: Enter the IP address of the network as 10.10.10.0.
Netmask: Select the subnet mask /24 for the network.
4. Click Add.
5. Choose the grid member(s) that should serve DHCP for this network from the Select Grid Members dialog box.
Keep in mind, DHCP properties are inherited from this member. The network can be served by multiple members.
6. Click OK to close the Select Grid Members dialog box.
Create DHCP Address Ranges in the Network
Add the following DHCP address ranges in your network:
10.10.10.1 to 10.10.10.10
10.10.10.11 to 10.10.10.20
The following steps show you how to add the DHCP range 10.10.10.1 to 10.10.10.10 to a network. Use the same
steps to add the ranges 10.10.10.11 to 10.10.10.20.
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> Edit -> Add DHCP Range.
Start Address: Enter the first IP address in the range available for the clients as 10.10.10.1.
End Address: Enter the last IP address in the range available for the clients as 10.10.10.10.
Comment: Enter the text string (such as Authorized, Quarantine, and Guest) to help identify this address
range.
3. Click Member Assignment and select the following:
Grid Member: Select the member that serves DHCP for this IP address range. The NIOS appliance populates
the drop-down list with the local appliance andif the appliance is part of a gridany other grid members.
Configure AD Servers for Authentication
To configure the appliance to authenticate users with Active Directory services:
1. From the AAA perspective, click External Servers -> AD Authentication Services -> Edit -> Add AD Authentication
Service.
2. In the AD Authentication Service Properties editor, enter the following:
Name: Enter ad1.infoblox.com.
AD Domain: Enter infoblox.com.
AD Domain Controller Failover List: Enter the AD servers IP address.
Bind DHCP Ranges to the Quarantined and Authorized Levels
To bind DHCP ranges to the quarantined and authorized levels:
MAC Filter Name Prefix: Enter DHCPAuth.
NAC Foundation
Quarantine DHCP Range
Quarantine DHCP Range: Click Add to select the IP address range that the appliance uses for quarantined
addresses: 10.10.10.11 to 10.10.10.20. The appliance assigns IP addresses from this range to
unauthorized clients.
DHCP range.
Authorized DHCP Range: Click Add to add an IP address range that the appliance uses for authorized
addresses: 10.10.10.1 to 10.10.10.10. The appliance assigns IP addresses from this range to users that
are authorized to access the network.
DHCP range.
Configure the Captive Portal
To configure the captive portal on a NIOS appliance:
2. Enter the following information in the DHCP Authentication section:
Portal IP Address: Select the IP address of the captive portal server. This should be the loopback interface
IP address that you configured earlier. See Configure a Loopback Interface on page 600.
Configuring a Static Route
After you configure the captive portal, you must specify a static route to the captive portal so that clients can reach
it. See Quarantined DHCP Range on page 587 for more information.
To view the captive portal, open a web browser and enter the portal IP address. The captive portal appears as follows:
Configure Authentication
A user must be successfully authenticated before the NIOS appliance assigns it an IP address from the authorized
range. The appliance supports the following authentication services:
Local user database
Replicated Active Directory accounts
Active Directory service
LDAP (Lightweight Directory Access Protocol)/LDAPS (LDAP over SSL) service
RADIUS (Remote Authentication Dial-In User Service) service
This example shows you how to configure the Active Directory authentication:
Authentication: Click Add and in the Select Authentication Method dialog box:
Select the AD Authentication Services.
Click OK to close the dialog box and view the list of selected authentication methods.
Enable DHCP
To configure general DHCP properties for a grid member:
Properties.
2. In the Member DHCP Properties editor, click General Properties.
Enable DHCP Server: Select this check box to enable the grid member to serve DHCP. Service begins after
you save and restart services.
Verifying Your Configuration
To verify your configuration, view the authenticated and guest users in the User Name column of the DHCP leases
panel, IPAM panel, and the DHCP lease history panel. See Viewing Guest and Authenticated Users on page 598.
NAC Foundation

Chapter 20 File Distribution Services
This chapter provides an overview of the file distribution services provided on the NIOS appliance, and contains the
following sections:
File Distribution on page 606
Enabling and Configuring TFTP on page 607
Enabling and Configuring HTTP on page 608
Enabling and Configuring FTP on page 609
Managing Files on page 610
Creating a Directory Structure on page 610
Modifying File Distribution Storage Settings on page 611
Viewing Files on page 611
File Distribution Services
File Distribution
The NIOS appliance provides support for file transfers using TFTP, HTTP, and FTP. You can use the NIOS GUI or API to
upload files to the appliance. You can then allow specific network devices to retrieve the files using TFTP, HTTP, or FTP.
Network devices, such as VoIP phones, can use the DHCP service on the NIOS appliance for IP address assignments
and use the File Distribution service for IP device configuration downloads. Downloads can be accomplished with
TFTP, HTTP, or FTP.
Note: Only an administrator with superuser privileges can manage uploading files.
Figure 20.1 Uploading and retrieving files
You can store up to 10,000 files in binary and ASCII format on the NIOS appliance. It provides a total storage size of
5 gigabytes, with a default of 500 MB. You can create a directory structure and organize your files to match your
requirements. By default, the appliance includes the files when you back up the system.
For appliances in a grid, you can configure all or some grid members for file distribution services. Upload the files to
the active grid master, and it replicates the files to all potential grid masters and all members with TFTP, HTTP, or FTP
enabled.
After configuring File Distribution services on the NIOS appliance, you can do the following:
1 2
3 4
Administrator uploads a file on to
a directory in the NIOS appliance
using the GUI or API.
A host sends a request
for the file.
The appliance checks if it is
allowed to respond to the
request from the host.
If the host is on the list of those allowed to
retrieve a file, the appliance accepts the
request. If the host is not on the list of
allowed hosts or is on the list of denied
hosts, the appliance does not allow the host
to retrieve the file.
File NIOS appliance
Host
TFTP, HTTP, or FTP
Enabling and Configuring TFTP
Enabling and Configuring TFTP
The TFTP service is disabled on the appliance by default. To allow file distribution access using TFTP, you must enable
the TFTP service on the NIOS appliance and then specify the hosts that are allowed to use the service. If you do not
specify this information, the appliance denies access to all hosts. The appliance provides read-only access to the
files.
To enable TFTP on the appliance:
1. From the File Distribution perspective, click the File Distribution Members tab, and then select +(for grid) ->
grid_member -> Edit -> Member FD Properties -> TFTP Service.
2. In the TFTP Service section of the Member File Distribution Properties editor, do the following:
Enable TFTP Service: Select this check box.
Listen on Port: Enter the number of the port on which the appliance receives TFTP requests. The default is
port 69.
Allow TFTP request from: Click Add, enter the following information in the TFTP Access Item dialog box, and
then click OK:
IP Address: Select and enter the host IP address in the Address field.
Network: Select and enter the network IP Address, and choose a CIDR (Classless Inter-Domain Routing)
netmask for the subnet to which the IP address connects.
Any: Select to accept requests from any host.
Permissions: Click Allow or Deny.
If you specify Deny permissions for a host, then the appliance allows all other hosts (except the one that
is denied) to access its TFTP server.
3. To modify a host or network specified for TFTP requests, click Modify and change the settings as needed. You can
remove a host or network by selecting it, and then clicking Remove.
Enabling and Configuring HTTP
To allow file distribution access using HTTP, you must enable the HTTP service on the NIOS appliance and then specify
hosts allowed to request the service.
Before you enable HTTP service, however, you should be aware of the following configuration rules:
HTTP only runs on the active member of an HA pair.
HTTP can run on the master or any member.
HTTP always runs on the LAN port, never the MGMT port.
HTTP to HTTPS redirect becomes non-functional if File Distribution is turned on and all administrative access is
run on the LAN port. For more information on HTTP redirect, Enabling HTTP Redirection on page 130. For
information on how to specify the MGMT port for HTTP, see Using the MGMT Port on page 136.
To enable HTTP on the NIOS appliance:
grid_member -> Edit -> Member FD Properties -> HTTP Service.
2. In the HTTP Service section of the Member File Distribution Properties editor, do the following:
Enable HTTP Service: Click this check box.
Enable file distribution HTTP access restrictions: Click this check box.
Allow file distribution HTTP requests from: Click Add, enter the following information in the HTTP File
Distribution Access Item dialog box, and then click OK:
Address: Select and enter the host IP address in the Address field.
Network: Select this check box, specify the network IP address in the Address field, and then select the
netmask.
3. To modify a host or network, click Modify and change the settings as needed. You can remove a host or network
by selecting it, and then clicking Remove.
Enabling and Configuring FTP
Enabling and Configuring FTP
FTP is disabled on the NIOS appliance by default. To allow file distribution access using FTP, you must enable the FTP
service on the NIOS appliance and then specify the hosts that are allowed to use the service. The appliance provides
(anonymous) read-only access to the files.
To enable FTP on the appliance:
grid_member -> Edit -> Member FD Properties -> FTP Service.
2. In the FTP Service section of the Member File Distribution Properties editor, do the following:
Enable FTP Service: Click this check box.
Listen on Port: Enter the port number on which the appliance receives FTP requests. The default is port 21.
Login Banner: Enter your own login banner text that appears after you establish an FTP connection or leave
the default (Restricted Access Only) as is.
Enable FTP passive mode: Leave this check box selected (default) to enable FTP in passive mode;
otherwise, it is in active mode. An FTP connection between a client and server can be in active or passive
mode. In active mode, the server initiates the data connection. In passive mode, the client initiates the data
connection. Depending on the organizations firewall policy, firewalls can block active mode connections.
There is no firewall filtering in passive mode.
Enable FTP file listing: Click this check box to allow users to list files and subdirectories on the NIOS
appliance.
Allow FTP request from: Click Add, enter the following information in the FTP Access Item dialog box, and
then click OK.
IP Address: Select and enter the host IP address in the IP Address field.
Network: Select this check box, specify the network IP address in the IP Address field, and then select
the netmask.
Any: Select to accept requests from any host.
Permissions: Click Allow or Deny.
If you select Deny, then the appliance allows all other hosts (except the one that is denied) to access its FTP
service.
3. To modify a host or network (specified for FTP requests), click Modify and change the settings as needed. To
remove a host or network select it and click Remove.
Managing Files
You can manage files in the following ways:
Uploading Files
Creating a Directory Structure
Uploading Files
You can upload a maximum of 10,000 files. When you upload a file, the NIOS appliance compares the file size with
the available storage. If there is enough space, it uploads the file. If uploading the file exceeds the storage limit, the
appliance displays a warning message and does not upload the file. For information about File Distribution storage,
see Modifying File Distribution Storage Settings on page 611.
Note: If you upload a file that has the same name and path as an existing file, the appliance automatically replaces
the old file.
To upload files:
1. From the File Distribution perspective, click Directories.
2. Select the destination directory.
3. Select Edit -> Add File.
4. Navigate to the file, select it, and then click Open.
Creating a Directory Structure
To facilitate file management, you can create a directory structure in which to store your files.
To create a directory for files:
1. In the File Distribution perspective, click Directories.
2. Click the parent directory and select Edit -> Add Directory.
3. In the enter the Add Directory editor, enter the name of the directory.
To modify a directory, select it, make your changes, and then click the Save icon. To remove a directory, select it, and
then select Edit -> Remove directory.
Note: When you remove a directory, the appliance automatically removes the directorys contents as well.
Managing Files
Modifying File Distribution Storage Settings
On a grid with Infoblox NIOS appliances, the maximum storage space for File Distribution files is 2 gigabytes. On a
grid with NIOS virtual appliances as grid members, the maximum storage is 1 gigabyte. The default is 500 MB.
To change the File Distribution storage settings:
1. From the File Distribution perspective, click the File Distribution Members tab, and then select grid -> Edit ->
GridTFTP Properties.
2. In the Grid FD Properties editor, enter a value in the Storage Limit (in Megabytes) field.
3. To ensure that the appliance includes the files in the backup process, click the Include files and directories in
system backup check box.
Viewing Files
To view files:
1. In the File Distribution perspective, click Directories.
2. Click the Directories tab and select a directory.
3. Select View -> Files.
4. Sort and view files in the following ways:
Enter a Page number to go directly to a page in the list.
Sort the files in a directory by name, size, or the date a file was last modified by clicking the appropriate
column heading.
Use the navigation buttons at the bottom of the viewer to page through the list of files.

Chapter 21 RADIUS Services
This chapter describes the RADIUS (Remote Authentication Dial-In User Service) service that the NIOS appliance
provides. This chapter contains the following sections:
Understanding RADIUS on page 615
Infoblox RADIUS Services on page 616
RADIUS Servers in a Grid on page 617
Authentication Methods on page 618
Accounting on page 618
Configuring RADIUS Services on page 619
Managing User Accounts in the Local Database on page 620
Adding Users on page 620
Adding Users on page 620
Importing Users From a Microsoft Active Directory Server on page 620
Viewing Imported Users and Groups on page 622
Configuration Example: Importing Users from AD Servers on page 622
Troubleshooting AD Error Messages on page 624
Configuring LDAP Authentication on page 625
Managing Certificates on page 626
Generating a Self-Signed EAP Certificate on page 626
Generating a Certificate Signing Request on page 626
Uploading Certificates to the Appliance on page 627
Downloading Certificates from the Appliance on page 627
About RADIUS Policies on page 628
Defining Policies for User Groups on page 629
Using RADIUS Policies on page 630
Configuring RADIUS Policies on page 630
Managing Policies on page 631
Configuring RADIUS Policy Groups on page 631
Managing Policy Groups on page 631
Assigning a Policy Group to a Grid Member on page 631
Network Access Servers on page 632
RADIUS Services
Enabling RADIUS Services on page 633
RADIUS Authentication on page 633
RADIUS Accounting on page 634
Understanding RADIUS Proxy Services on page 635
RADIUS Home Servers on page 637
Configuring a RADIUS Authentication Home Server Object on page 638
Configuring a RADIUS Accounting Home Server Object on page 638
Managing RADIUS Proxy Services on page 639
Proxying RADIUS Access-Requests on page 640
Viewing the RADIUS Configuration File on page 640
Proxying RADIUS Accounting-Requests on page 640
Removing Home Servers and Shared Secret Relationships on page 641
Understanding RADIUS
Understanding RADIUS
RADIUS (Remote Authentication Dial-In User Service) provides authentication, authorization, and accounting (AAA)
services so you can control access to your network and track the activities of users on the network.
RADIUS is a client-server protocol where the client is a network access server (NAS) configured to use RADIUS.
Figure 21.1 illustrates the basic RADIUS authentication, authorization and accounting process. The NAS collects the
user name and password from a user that tries to connect to the network. The NAS creates an Access-Request packet
that contains certain attributes, such as the user name and password, and sends the packet and its own identifier to
the RADIUS server. When the RADIUS server receives the request, it processes the attributes and attempts to
authenticate the user based on the parameters in the user database. If the RADIUS server authenticates the user, it
sends an Access-Accept packet that contains authorization information to the NAS, which in turn allows the end user
to connect to the network. If the RADIUS server is unable to authenticate the users credentials, the RADIUS server
sends an Access-Reject packet to the NAS, which in turn rejects the connection from the end user.
Figure 21.1 RADIUS Authentication and Accounting Process
1
3
2
4a
4b
4c
A user connects to a NAS and enters
a user name and password.
A u
The NAS creates an Access-Request
packet with the user name and
password and sends the packet and its
own identifier to the RADIUS server.
The RADIUS server accesses the
user database and attempts to
authenticate the user.
The NAS allows the user to access the
network.
The NAS does not allow the user to
access the network..
If the RADIUS server authenticates the
user, it sends back an Access-Accept
packet.
If the RADIUS server rejects the
authentication request, it sends back an
Access-Reject packet.
The NAS server then sends an
Accounting-Request packet to the
RADIUS server. The RADIUS server
responds with an Accounting-Response
packet.
The RADIUS server can send an
Access-Challenge packet that contains a
challenge for the user.
The NAS forwards the Access-Challenge
packet to the user, who calculates the
response and sends it to the NAS.
The NAS sends another Access-Request
packet with the challenge response to the
RADIUS server, which can send another
Access-Challenge packet, or send an
Access-Accept or Access-Reject packet.
Client
Network Access
Server (NAS)
RADIUS
Server
RADIUS Services
Infoblox RADIUS Services
You can configure a NIOS appliance to provide RADIUS authentication and accounting services. As a RADIUS server,
the NIOS appliance can authenticate users against its local database and against external user stores on Novell
eDirectory and LDAP servers, as shown in Figure 21.2.
Figure 21.2 Infoblox RADIUS Authentication
There are two ways to enter user accounts on the NIOS appliance. You can enter user names and passwords through
the Device Manager or Grid Manager GUI, and import user names and passwords from an Active Directory server. To
import user names passwords from an AD server, you must install the Infoblox Replication Agent on the server. See
Importing Users From a Microsoft Active Directory Server on page 620 for more information.
The NIOS appliance supports authentication using PAP (Password Authentication Protocol) and 802.1x
authentication, the standard for port-based authentication. In 802.1x networks, the wired or wireless client is a
supplicant that tries to access network services through a network access server (NAS), which is called the
authenticator. The authenticator communicates with a RADIUS server to authenticate the supplicant. For information
about the authentication protocols that Infoblox supports, see Authentication Methods on page 618. The NIOS
appliance can operate with any NAS (wireless access points, for example) that supports RADIUS.
For RADIUS authentication, the NIOS appliance supports single-byte international character sets for Windows
environments and UTF-8 encoding for other platforms. For information about UTF-8 support on NIOS appliances, see
Multilingual Support on page 58. You can configure the NIOS appliance to be a RADIUS server for RADIUS
authentication. If you want the RADIUS server to support wireless supplicants on a Windows client that does not use
a Latin 1 (1252) codepage, you must change the default codepage on the NIOS appliance to match the clients set
up. The NIOS appliance uses the codepage to translate single-byte characters into UTF-8 encoded characters. For
information about how to enable RADIUS authentication and configure codepages, see RADIUS Authentication on
page 633.
You can also configure an appliance to proxy Access-Requests and Accounting-Requests between network access
servers and RADIUS authentication and accounting home servers. When there is a large number of network access
servers, proxying RADIUS requests through NIOS appliances reduces the number of sources from which a RADIUS
home server needs to allow requests. For addition information on configuring the appliance as a RADIUS proxy server,
see Understanding RADIUS Proxy Services on page 635.
A
c
c
e
s
s

R
e
q
u
e
s
t
A
c
c
e
p
t
/
R
e
je
c
t
A
cce
s
s R
e
q
u
e
st
A
ccep
t/R
e
je
ct
A
u
th
e
n
tica
te
A
cce
p
t/R
e
je
ct
A
u
t
h
e
n
t
ic
a
t
e
A
c
c
e
p
t
/
R
e
je
c
t
Authenticate
Accept/Reject
NIOS database with
local and replicated
users
LDAP server
NIOS
Appliance
NAS
authenticator
Client
Client
RADIUS Servers in a Grid
As shown in Figure 21.3, you can use the Infoblox grid technology to centrally manage authentication services in your
network and to provide security for wireless access from remote sites. You can deploy the grid master in a central
location, such as a corporate data center, and deploy the grid members in remote or branch offices. Through the grid
technology, the grid master replicates the user database to all members in the grid on which RADIUS is enabled. Thus
the grid members can provide authentication services in the branch offices, ensuring local survivability should the
WAN link to the corporate data center fail.
Figure 21.3 Managing Authentication Services Using the Grid
A NIOS appliance stores user names and
passwords in its local database. In a grid, the grid
master replicates the RADIUS user database to the
members that have RADIUS enabled.
RADIUS Server and Access
Point in Remote Office
When a supplicant connects to
the access point (AP) at the
remote site and enters a user
name and password, the AP
accesses the RADIUS server
in the remote site to
authenticate the supplicant.
If the RADIUS server successfully authenticates the
supplicant, the AP allows the supplicant to access the
network services.
Grid Master in Corporate
Data Center
Supplicants
RADIUS Services
Authentication Methods
The NIOS appliance supports PAP (Password Authentication Protocol) and 802.1x authentication. 802.1x use EAP
(Extensible Authentication Protocol), a general protocol for securely transmitting authentication information over
wired and wireless networks. Infoblox supports multiple EAP authentication methods, including
PEAP/EAP-MS-CHAPv2, PEAP/EAP-GTC, EAP/TLS and EAP/TTLS. The following sections summarize each
authentication protocol that Infoblox supports.
PAP
PAP (Password Authentication Protocol) tries to establish the identity of a host using a two-way handshake. The host
sends the user name and password in clear text to the NAS, which uses a shared secret to encrypt the password and
then sends it to the RADIUS server in an Access-Request packet. The RADIUS server uses the shared secret to decrypt
the password. If the decrypted password matches a password in its database, the host is successfully authenticated
and the RADIUS server sends an Access-Accept packet to the NAS.
PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC
PEAP (Protected Extensible Authentication Protocol) provides authentication in two phases. In the first phase, the
RADIUS server presents its digital certificate to authenticate itself to the client, and the client and RADIUS server
establish an encrypted TLS (Transport Layer Security) channel to provide a secure way to transmit authentication
information in the second phase. In the second phase, the client authenticates itself using a Generic Token Card
(GTC) for (PEAP/EAP-GTC).
EAP/TLS
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) provides mutual authentication through the
TLS handshake. Both the client and the RADIUS server authenticate themselves using x.509 certificates. For
information on managing certificates on the NIOS appliance, see Managing Certificates on page 626.
EAP/TTLS, EAP-PAP
EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security) provides mutual authentication
without the use of client certificates. EAP-TTLS requires only a server certificate and creates an end-to-end tunnel to
continue the authentication process using another EAP method or PAP.
Accounting
You can enable the accounting feature on the NIOS appliance server to track a users activities during a session. After
a user successfully logs in, the NAS sends an Accounting-Start packet to the RADIUS server. To better manage the
logs, you can designate one grid member as the accounting log member. The maximum log size is 2M. You can
download the accounting logs for later analysis.
Configuring RADIUS Services
You can enable a NIOS appliance to provide RADIUS authentication and accounting services. In a grid, you can
selectively enable RADIUS services on each grid member. Following are the steps for configuring an appliance to
provide RADIUS services:
1. To authenticate users against the local database, add the user names and passwords.
To enter user names and passwords using the Device or Grid Manager GUI, see Adding Users on page 620).
To import user accounts from an Active Directory server, see Importing Users From a Microsoft Active
Directory Server on page 620.
2. To authenticate users against a Novell eDirectory and LDAP service, configure the authentication service, as
described in Configuring LDAP Authentication on page 625.
3. Generate or upload an EAP (Extensible Authentication Protocol) certificate. See Managing Certificates on page
626.
4. Optionally, configure RADIUS policies and policy groups. See About RADIUS Policies on page 628.
5. Configure the NIOS appliance to communicate with each NAS (Network Access Server) from which the appliance
receives authentication and accounting requests. For addition information, see Network Access Servers on page
632.
6. Configure the appliance as a RADIUS server. In a grid, you must configure each member to provide RADIUS
services. For addition information, see Enabling RADIUS Services on page 633.
RADIUS Services
Managing User Accounts in the Local Database
The NIOS appliance provides two ways to enter user accounts. You can enter user names and passwords through the
Device Manager or Grid Manager GUI, and you can import user accounts from an Active Directory server. When the
appliance stores user names and passwords in its local database, it encrypts all passwords. In addition, you can
create a self-service portal where users can update their passwords. For information about configuring the
self-service portal, see Configuring the Self Service Portal on page 593.
Adding Users
To add a user:
1. From the AAA perspective, click the User Store tab -> In-Grid User Accounts -> Edit -> Add User.
2. In the Add User editor, enter the following:
Disable this user account: Select this check box to retain an unactivated profile for this user.
Username: Enter the name that the user enters to log in to the network.
Comment: Enter information about the user, such as location or department.
Password: Enter the password for the user to enter when logging in.
Retype password: Enter the password.
Managing Users
To view local users, from the AAA perspective, click User Store -> In-Grid User Accounts -> View -> User Accounts. The
appliance lists the users in the User Accounts panel. You can select a user account and view and edit its properties,
or remove it by clicking Edit -> Remove.
Importing Users From a Microsoft Active Directory Server
Infoblox provides the Infoblox Grid Connector for Active Directory, which you can download from the Infoblox support
site and install on a Microsoft Active Directory (AD) server. You can then configure a NIOS appliance to communicate
with the grid connector and import user names and passwords from the AD server. In a network with multiple AD
servers, Infoblox recommends that you install the grid connector on a central AD server that stores all of the user
accounts.
You can install the grid connector on multiple AD servers and configure the appliance to communicate with each grid
connector for redundancy. When you configure multiple grid connectors, the appliance tries to communicate with the
grid connector at the top of the list. If it fails, then the appliance tries to connect to the next grid connector on the list,
and so on.
To ensure that the information in the database is always current, you can configure the appliance to poll the grid
connector periodically or to synchronize the AD domain at any instant. Communications between the grid master and
the grid connector are encrypted using SSL, so, you must install certificates on the grid connector and ensure that
you upload the same certificate on the NIOS appliance. After the appliance imports the user names and passwords,
it encrypts the passwords in its database.
In a grid, you enable the grid master to connect to the grid connector. The grid master then replicates the user
credentials from Active Directory to grid members in the other sites.
Note: The NIOS back up and restore feature (see Backing Up and Restoring a Configuration File on page 222) does
not back up or restore replicated users for security reasons.
Before you configure an AD domain, you must install the certificate used in the grid connector on the NIOS appliance.
1. Download the certificate that you installed on the grid connector to your computer.
2. Upload the same certificate to the NIOS appliance as follows:
From the AAA perspective, click the Certificates tab -> Tools -> Upload Certificate -> Upload CA Certificate.
Navigate to the certificate in your computer and click Open.
The certificate that you uploaded appears under CA Certificates.
To configure an appliance to import user accounts from an Active Directory domain on an Active Directory server:
1. From the AAA perspective, click User Store -> Replicated Users and Groups -> Edit -> Add AD Domain.
2. In the Add AD Domain editor, enter the following:
AD Domain Name: Enter the DNS domain name of the user accounts you want to import.
Comment: Enter pertinent information about the domain.
Synchronization Interval: Enter the interval, in minutes, at which the appliance polls the grid connector for
user information.
Last Synchronization Time: The appliance displays the time at which it last synchronized with the AD server.
Grid Connector for AD Failover List: Click Add to enter information about the AD server from which the
appliance imports the users and groups. In the Grid Connector for Active Directory dialog box, enter the
following information and click OK:
Host Name or Address: Enter the host name or the IP address of the interface to which the
appliance connects. This should be the same as the Common Name you entered in the grid
connector when you created a certificate. If you entered a name use the same name in this field; if
you entered an IP address, use the same IP address in this field. To check whether the AD server
can resolve the NTP server host name or IP address, click Resolve. If the server can resolve the host
name, the message: Addr ess i s val i d appears in the dialog box; otherwise, the appliance
displays an error that the address cannot be resolved.
Port: Enter the number of the port to which the appliance connects. The default port number is
1819.
Password: Enter the password the appliance sends to the agent to authenticate itself. This should
be the same as the password on the grid connector.
Re-type Password: Enter the password again.
Click OK to close the dialog box.
The appliance lists the server. You can add multiple servers for failover purposes. The NIOS appliance tries to
connect with the first server on the list. If it is unable to connect, it tries the next server on the list, and so on.
You can change the order in which the servers are listed by selecting a server and clicking Move up or Move
down. The order in which the policy groups are arranged determines the order by which they will be evaluated.
After you add the AD domain object to the appliance, it automatically imports the user accounts from the AD
server. After the initial import, the appliance then periodically polls the grid connector. If you change the user
accounts in the AD server, you can have the appliance immediately import the user accounts (overriding the
interval-based synchronization you specified in the AD Domain editor) as follows:
4. From the AAA perspective, click User Store -> Replicated Users and Groups -> Tools -> Replicated Domain
Information-> Synchronize With AD Domain Now.
5. Click Yes in the Synchronize Active Directory Users and Groups confirmation dialog box.
The appliance imports the updated user accounts from the AD server.
You can also view the syslog messages after you synchronize the appliance with the AD domain as follows:
From the Device perspective, click hostname -> File -> System Log -> ip_addr. The contents of the system log depend
on the debug level that you specified, one of Minimum, Low, Medium or High. See RADIUS Authentication on page
633.
RADIUS Services
You can only view the users and members in the groups. You cannot delete an individual user or group. However, you
can delete all users and groups at the domain level by selecting Tools -> Replicated Domain Information -> Delete
Replicated AD Users and Groups.
No user password information is contained in the system log.
Viewing Imported Users and Groups
You can verify your user accounts and replicated users and groups configuration as follows:
To view imported user accounts and groups, click View -> User Accounts. The appliance lists the user name and
comment in the User Accounts panel. You can select a user account and view its properties by selecting the user
name and clicking View Properties.
To view all users in an AD domain, from the AAA perspective, select Replicated Users and Groups -> Users. All
users in the AD domain appear on the right panel.
To view users who are members of a group, from the AAA perspective, select the User Store tab -> Replicated
Users and Groups -> Groups. The members of the group appear in the right panel.
Configuration Example: Importing Users from AD Servers
In this example, you connect the NIOS appliance to an AD server with the IP address 10.34.65.22 and a domain
qalab.infoblox.com with 30,000 users. You also connect the NIOS appliance to another AD server with the IP address
192.163.2.9 and a domain test.infoblox.com with 9000 users and multiple groups. Then, you use the Infoblox Grid
Connector to replicate all users and groups in the AD servers on the NIOS appliance.
1. Install and start the Infoblox Grid Connector for AD using the steps described in the Infoblox Grid Connector for
Active Directory Users Guide.
2. Download the certificate that you use for the grid connector to your computer.
3. Upload the same certificate to the appliance as follows:
From the AAA perspective, click the Certificates tab -> Tools -> Upload Certificate -> Upload CA Certificate.
Navigate to the certificate in your computer and click Open.
The certificate that you uploaded appears under CA Certificates.
4. From the AAA perspective, click User Store -> Replicated Users and Groups -> Edit -> Add AD Domain.
AD Domain Name: Enter qalab.infoblox.com
Comment: Enter QA domain.
Synchronization Interval: Enter 10.
appliance imports the user accounts. In the Grid Connector for Active Directory dialog box, enter the
Host Name or Address: Enter 10.34.65.22.
Port: Leave the default port number 1819 as is. This is the same port number that you entered on
the grid connector.
Password: Enter the password infoblox. This is the same password that you entered on the grid
connector.
7. From the AAA perspective, click the User Store tab -> Replicated Users and Groups -> Edit -> Add AD Domain.
AD Domain Name: Enter test.infoblox.com.
Comment: Enter test domain.
appliance imports the user accounts. In the Grid Connector for Active Directory dialog box, enter the
Host Name or Address: Enter 192.163.2.9.
Port: Leave the default port number 1819 as is.
Password: Enter the password infoblox.
10. Select the domain qalab.infoblox.com, right-click and select Synchronize With AD Domain Now.
11. Select the domain test.infoblox.com, right-click and select Synchronize With AD Domain Now.
12. Select Replicated Users and Groups -> Users to view all users in each AD domain.
All users in the AD domain appear on the right panel.
13. Select Replicated Users and Groups -> Groups to view all groups in each AD domain.
All users in the AD domain appear on the right panel.
14. Select Replicated Users and Groups -> Groups -> group_name to view all users in a group.
The members of the group appear on the right panel.
Figure 21.4 shows the replicated users and groups.
Figure 21.4 Replicated Users and Groups
RADIUS Services
Troubleshooting AD Error Messages
The following examples show syslog messages related to AD configuration.
Normal synchronization message:
( none) ad_agent _cl i ent : Recei ved 30169 ent r i es f r omagent r unni ng on 10. 65. 11. 41 ( added:
96, updat ed: 0, del et ed: 0)
( none) ad_agent _cl i ent : Pr ocessed 1 domai ns ( added: 96, updat ed: 0, del et ed: 0)
Message:
( none) ad_agent _cl i ent : The conf i gur ed domai n ( gr een- bl ox. com) does not mat ch t he DNS
domai n ( bl ue- bl ox. com) r epor t ed by agent r unni ng on 10. 65. 11. 41: 1819
Workaround:
Check that the AD domain configured on the NIOS appliance matches the DNS domain name configured in the grid
connector domain controller.
Message:
( none) ad_agent _cl i ent : Fai l ed t o communi cat e wi t h agent on ht t ps: / / 10. 65. 11. 41: 1820
Workaround:
Check that:
The IP address is routable.
The port number configured on the appliance matches the port number configured on the grid connector.
The certificate on the grid connector matches the certificate on the NIOS appliance. The grid connector
connectivity information should match the subject in the SSL certificate.
Message:
( none) ad_agent _cl i ent : Fai l ed t o aut hent i cat e t o agent on ht t ps: / / 10. 65. 11. 41: 1819
Workaround:
Check that the AD domain password matches the grid connector password.
Configuring LDAP Authentication
Configuring LDAP Authentication
You can configure the NIOS appliance to use an LDAP (Lightweight Directory Access Protocol) service to authenticate
users. LDAP and LDAPS (secure LDAP) are application protocols used for querying and modifying directory services
running over TCP/IP. LDAP uses the Domain Name System names to structure the top levels of the hierarchy, with
lower levels representing people, departments, devices, document, etc. on a public internet or a corporate intranet.
The properties you specify on the NIOS appliance must match the parameters on the LDAP/LDAPS server. The
appliance supports authentication using Novell eDirectory as an LDAP directory service as well.
To configure an LDAP authentication service:
1. From the AAA perspective, click the External Devices tab -> LDAP Authentication Services -> Edit -> Add LDAP
Authentication Service.
2. In the LDAP Authentication Service Properties editor, enter the following:
Name: Type a name for the LDAP authentication service.
Port: Enter the port number on the LDAP server to which the appliance sends authentication requests.
Transport Encryption: Select SSL to transmit through an SSL tunnel. Infoblox strongly recommends that you
select this option to ensure the security of all communications between the NIOS appliance and the LDAP
server. If you select this option, you must upload a CA certificate from the LDAP server. For information
about uploading a CA certificate, see Uploading Certificates to the Appliance on page 627.
Comment: Enter pertinent information about the server.
Disable this LDAP authentication service: Select this check box to retain an inactive LDAP service profile.
Use eDirectory as LDAP service: Select this check box to use Novell eDirectory to authenticate users. If you
select this option, you must select SSL as the transport method.
Search/Bind Properties
Search/Bind Type
Anonymous search then bind: Select this check box to enable the appliance to connect to the LDAP server
as an anonymous user.
OR
Authenticated search then bind: Select this check box if the appliance is required to authenticate itself
before it can connect to the LDAP server. If you select this option, you must enter a valid user DN
(distinguished name) and password.
Authentication User DN: Enter the user DN (distinguished name) that the appliance uses to authenticate
itself to the LDAP server when searching for user DNs. The DN must be a valid DN that is authorized to
search for user DNs.
Authentication Password: Enter the password associated with the user DN authorized to search the LDAP
directory.
Retype Authentication Password: Re-enter the password.
Search Base DN: The distinguished name of the search base object. It identifies the location in the
directory from which to begin searching.
Search Username Attribute: Specify the attribute that the appliance retrieves to authenticate users.
Group Attribute: Specify the LDAP attribute that identifies the group to which a user belongs.
LDAP Authentication Server Failover List
Click Add to enter the host name or IP address of the LDAP server to which the appliance connects. If you
enter a host name, you can click Resolve to check whether the DNS server can successfully resolve the host
name, enabling connectivity to the LDAP server.
Select a host, then click Modify to modify the information for an existing LDAP authentication server.
You can add multiple servers for failover purposes. The NIOS appliance tries to connect with the first server on
the list. If it is unable to connect, it tries the next server on the list, and so on. You can change the order in which
the servers are listed by selecting a server and clicking Move up or Move down. The order in which the policy
groups are arranged determines the order by which they will be evaluated.
RADIUS Services
If you use an EAP authentication method that requires a server certificate, you must install a digital certificate on the
appliance. A certificate is an electronic form that verifies the identity and public key its subject. Certificates are
typically issued and digitally signed by a trusted third party, the Certificate Authority (CA). A certificate contains the
following information: the dates it is valid, the issuing CA, the server name, and the public key of the server.
You can do any of the following:
Generate a self-signed certificate. The NIOS appliance generates a self-signed server certificate that also serves
as the Root CA Certificate. Therefore after you generate a self-signed certificate on the appliance, you must
import it into the host workstations certificate store as a trusted root certificate.
Generate a certificate signing request (CSR) and send it to you own trusted CA to obtain an EAP server certificate
or a Root CA certificate. After you receive the certificate, you can upload it to the appliance.
Generating a Self-Signed EAP Certificate
To generate a self-signed EAP (Extensible Authentication Protocol) certificate:
1. From the AAA perspective, click the Certificates tab-> EAP Server Certificates -> Tools -> Generate Self-Signed
Certificate.
2. In the Create Self-Signed EAP Certificate dialog box, enter the following:
Key Size: Select either 2048 or 1024 for the length of the public key. Note that for PEAP , the key size must
be 1024.
*Days Valid: Specify the validity period of the certificate.
*Common Name: Specify the domain name of the NIOS appliance.
3. Click OK to close the Create Self-Signed Certificate dialog box.
After you generate the certificate, you can then download it so you can install it on the client devices.
Generating a Certificate Signing Request
You can generate a certificate signing request (CSR) that you can use to obtain a signed certificate from your own
trusted CA (Certificate Authority). Once you receive the signed certificate, you can upload it to the NIOS appliance, as
described in Uploading Certificates to the Appliance on page 627.
To generate a CSR:
1. From the AAA perspective, click -> the Certificates tab -> Tools -> Generate Certificate Signing Request.
2. In the Create Certificate Signing Request dialog box, enter the following:
Key Size: Select either 2048 or 1024 for the length of the public/private key pair. For PEAP, the key must be
1024.
name (FQDN).
Administrators E-mail Address: Enter the e-mail address of the NIOS appliance administrator.
3. Click OK to close the Create Certificate Signing Request dialog box.
4. In the Save As dialog box, navigate to where you want to download the CSR, enter the file name and click Save.
Uploading Certificates to the Appliance
You can upload a CA certificate or an EAP server certificate. When you import a certificate, the NIOS appliance finds
the matching CSR and takes the private key associated with the CSR and associates it with the newly imported
certificate. The appliance then automatically deletes the CSR.
To import a CA certificate:
1. From the AAA perspective, click Certificates -> Tools -> Upload Certificate -> Upload CA certificate or Upload EAP
Server Certificate.
2. Navigate to the certificate you want to upload and click Open.
Downloading Certificates from the Appliance
If you generated a self-signed certificate, you can download it so you can install it on the client devices. You can also
download any CA and EAP server certificates stored on the appliance.
To download a certificate:
1. From the AAA perspective, click Certificates -> Tools -> Download Certificate -> Download CA certificate or
Download EAP Server Certificate.
2. In the Save As dialog box, navigate to where you want to download the certificate, enter the file name and click
Save.
RADIUS Services
About RADIUS Policies
You can define RADIUS policies that enable the NIOS appliance to provide configuration information to RADIUS clients
based on attributes in access requests or on the group to which a user belongs.
RADIUS clients and servers use attributes to convey certain configuration settings and information. RADIUS clients
include attributes in Access-Request packets and RADIUS servers include attributes in Access-Accept packets. You
can create RADIUS policies that define which attributes must be in Access-Request packets for the appliance to
append the corresponding attributes in its Access-Accept packets.
IETF specifies the standard RADIUS attributes, and vendors create their own vendor-specific attributes (VSAs) to
support non-standard features. NIOS appliances support the same standard RADIUS attributes and VSAs that are
supported by FreeRADIUS.
In addition, a NIOS appliance can retrieve group membership information for replicated users and users it
authenticates against an LDAP server. You can define RADIUS policies that provide configuration information to users
based on their group membership, as explained in Defining Policies for User Groups on page 629.
After you define the RADIUS policies, you can organize them into policy groups and configure a grid member to apply
a policy group when it receives authentication requests.
Defining Policies for User Groups
A NIOS appliance can receive group membership information when it imports user accounts from an AD server and
when it authenticates users against an LDAP server.
The NIOS appliance includes a dictionary that contains an attribute (Group-Internal) for group membership. You can
configure a policy that includes this attribute and the configuration settings the appliance includes in its
Access-Accept packet when it receives the attribute. When the appliance receives authentication requests from a user
that belongs to the group specified in the attribute, it responds with an Access-Accept that provides configuration
settings for the group.
For example, you can assign hosts to VLANS on your network, based on their group membership. In Figure 21.5, hosts
connect to the network through the NAS device. The NAS device sends authentication requests to the NIOS
appliance, which imports user information from the AD server. The NIOS appliance has a RADIUS policy that states
that when it authenticates users from the EMEA group, it must include attributes that provide VLAN information in its
Access-Accept packet.
Figure 21.5 Applying a Policy Based on Group Membership
Note that user groups are available only for replicated users and users authenticated against an LDAP database. The
NIOS appliance receives group information when it imports users from an Active Directory server and when it
authenticates users against an LDAP database. User groups are not supported for users entered in the local database
through the Device or Grid Manager.
A RADIUS client connects to the NAS and enters a user name and
password. The NAS sends an Access-Request with the user name
and password to the RADIUS server.
The RADIUS server has a RADIUS policy that states that when it
receives access requests with the Group Internal=EMEA attribute, it
must include the following attributes in its Access-Accept packet:
Tunnel-Type=VLAN
Tunnel Media-Type =IEEE802
Tunnel-Private-Group =10
The RADIUS server imports user information from an AD server. The
RADIUS server finds the user name and password in its database of
replicated users. It also determines that the user belongs to the
EMEA user group.
NAS
RADIUS
Server
AD server from
which the
RADIUS server
imports user
information
1
2
3
The RADIUS server sends an Access-Accept packet with the
specified attributes. The RADIUS client is allowed to log in and is
assigned to VLAN 10.
4
RADIUS
Client
User Group =EMEA
VLAN =10
RADIUS Services
Using RADIUS Policies
To configure the NIOS appliance to apply RADIUS policies to authentication requests:
1. If you are creating policies with the group membership attribute, import users as explained in Importing Users
From a Microsoft Active Directory Server on page 620 or configure the appliance to authenticate users against
an LDAP server, as explained in Configuring LDAP Authentication on page 625. When you configure LDAP
authentication, you must specify the LDAP attribute that identifies the group to which a user belongs.
2. Configure the RADIUS policy rules, as explained in Configuring RADIUS Policies.
3. Configure at least one RADIUS policy group, as explained in Configuring RADIUS Policy Groups on page 631.
4. Assign a RADIUS policy group to the NIOS appliance, as explained in Assigning a Policy Group to a Grid Member
on page 631.
Configuring RADIUS Policies
When you configure a RADIUS policy, you specify the attributes in an Access-Request packet and the corresponding
attributes the appliance appends to its Access-Accept packets.
To configure a RADIUS policy:
1. From the AAA perspective, select the Policies tab -> Policy Rules -> Edit -> Add Policy Rule.
2. In the Policy Rule Properties editor, complete the following:
Name: Enter a name for the policy.
Comment: You can enter information about the policy.
Match the Following Conditions: Click Add to add an attribute to the policy.
Attribute: Select to display the Select Check Attribute dialog box, which lists the RADIUS
dictionaries supported by the appliance. Expand a dictionary name to display its attributes, and then
select the attribute that the appliance must check in Access-Request packets when it applies this
policy.
To create a policy that specifies the attribute for group membership, expand the RADIUS dictionary and
select the Group-Internal attribute.
Operator: Select one of the following:
= The attribute value must be the same as the specified value.
!= The attribute value must be different from the specified value.
< The attribute value must be less than the specified value.
<= The attribute value must be less than or equal to the specified value.
> The attribute value must be greater than the specified value.
>= The attribute value must be greater than or equal to the specified value.
Value: If the attribute is a non-ENUM type of attribute, enter a value. If this is an ENUM-type variable,
click to display the Select Value dialog box, select a value, and then click OK to close the dialog box.
Select either Match all of the above or Match any of the above to specify the match criteria.
Reply with the following attributes: Click Add to include an attribute in the Access-Accept the RADIUS server
sends after it successfully authenticates the host.
Action: After you click Add, the appliance automatically enters append in this field to indicate it is
appending the attribute to the Access-Accept packet.
Attribute: Select to display the Select Reply Attribute dialog box, which lists the RADIUS
dictionaries supported by the appliance. Expand a dictionary name to display its attributes, and then
select the attribute that the appliance must include in its Access-Accept packets.
Value: If the attribute is a non-ENUM type of attribute, enter a value. If this is an ENUM-type variable,
click to display the Select Value dialog box, select a value, and then click OK to close the dialog box.
Managing Policies
You can view and edit policies, remove them, and add them to policy groups as described in Configuring RADIUS
Policy Groups.
To view policies, from the AAA perspective, select the Policies tab -> + (for Policy Rules).
The appliance lists the configured policies.
To change a policy, select it, right-click, and then select Edit Properties.
To remove a policy, select it, right-click, and then select Remove.
Configuring RADIUS Policy Groups
After you create the policies, organize them into policy groups so that you can assign a policy group to an appliance.
The appliance applies the policies in the order they are listed in the policy group.
To configure a RADIUS policy group:
1. From the AAA perspective, select the Policies tab -> Policy Groups -> Edit -> Add Policy Group.
2. In the Policy Group Properties editor, do the following:
Name: Enter a name for the policy group.
Comment: You can enter information about the policy group.
Policy Rule List: Click Add to add policy rules to the group. The RADIUS server applies the policies in the
order they are listed in the policy group. Use the Move Up and Move Down buttons to order the list.
Managing Policy Groups
You can view and edit policy groups and delete them from the database.
To view policy group, from the AAA perspective, select the Policies tab -> + (for Policy Groups).
The appliance lists the configured policy groups.
To change a policy group, select it, right-click, and then select Edit Properties.
To remove a policy group, select it, right-click, and then select Remove.
Assigning a Policy Group to a Grid Member
To assign a policy group to a grid member:
1. From the AAA perspective, click the AAA Members tab -> + (for grid) -> member -> Edit -> Member AAA Properties
-> RADIUS Authentication.
2. In the RADIUS Authentication section of the AAA Member Properties editor, enter the following:
Policy Group: Click Select Policy Group and select the policy group the member applies to authentication
requests it receives.
RADIUS Services
Network Access Servers
A NAS (network access server) is a server that provides network access to clients. A NAS can also authenticate and
authorize clients attempting to connect to a network, and thenassuming they are authorizedgrant them access.
If user accounts are not stored on a NAS but on another device such as a RADIUS server, then each NAS must forward
authentication requests to the RADIUS server.
You can configure a NAS to communicate with multiple RADIUS servers for redundancy. For example, the NAS can
communicate with RADIUS server in a remote site first. If it fails, then it can connect to a RADIUS server in a central
office.
To define a NAS and enable NIOS appliances to communicate with it:
1. From the AAA perspective, click the AAA Members tab -> + (for grid) -> member (NIOS appliance for which you want
to configure a NAS) -> Edit -> Add Network Access Server.
2. In the Network Access Server Properties editor, enter the following:
Disable this NAS: Select this check box if you are defining properties of a NAS you plan to enable at a later
date.
Name: Type a name for the NAS that is meaningful for you. This does not have to be the FQDN (fully
qualified domain name) of the server.
IP Address: Type the IP address of the NAS from which NIOS appliances can receive Access-Requests and
Accounting-Requests.
Comment: You can type a useful note for yourself, such as the location or owner of the NAS or the contact
information of the NAS administrator.
Shared Secret: Type the shared secret that is also entered on the NAS at the above IP address.
Retype Shared Secret: Retype the shared secret.
Member Association List: Click Add. In the Edit Member Association dialog box, select the grid member that
communicates with the NAS and click OK:
Disable: Select this check box if you want to associate the appliance with the NAS now, and enable
communication at a later date. Clear the check box to enable communication.
Member: Select the grid member that can communicate with the NAS.
Override Shared Secret: Select this check box if the grid member uses a different shared secret when it
connects to the NAS.
Shared Secret: Enter the shared secret in this field and in the Retype Shared Secret field.
Enabling RADIUS Services
Enabling RADIUS Services
You must configure RADIUS services on each NIOS appliance that functions as a RADIUS server. In a grid, you can
selectively enable RADIUS authentication and accounting on each grid member.
RADIUS Authentication
To enable a NIOS appliance to provide RADIUS authentication:
Listen on RADIUS Authentication Port: Select this check box to enable RADIUS authentication for the
member you selected in the AAA Members list.
Authentication Port: Specify the port number on which you want the appliance to receive Access-Requests
from a NAS. This port number applies to Access-Requests from all access servers. The default port number
is 1812, which you can change to any number from 1024 to 63,997.
Authentication Mode: Select Handle Requests Locally to use the RADIUS authentication service on the NIOS
appliance to authenticate users.
Authentication: The appliance uses the authentication methods in this list in descending order from the
top. The services, except for local, must have been previously configured.
Click Add to add local authentication, the Replicated User Authentication service, or an LDAP
authentication service. You can add multiple LDAP authentication services but only one Replicated
User Authentication service.
In the Select Authentication Method dialog box, select the service you want to add. When the
appliance successfully authenticates a user, it automatically allows access to the network. You must
specify which action the appliance should take when authentication fails through the selected method.
Select Reject to reject access to the user or select Next to try the next method on the list. Click OK to
close the dialog box.
If a users credentials are in multiple databases or servers, the appliance authenticates the user with the
first authentication method in which it finds the user.
To move an entry within the list, select it, and then click the Move up or Move down buttons. Moving an
entry higher in the list increases its priority, and moving it lower in the list decreases it.
To change a service or to change the action the appliance takes when authentication fails through the
selected method, click Modify.
You can change the action of the appliance when authentication fails.
You can replace the selected authentication method. Select the new service and click OK.
Optionally, change the action of the appliance when the newly selected authentication method
fails, and then click OK. The new authentication service appears in the Authentication list box.
To remove a particular entry from the list, select the entry, and then click Delete.
Debugging Level: From the drop-down list select one of the following:
Minimal: Indicates whether authentication was successful.
Low: Provides minimal information, and module and policy debugging output.
Medium: Provides more detailed calling, matching, and return module information.
High: Provides information generated at other levels, and module calling and return traces as well
Policy Group: Click Select Policy Group and select the policy group the member applies to authentication
requests it receives. For information on policy groups, see Configuring RADIUS Policy Groups on page 631.
RADIUS Services
Authentication Codepage: Select the international character set (codepage) from the drop-down menu to
match the Windows clients set up. For more information, see International Characters Support for RADIUS
Authentication on page 59. The NIOS appliance uses the codepage to translate single-byte characters into
UTF-8 encoded characters. The appliance supports the following codepages:
UTF-8
Arabic (1256)
Baltic (1257)
Central/Eastern European (1250)
Cyrillic (1251)
Greek (1253)
Hebrew (1255)
Latin-1 (1252)
Turkish (1254)
Note: The default is Latin-1 (1252). This codepage is usually correct for most English based Windows
environments.
RADIUS Accounting
Note: This feature is not supported on Riverbed virtual grid members.
To enable a NIOS appliance to process RADIUS Accounting-Requests:
-> + (for RADIUS Accounting).
2. In the Accounting section of the AAA Member Properties editor, enter the following:
Listen on RADIUS Accounting Port: Select this check box to enable RADIUS accounting for the appliance (or
member) whose IP address you selected in the AAA Members list.
Accounting Port: Specify the port number on which you want the appliance to receive Accounting-Requests
from a NAS. This port number applies to Accounting-Requests from all access servers. The default port
number is 1813, which you can change to any number from 1024 to 63,998.
Acct Failover List: Click Add and select a server from the Home Server list, then click OK to close the dialog
box.
To download the accounting log:
1. From the AAA perspective, click Tools -> Export RADIUS Detail file.
2. In the Export Detail File dialog box, specify the start and end times of the log you want to download:
Start Time: You can select Earliest event, which begins the exported file with the earliest event, or you can
select Specify and then enter the year, month, day, hour, and minute to specify the point at which you want
the exported file to begin.
End Time: You can select Latest event, which concludes the exported file with the last event, or you can
select Specify and then enter the year, month, day, hour, and minute to specify the point at which you want
the exported file to conclude.
3. Click OK.
A dialog box for navigating to the directory where you want to save the exported file appears.
4. Navigate to the directory where you want to save the exported file, and then click Save.
Understanding RADIUS Proxy Services
You can configure a NIOS appliance to proxy Access-Requests and Accounting-Requests between network access
servers (such as wireless access points, VPN concentrators, and DSL access multiplexers) and RADIUS authentication
and accounting home servers. When there is a large number of network access servers, proxying RADIUS requests
through NIOS appliances reduces the number of sources from which a RADIUS home server needs to allow requests;
that is, it only has to allow requests from a small number of appliances rather than from a considerably larger number
of network access servers. This eases the configuration of the RADIUS home server, as well as any intervening
firewalls.
Figure 21.6 Proxying RADIUS Authentication Requests
The packet flow for an Access-Request from a NAS (network access server) through a NIOS appliance to a RADIUS
authentication home server is shown in Figure 21.7.
Note: The NIOS appliance proxies EAP (Extensible Authentication Protocol) traffic encapsulated in RADIUS packets.
This illustrationand Figure 21.8 on page 636shows only select Layer 3 and 4 header characteristics.
Figure 21.7 Proxied RADIUS Authentication Packet Flow
Note: Although only one RADIUS
authentication and accounting server is
shown, NIOS appliances can proxy
requests to multiple RADIUS servers.
RADIUS Authentication and
Accounting Home Server
NIOS appliances as
RADIUS Proxy Servers
Network Access Servers
Src
Port
Dst
Port
Src
IP
Data
1.1.1.1 1.1.1.2 9000 1812 17
Dst
IP
Proto
Src
Port
Dst
Port
Src
IP
Data
1.1.1.2 1.1.1.1 1812 9000 17
Dst
IP
Proto
Src
Port
Dst
Port
Src
IP
Data
1.1.1.2 2.2.2.2 1814 1812 17
Dst
IP
Proto
Src
Port
Dst
Port
Src
IP
Data
2.2.2.2 1.1.1.2 1812 1814 17
Dst
IP
Proto
NIOS appliance as
RADIUS Proxy Server
IP Address 1.1.1.2
NAS
(Network Access Server)
IP Address 1.1.1.1
RADIUS Authentication
Home Server
IP Address 2.2.2.2
* The access response can be an Access-Accept,
Access-Reject, or Access-Challenge packet.
Access-Request Proxied Access-Request
Proxied Access Response Access Response*
RADIUS Services
Figure 21.7 on page 635 shows the default destination port number for RADIUS authentication: 1812. Note that when
the destination port number is 1812, the NIOS appliance generally changes the original source port numberwhich
can be any port number from 1024 to 65,535to 1814 in its proxied requests. If you change the destination port
number for RADIUS Access-Requestson the NAS and on the NIOS appliancethe appliance automatically changes
the source port number for the proxied requests to be two numerals greater than the new port number. Thus, if you
change the destination port number for RADIUS authentication to 30000, the appliance changes the source port
number for the proxied requests to 30002. (An exception to the two-digit port number shift occurs if the number of
pending requests exceeds 256the RADIUS packet identifier range is 0255. The RADIUS proxy uses the identifier
to associate a reply with a request. When requests exceed the 256 threshold, the NIOS appliance increases the
source port number on proxied requests incrementally.)
Note: Make sure that the settings for the destination port number for RADIUS requests on the NAS and the NIOS
appliance match. Otherwise, if they arrive at a port number that is not configured to receive them, the
appliance drops them. You can set the destination port numbers for authentication and accounting requests
at AAA -> AAA Members -> grid -> member -> Edit -> Properties.
For an Accounting-Request packet to a RADIUS accounting home server, the default destination port number is 1813.
This number is configurable. Like the source port number for proxied Access-Requests, the appliance also changes
the source port number for proxied Accounting-Requests to be two greater than the original Authentication-Request
destination port number, as shown in Figure 21.8.
Figure 21.8 Proxied RADIUS Accounting Packet Flow
To set up a NIOS appliance to function as a RADIUS proxy server, you must configure it to communicate with the
following two types of devices:
Each NAS from which you want the NIOS appliance to receive authentication and accounting requests. For
information configuring the NAS, see Network Access Servers on page 632.
Each RADIUS authentication and accounting home server to which you want the NIOS appliance to forward the
authentication and accounting requests it receives.
Note: When a NIOS appliance is a member of a grid, limited-access administrators can see NAS and home server
entries only for those members to which they have been given access.
Src
Port
Dst
Port
Src
IP
Data
1.1.1.1 1.1.1.2 9000 1813 17
Dst
IP
Proto
Src
Port
Dst
Port
Src
IP
Data
1.1.1.2 1.1.1.1 1813 9000 17
Dst
IP
Proto
Src
Port
Dst
Port
Src
IP
Data
1.1.1.2 2.2.2.2 1814* 1813 17
Dst
IP
Proto
Src
Port
Dst
Port
Src
IP
Data
2.2.2.2 1.1.1.2 1813 1814 17
Dst
IP
Proto
NIOS appliance as
RADIUS Proxy Server
IP Address 1.1.1.2
NAS
(Network Access Server)
IP Address 1.1.1.1
RADIUS Accounting
Home Server
IP Address 2.2.2.2
* The source port number for the proxied accounting-request is 1814 because
the destination port number for RADIUS authentication is 1812 (the default).
The source port number for proxied RADIUS requests is generally two
numerals higher than the destination port number for RADIUS authentication.
Accounting-Request Proxied Accounting-Request
Proxied Accounting Response Accounting Response
Then, after configuring NAS and home server objects on the NIOS appliance, you must enable the appliance to proxy
services (see Proxying RADIUS Accounting-Requests on page 640).
RADIUS Home Servers
A RADIUS home server is the server to which the NIOS appliance forwards proxied RADIUS Access-Requests and
Accounting-Requests from network access servers. You can designate the same RADIUS server for both
authentication and accounting purposes, or you can specify a different server for each function.
A NIOS appliance supports multiple RADIUS home servers for redundancy. When you configure multiple home
servers, the NIOS appliance stores them in a list, which you can see in the GUI by selecting the AAA perspective,
clicking the External Devices tab -> RADIUS Authentication Home Servers or RADIUS Accounting Home Servers. The
NIOS appliance first sends all RADIUS requests to the server at the top of the list. If the appliance does not receive a
response from that serveran Access-Accept, Access-Reject, or Accounting-Response packetit then sends requests
to the next server in the list. If that server also does not respond, the appliance tries the next server in the list, and
so on.
Figure 21.9 Multiple Home Servers for Redundancy
In more detail, a failover from one RADIUS home server to another occurs as follows:
1. A NAS (network access server) sends an Access-Request to the NIOS appliance.
2. The appliance proxies the request to the first RADIUS home server in its list, whichfor whatever reasondoes
not respond. (In Figure 21.9, this is the name server Primary at 1.1.1.5.)
3. After five seconds, the appliance resends the proxied request to the same server.
4. If the appliance receives no response after another five seconds, it sends the request to the server a third time.
5. At this pointif it again gets no response after five secondsthe appliance stops trying to proxy the request.
6. The NAS retransmits the Access-Request, and the NIOS appliance proxies that (up to three times if necessary) to
the next home server in its list. (In Figure 21.9, this is the name server Backup1 at 1.1.1.6.)
7. If that server does not respond, the appliance tries the next server in the list, rotating through the list of home
servers (proxying up to three times per request per unresponsive server) until it finds a server that responds.
8. After finding a responsive home server, the appliance continues to proxy further requests to it.
9. Every two minutesfrom the point when its third attempt fails to elicit a response from the first server in the list
the appliance proxies a request to that server again in case it can now respond.
. . .
Backup1
1.1.1.6
Backup2
1.1.1.7
Primary
1.1.1.5
Network
Access
Servers
1.1.1.3
RADIUS
Authentication
Home Servers
1.1.1.2 1.1.1.1
Central Site
Branch Site HA Pair of NIOS
Appliances as a
RADIUS Proxy
Server
VIP 1.1.1.4
RADIUS Home Server Failover Support
The proxy server sends all request packets to the RADIUS
home server named Primary at 1.1.1.5. If Primary does
not respond, the proxy server sends requests to Backup1
at 1.1.1.6. If neither Primary nor Backup1 responds, it then
sends requests to Backup2 at 1.1.1.7.
RADIUS Services
Note: The two-minute rule applies to every unresponsive home server. For example, two minutes after its third
attempt fails to elicit a response from the second server in the list, the NIOS appliance again attempts to
proxy a request to that server. The appliance makes these attempts even if the current home server is
responding.
Configuring a RADIUS Authentication Home Server Object
To enable the NIOS appliance to communicate with a RADIUS authentication home server:
1. From the AAA perspective, click the External Devices tab -> RADIUS Authentication Home Servers -> Edit -> Add
RADIUS Authentication Home Server.
2. In the Authentication Home Server editor, enter the following:
Disable this server: Select check box to disable the ability of the NIOS appliance to communicate with this
Name: Type a name for the RADIUS authentication home server that is meaningful for you. This does not
have to be the FQDN of the server.
Hostname: Type the IP address of the RADIUS authentication home server to which you want the appliance
to proxy Access-Requests.
Comment: You can type a useful note for yourself such as the location or owner of the RADIUS
authentication home server or the contact information of the remote RADIUS administrator.
Port: Enter the destination port number to which you want the NIOS appliance to send proxied RADIUS
Access-Requests. The default port number is 1813. It can be 1 65,535.
Members: Click Add, enter the following information, and then click OK.
Shared Secret: Type the shared secret that you want the appliance that you chose in the Select Grid
Member dialog box to use when communicating with this RADIUS server. When you deploy an
independent NIOS appliance, you can only define one shared secret for the appliance to use. When
deploying multiple NIOS appliances in a grid, you can define a different (or the same) shared
secret for each grid member that you choose in the Select Grid Member dialog box.
Select member: Click this link to open the Select Grid Member dialog box, choose the member for
which you want to define a relationship with the RADIUS authentication home server, and then
click OK.
Configuring a RADIUS Accounting Home Server Object
In addition to proxying RADIUS authentication packets, the NIOS appliance can also proxy RADIUS accounting
packets. RADIUS accounting tracks usage statistics, such as the length of a network connection and the amount of
data transferred. Note that the appliance simply proxies RADIUS accounting packets; it does not generate and store
any accounting logs.
To enable the NIOS appliance to communicate with a RADIUS accounting home server:
1. From the AAA perspective, click the External Devices tab -> RADIUS Accounting Home Servers -> Edit -> Add RADIUS
Accounting Home Server.
2. In the Accounting Home Server editor, enter the following:
Disable this server: Select check box to disable the ability of the appliance to communicate with this
Name: Type a name for the RADIUS accounting home server that is meaningful for you. This does not have
to be the FQDN of the server.
Hostname: Type the IP address of the RADIUS accounting home server to which you want the appliance to
proxy Accounting-Requests.
Managing RADIUS Proxy Services
Comment: You can type a useful note for yourself such as the location or owner of the RADIUS accounting
home server or the contact information of the remote RADIUS administrator.
Port: Enter the destination port number to which you want the NIOS appliance to send proxied RADIUS
Accounting-Requests. The default port number is 1813. It can be 1 65,535.
Members: Click Add, enter the following information, and then click OK.
Shared Secret: Type the shared secret that you want the NIOS appliance that you chose in the
Select Grid Member dialog box to use when communicating with this RADIUS server. When you
deploy an independent appliance, you can only define one shared secret for the appliance to use.
When deploying multiple NIOS appliances in a grid, you can define a different (or the same) shared
secret for each grid member that you choose in the Select Grid Member dialog box.
Select member: Click this link to open the Select Grid Member dialog box, choose the member for
which you want to define a relationship with the RADIUS accounting home server, and then click
OK.
After configuring one or more network access servers and RADIUS home servers, you must enable RADIUS proxy
functionality on each NIOS appliance that you want to proxy authentication and accounting requests. If you are
configuring multiple appliances in a grid, you can selectively enable (and disable) the RADIUS proxying service on
different members. You can also add, remove, and prioritize home servers on a per-member basis. For example, you
might use different settings on different members to distribute proxied requests somewhat evenly between two home
servers. As shown in Figure 21.10, you can configure GridMember-1 to proxy requests first to HomeServer-1 and fail
over to HomeServer-2, and GridMember-2 to proxy requests first to HomeServer-2 and fail over to HomeServer-1.
Figure 21.10 Distributing Proxied Requests from Grid Members
GridMember-2
Proxied RADIUS Requests
HomeServer-2 HomeServer-1
GridMember-1
RADIUS Requests
Members in the
Same Grid
GridMember-1 first
proxies requests to
HomeServer-1.
If HomeServer-1 becomes
unresponsive, GridMember-1
proxies requests to HomeServer-2.
If HomeServer-2 becomes
unresponsive, GridMember-2
proxies requests to HomeServer-1.
GridMember-2 first
proxies requests to
HomeServer-2.
Home Server Failover List
HomeServer-1:1812
HomeServer-2:1812
Home Server Failover List
HomeServer-2:1812
HomeServer-1:1812
RADIUS Services
Proxying RADIUS Access-Requests
To enable a NIOS appliance to proxy RADIUS Access-Requests:
Listen on RADIUS Authentication Port: Select check box to enable proxy services for RADIUS authentication
for the member you selected in the AAA Members list.
Authentication Port: Specify the port number on which you want the appliance to receive Access-Requests
from a NAS. This port number applies to Access-Requests from all access servers. The appliance typically
changes the port number on proxied Access-Requests to a value two digits greater than this number. The
default port number is 1812, which you can change to any number from 1024 to 63,997. This range allows
the appliance to change the source port number on proxied RADIUS requests to a maximum of 63,999).
However, if you set this port number to 63,997 (making the source port number for proxied requests
63,999) and there are more than 256 simultaneously pending proxied requests, the appliance cannot
increase the source port number incrementally to accommodate the additional proxied requests and
replies to them with ICMP port-unreachable messages.
Note: When setting custom port numbers for services such as RADIUS authentication and accounting, TFTP, and
VPNs, Infoblox recommends using numbers between 1024 and 59,999. This range provides a sizeable
margin before reaching the maximum of 63,999 (port numbers 64,000 and above are reserved).
Authentication Mode: Select Proxy authentication requests to proxy Access-Requests to RADIUS
authentication home servers.
Authentication Failover List: The NIOS appliance proxies Access-Requests to the RADIUS home servers in
this list in descending priority from the top.
To add servers to the Auth Failover List, click Add, choose an entry in the Home Server list, and then
click OK.
entry higher in the list increases its priority, and moving it lower in the list decreases it. The appliance
proxies requests to the entry at the top of the list first.
Viewing the RADIUS Configuration File
To view the RADIUS Configuration File:
1. From the AAA perspective, click the AAA Members tab -> + (for grid) -> member -> then from the View menu select
Radius Configuration.
2. In the RADIUS Config File tab, scroll down to view the contents of the RADIUS configuration file.
Proxying RADIUS Accounting-Requests
To enable a NIOS appliance to proxy RADIUS Accounting-Requests:
-> RADIUS Accounting.
2. In the RADIUS Accounting section of the AAA Member Properties editor, enter the following:
Listen on RADIUS Accounting Port: Select check box to enable proxy services for RADIUS accounting for the
appliance (or member) whose IP address you selected in the AAA Members list.
Accounting Port: Specify the port number on which you want the NIOS appliance to receive
Accounting-Requests from a NAS. This port number applies to Accounting-Requests from all access servers.
The default port number is 1813, which you can change to any number from 1024 to 63,998.
Proxy Accounting Requests: Select this check box to proxy Accounting-Requests to RADIUS accounting
home servers.
Authentication Mode: Click Add to select an authentication mode, then click OK to close this dialog box.
Accounting Failover List: The appliance proxies Accounting-Requests to the RADIUS home servers in this list
in descending priority from the top.
To add servers to the Accounting Failover List, click Add, choose an entry in the Home Server list, and
then click OK.
entry higher in the list increases its priority, and moving it lower in the list decreases it. The NIOS
appliance proxies requests to the entry at the top of the list first.
Removing Home Servers and Shared Secret Relationships
When RADIUS proxying is enabled and you want to remove a RADIUS home server definition that is referenced by the
only entry in the Authentication/Accounting Home Server Failover list, remove the entry from the failover list and
disable RADIUS proxy services before removing the home server definition. Similarly, remove the failover list entry
and disable RADIUS proxy services before deleting a shared secret relationship for the only referenced home server
in the failover list.
Removing RADIUS Home Servers
To remove a RADIUS authentication or accounting home server, make the following removals in this order:
1. Remove the entry referencing the home server from the Auth Failover List or Acct Failover List.
If there are multiple NIOS appliances in a grid, remove the home server from the failover list of each
member that references it.
If this is the last entry in the failover list, disable the proxying of RADIUS authentication or accounting
requests.
2. Remove the home server definition from the RADIUS authentication or accounting home servers list.
To make these removals:
-> RADIUS Authentication or RADIUS Accounting.
2. In the Authentication or Accounting section of the Member RADIUS Properties editor, select the ip_addr:port of
the server that you want to remove from the Auth Failover List or Acct Failover List, and then click Delete.
3. If this is the last entry in a failover list, clear the Listen on RADIUS Authentication/Accounting Port check box.
Note: When removing a home server for multiple members in a grid, repeat steps 13 for each member.
4. From the AAA perspective, click the External Devices tab -> + (for RADIUS Authentication Home Servers or RADIUS
Accounting Home Servers) -> server_name -> Edit -> Remove server_name.
RADIUS Services
Removing Shared Secret Relationships
A shared secret relationship consists of the following three elements:
RADIUS home server
NIOS appliance (this can be an independent appliance or one or more members in a grid)
Shared secret
To remove the shared secret relationship between a NIOS appliance and a RADIUS authentication or accounting home
server, make the following removals in this order:
1. Remove the entry referencing the home server whose relationship you want to remove from the Auth/Acct
Failover List.
If the shared secret relationship is for a server referenced by the last entry in the failover list, disable the
proxying of RADIUS authentication or accounting requests.
2. Remove the shared secret relationship between the NIOS appliance and the home server.
To make these removals:
1. From the AAA perspective, click AAA Members -> + (for grid ) -> member -> Edit -> AAA Member Properties -> RADIUS
Authentication or RADIUS Accounting.
2. In the RADIUS Authentication or RADIUS Accounting section of the AAA Member Properties editor, select the
ip_addr:port of the server that you want to remove from the Auth Failover List or Acct Failover List, and then click
Delete.
3. If this is the last entry in a failover list, clear the Listen on RADIUS Authentication/Accounting Port check box.
4. From the AAA perspective, click the External Devices tab -> + (for RADIUS Authentication Home Servers or RADIUS
Accounting Home Servers) -> server_name -> Edit -> RADIUS Authentication/RADIUS Accounting Home Server
Properties.
5. In the Authentication/Accounting Home Server editor, select the relationship in the Members list that you want
to remove, and then click Delete.

Chapter 22 IPAM WinConnect
Infoblox IPAM WinConnect provides a number of tools and features so you can centrally manage your IP address data.
For information about IPAM WinConnect, refer to the Infoblox User Guide for IPAM WinConnect. This chapter describes
how to configure a NIOS appliance to run the IPAM WinConnect service. It contains the following sections:
Configuring IPAM WinConnect on page 644
Uploading a WinConnect Bundle on page 644
Viewing Bundle Information on page 644
Managing the WinConnect Bundles on page 644
Configuring the WinConnect Service on page 645
Backing Up and Restoring Data on page 646
Monitoring WinConnect Services on page 646
IPAM WinConnect
Configuring IPAM WinConnect
You can configure an independent appliance to provide IPAM WinConnect services. To enable a NIOS appliance to
provide IPAM WinConnect services, you must do the following:
1. Download the IPAM WinConnect bundle from the Infoblox Technical Support at: http://support.infoblox.com.
2. Upload the WinConnect bundle to the NIOS appliance.
3. Enable the WinConnect service and enter a shared secret, as described in Configuring the WinConnect Service
on page 645.
Uploading a WinConnect Bundle
The WinConnect bundle contains all the files you need to run the service. Upload the WinConnect bundle to an
independent appliance as follows:
1. From the Device perspective, click + for hostname -> IPAM WinConnect -> Edit -> Upload IPAM WinConnect Bundle.
2. Navigate to the location of the bundle and click OK.
The appliance starts the upload process and displays a message confirming the upload after it is successful.
Viewing Bundle Information
After you upload a bundle you can view information about it, as follows:
From the Device perspective, click + for hostname -> IPAMWinConnect -> Edit -> Service Properties.
Expand the Information section to view the following information:
Bundle: Indicates that the bundle is installed.
Version: The version number of the bundle.
Allowed IP Nodes: The number of hosts the appliance is allowed to manage based on the license installed. This
displays only after you enable the WinConnect service.
Used IP Nodes: Displays the current number of active hosts in the database. This displays only after you enable
the WinConnect service.
Managing the WinConnect Bundles
You can upgrade IPAM WinConnect to a new bundle version or downgrade to an earlier version. When you upgrade or
downgrade WinConnect, you do not have to upgrade or downgrade the NIOS software as well.
When you upgrade WinConnect to a new bundle version, the appliance preserves the configuration files and data. To
upgrade a WinConnect bundle:
1. From the Device perspective, click + for hostname -> IPAMWinConnect -> Edit -> Upgrade IPAM WinConnect Bundle.
When you downgrade WinConnect to an earlier bundle version, the appliance deletes all data in the database.
Therefore, you must back up the database before you downgrade. To downgrade to an earlier version of the
WinConnect bundle:
1. Back up the database as described in Backing Up and Restoring a Configuration File on page 222.
2. From the Device perspective, click + for hostname -> IPAMWinConnect -> Edit -> Downgrade IPAM WinConnect
Bundle.
Configuring IPAM WinConnect
Configuring the WinConnect Service
After you upload the WinConnect bundle to a NIOS appliance, enable the service and configure operational
parameters as follows:
Configure the appliance to communicate with the WinConnect connectors installed on DNS and DHCP servers.
Enable logging. The WinConnect service generates syslog messages which you can view and download to your
management system. For additional information, see Using a Syslog Server on page 165.
Configure settings for the Multiping and Discover features.
To enable and configure the WinConnect service:
1. From the Device perspective, click + for hostname -> IPAMWinConnect -> Edit -> Service Properties.
2. In the Member IPAM WinConnect Properties editor, expand the Properties section, and enter the following:
Enable IPAM WinConnect services: Select this check box to enable the service.
Shared Secret: Enter the shared secret that the NIOS appliance and the WinConnect connectors use to
encrypt and decrypt their messages. Enter a minimum of eight characters.
IPAM WinConnect Connector
Connector Port: Enter the number of the port through which the appliance receives messages from
connectors. The default is 9633.
Use SSL to secure port: Select this option to transmit messages between a connector and an appliance
through an SSL tunnel. Infoblox strongly recommends that you select this option to ensure the security
of the communications between the appliance and the connectors. If you select this option, you must
install the same certificate on the NIOS appliance and the connector. For information about certificates,
see Managing Certificates on page 48.
IPAM WinConnect GUI
Web GUI Secure Port: Enter the number of the port through which users can connect to the WinConnect
GUI. The default is 4443.
Access URL: This field displays the URL that users must enter on their web browser to connect to the
GUI. The URL consists of the NIOS appliance host name and the Web GUI secure port number displayed
in the field above.
3. To enable logging and set the level of messages to be logged, expand the Support section, and then enter the
following:
Enable logging: Select this check box.
Log Level: Select one of the following:
Trivial: Generates start and stop messages. This is the default.
Normal: Generates messages for monitoring activity in the WinConnect service. These are mostly failure
messages.
Advanced: Generates messages for monitoring activity in the WinConnect service. Includes success
and failure messages.
Debug: Generates messages for debugging purposes.
4. Optionally, expand the Advanced section, and set the following parameters for the Multiping and Discover
features:
Ping
Burst Delay: Specify the delay, in milliseconds, between two ICMP bursts. The default is 4 milliseconds.
Timeout: Specify the time, in milliseconds, before a host is considered not responding. The default is
1000 milliseconds.
Retry: Specify the number of times the appliance retries an ICMP echo request. The default is 2.
Discovery Type: Identifies the discovery method the appliance uses for immediate discovery. Select one of
the following:
IPAM WinConnect
full: WinConnect performs a NetBios and nmap discovery. This is the most accurate discovery method.
Default.
nbt: WinConnect performs a NetBios discovery. It queries IP addresses for an existing NetBios service.
nmap: WinConnect performs a TCP discovery based on a selected list of services. It discovers nearly all
IP addresses on a subnet and can optionally guess the operating system running on the underlying
hosts.
Timeout: The maximum duration, in seconds, of a scan subprocess. The scan takes longer with larger
networks. The default is 3600 seconds.
Backing Up and Restoring Data
You can schedule regular backups to back up system files as well as the WinConnect configuration files, bundle, and
data. You can restore configuration files and data from the same appliance or another appliance. For information, see
Backing Up and Restoring a Configuration File on page 222. Note that when the appliance performs a restore
operation, any data currently on the appliance is lost. In addition, the appliance checks that the restored data is
compatible with the current version of the WinConnect bundle.
Monitoring WinConnect Services
You can view the status of the IPAM WinConnect service on the Detailed Status panel. This panel displays the state
of all available services in addition to the status of the various components of the appliance, such as database
capacity and Ethernet ports. For additional information about the Detailed Status panel, see Viewing Detailed Status
on page 160.
Following are the status icons for the IPAM WInConnect service:
Icon Color Meaning
Green The IPAM WinConnect service was enabled and is running properly.
Yellow The license usage information is unavailable or the license limit has been exceeded. Note that
this usually appears temporarily when the service first starts up, while the appliance checks
the license information.
Red The WinConnect service is not running properly.

Chapter 23 VitalQIP
Infoblox provides support for Lucents VitalQIP
IP address management software. You can easily deploy NIOS

appliances as VitalQIP DNS and DHCP remote servers by using the Infoblox grid technology to centrally manage code
and patch distribution, and to monitor the servers through one logging facility. For more information about grids, see
Chapter 9, Deploying a Grid, on page 267.
About VitalQIP on a Grid on page 648
HA Pair Grid Members on page 650
Deploying Grid Members as VitalQIP Remote Servers on page 651
Uploading and Enabling VitalQIP Files on page 651
Launching VitalQIP on the Grid on page 655
Configuring Grid Members on the VitalQIP Enterprise Server on page 656
Monitoring VitalQIP Services on page 660
SNMP on page 661
Troubleshooting Tools on page 661
This chapter does not describe the VitalQIP application and services. For information about VitalQIP, refer to the
Lucent VitalQIP documentation.
VitalQIP
About VitalQIP on a Grid
When you run VitalQIP remote server processes on a grid, you can manage code distribution and upgrades, and
monitor the server processes from one central pointthe grid master. You can manage the IP address data and QDNS
and QDHCP software configuration on the grid members from the VitalQIP enterprise server. You can also enable
SNMP (Simple Network Management Protocol) to monitor the operations and status of the grid, as well as those of
the VitalQIP remote services.
Note: You can run either NSQ (Network Services for Lucent VitalQIP)or the Infoblox DNSone software package on a
grid. You cannot run both software packages simultaneously on a grid.
To run VitalQIP on a grid, you must upload the following files to the grid master:
The VitalQIP policy file
The remote service core bundle
The DNS, DHCP and SNMP service bundles you want to run on the grid.
Optionally, you can upload the VitalQIP user exit files. User exit files are special Perl or shell script files executed
during a DNS or DHCP push. You can use user exit files to check for errors in the named.conf or database files.
You can also use them to modify the MAC filter in the DHCP configuration file.
You can obtain the VitalQIP files from Infoblox or Lucent Technical Support.
After you upload the VitalQIP files to the grid master, select the policy file and remote service core bundle you want
to run on the grid. Select and enable the DNS, DHCP and SNMP service bundles, and immediately restart services on
the grid. Each grid member then launches VitalQIP and can provide DNS and DHCP services after it receives DNS and
DHCP data and configuration files from the enterprise server.
You can upload multiple VitalQIP files to the grid master if you plan to run more than one VitalQIP version in the grid.
You can run one version on the grid and another version on an individual grid member if, for example, you want to
evaluate a version before deploying it throughout the grid. You can also enable different services on each grid
member. For example, you can enable DNS and SNMP services on one grid member, and DHCP and SNMP on another
grid member. Figure 23.1 illustrates the process for implementing VitalQIP in a grid.
Note: When running the VitalQIP DHCP server on the grid master, Infoblox recommends that you do not use DHCP
Failover and DHCP HA. There is a known limitation when running the VitalQIP DHCP server on the grid master
that prevents DHCP Failover and DHCP HA from working correctly. Running DHCP Failover and DHCP HA on
other members of the grid is supported.
About VitalQIP on a Grid
Figure 23.1 VitalQIP in a Grid
1 On the grid master, upload the
remote service core bundle and
policy file of the VitalQIP
version you want to run on the
grid, and a bundle for each
service you want to runDNS,
DHCP and/or SNMP.
The grid master replicates the
VitalQIP files to all grid
members. Select the binary
bundles and policy file, and
enable DNS, DHCP, and/or
SNMP. Restart grid services.
The grid members launch
VitalQIP and function as
remote servers. Push DNS
and DHCP configurations
from the enterprise server to
the grid members.
2 3
Grid Master
Grid Member
VitalQIP Remote Services
VitalQIP Remote Services
Grid Member
VitalQIP Binary Bundle
and Policy File
Enterprise Server
The grid master manages
code distribution.
The enterprise server
manages VitalQIP remote
services on the grid members.
VitalQIP
HA Pair Grid Members
VItalQIP can run on a grid member that is a single NIOS appliance and on two appliances configured as an HA (high
availability) pair. In an HA pair, one appliance functions as the active node and the other as the passive node. If the
active node fails, then the passive node becomes active and prevents service outages. The two nodes share a virtual
MAC address and a VIP (virtual IP address). For information on configuring an HA pair, see Adding an HA Member on
page 289.
The VitalQIP enterprise server considers each node in the HA pair as a separate remote server. The enterprise server
communicates with the VitalQIP daemon on each server. Therefore, you must add each node as a DNS and DHCP
server object on the enterprise server and specify the LAN address of the node as the server address. You must also
push DNS and DHCP configuration files to each server, using the LAN IP address of each node. After you push the files
from the enterprise server to each node in the HA pair, you can log in to the grid master and view the configuration
and logs of each node. For information about viewing the logs, see Monitoring VitalQIP Services on page 660.
For VitalQIP, you should also define a third virtual server for each HA pair. The virtual server enables the DNS servers
to manage and assign subnet profiles, domain profiles, and DHCP templates.
After you deploy an HA pair grid member as a DNS and DHCP server on your network, it serves DNS and DHCP to the
public network through its VIP. As a DHCP server, it adds its virtual MAC address and VIP in all DHCPOFFER messages.
Clients also send unicast DHCPDISCOVER and DHCPREQUEST messages to the VIP.
Figure 23.2 illustrates how an HA grid member communicates with the VitalQIP enterprise server and with its DNS
and DHCP clients in the public network.
Figure 23.2 Communications between an HA Member and a VitalQIP Server
Though the grid master can also function as a DNS and DHCP remote server, Infoblox recommends that you use the
grid master to manage the grid only. Use the grid master to upload and manage VitalQIP code distribution in the grid,
and to view the logs of each grid member. To ensure service availability, you can deploy an HA pair and configure it
as a master candidate. The master candidate can assume the role of grid master, in case the current grid master loses
connectivity. For additional information about master candidates, see Promoting a Master Candidate on page 309.
Grid Master
The enterprise server communicates with
the VitalQIP daemon in each node through
the LAN IP address.
The HA pair grid member serves DNS and DHCP
data to the public network through its VIP.
10.1.1.3
LAN IP Address
Node 1
10.1.1.1
VIP Address
10.1.1.5
LAN IP Address
Node 2
Public Network
1.1.1.0/24
VitalQIP Enterprise
Server
Deploying Grid Members as VitalQIP Remote Servers
For Infoblox grid members to function as VitalQIP remote servers, you must do the following:
On the grid master, upload the required vitalQIP files to the grid and enable VitalQIP as described in Uploading
and Enabling VitalQIP Files on page 651.
On the enterprise server, configure the grid members as DNS and DHCP remote servers and push configuration
and data files, as described in Configuring Grid Members on the VitalQIP Enterprise Server on page 656
On the grid master, restart the service on the grid, as described in Launching VitalQIP on the Grid on page 655.
The following sections describe these tasks.
Uploading and Enabling VitalQIP Files
After you configure the grid, log in to the grid master as a superuser and configure the grid to support VitalQIP as
follows:
1. Upload the binary bundle, VitalQIP policy files, and user exit files (optional).
Upload the remote service core bundle and policy file of the VitalQIP version you want to run on the grid.
Upload the binary bundles for the SNMP, DNS, and DHCP services.
Optionally upload the user exit files.
You can upload multiple bundles and policy files if you plan to run a different VitalQIP version or service on an
individual grid member. For a list of VitalQIP versions and their corresponding bundles, refer to the Infoblox
Technical Support site.
2. Select the VitalQIP policy file that you want to run on the grid. If you want to upload multiple policy files, then
ensure that each file has a unique name when you upload it. Otherwise, the new version overwrites the old.
3. Select the service binary bundles and enable the service(s) that you want to run on the grid.
You can run a different VitalQIP version or service on an individual grid member, as described in Enabling
VitalQIP on the Grid on page 653.
If you enable the VitalQIP SNMP service, you must configure and enable SNMP on the grid as described in
Configuring SNMP on page 217.
4. Restart the service on the grid to enable VitalQIP.
You must have superuser privileges to upload and remove a binary bundle or a VitalQIP policy file. Non-superusers
can view VitalQIP files and the VitalQIP properties and logs of any grid member to which they have access. For
information about granting privileges to users, see Chapter 3, Managing Administrators, on page 65.
Uploading Files to the Grid
Log in to the grid master as a superuser and upload the VitalQIP files described in this section. You must upload a
remote service bundle and a bundle for the DNS, DHCP and SNMP service you want to run.
To upload a binary bundle or policy file, click VitalQIP Files -> Edit -> Add Binary Bundle or Add Policy File. Navigate to
the file you want to upload and click OK. The appliance displays a message confirming the upload. You can upload
multiple bundles and policy files. You can also remove any binary bundle or policy file that you uploaded, provided
the file is not in use. To remove a binary bundle or policy file, select it and click Edit -> Remove binary_bundle or
policy_file.
After you upload a binary bundle or a policy file, you can refresh the GUI by collapsing and then expanding the list of
binary bundles or policy files. The grid master backs up and restores the VitalQIP files during normal grid backup and
restore functionality. See Backing Up and Restoring a Configuration File on page 222 for more information.
VitalQIP
Uploading User Exit Files
You can upload user exit files for the Lucent VitalQIP DNS and DHCP servers running on NIOS appliances. User exit
files are special Perl or shell script files executed during a DNS or DHCP file push operation. You can use user exit files
to check for errors in the named.conf or database files. You can also use them to modify the MAC filter in the DHCP
configuration file. You can also run scheduled user exits at various time intervals for periodic maintenance or to
update DHCP MAC filters.
There are four types of user exits:
VitalQIP Pre-DNS User Exits: Executable file that is invoked during the VitalQIP enterprise server DNS push
operation before the configuration files are generated. The push type in the VitalQIP enterprise server is either
Update or Configuration and data.
VitalQIP Post-DNS User Exits: Executable file that is invoked during the VitalQIP enterprise server DNS push
operation after the configuration files are generated. The push type in the VitalQIP enterprise server is either
Update or Configuration and data.
VitalQIP Post-DHCP User Exit: Executable file that is invoked during the VitalQIP enterprise server DHCP push
operation after the configuration files are generated, before DHCP is restarted.
VitalQIP Scheduled User Exit List: File executed periodically based on the interval that you specify. You can run
scheduled user exits to perform periodic tasks related to VitalQIP, DNS, and DHCP such as deleting log files.
See Uploading and Enabling VitalQIP Files on page 651 for information on how to upload these files.
Using Built-in Arguments and Environment Variables
You can use the following built-in arguments when you generate the VitalQIP user exit scripts:
You can use the following environment variables when you generate the VitalQIP user exit scripts:
Variable Description
$SERVER_NAME Hostname of the remote server
$SERVER_I P IP address of the remote server
$REMOTE_PUSH_DI R Directory on the remote server in which the files are placed. If there is no directory
available, the value of this variable is NONE.
$CURRENT_PUSH_DI R Directory on the remote server in which the files are placed. If there is no directory
available, the value of this variable is NONE.
$PUSH_TYPE Type of push. This value is always SERVER.
$TYPE UPDATE or CNF (configuration & data) for DNS. For DHCP, this value is always CNF.
Environment variable Value Description
$NI OS_ROOT_DI R /nios NIOS root directory
$NI OS_USEREXI T_DI R /nios/userexits Directory in which you can store the user exit script
files that you upload through the GUI.
$QI P_USER_HOME_DI R /home/qip Home directory in which you can save temporary
files.
$NI OS_TFTP_DI R /nios/tftp You can use this directory to store the files that you
download using TFTP or HTTP. For example, you can
use this directory to back up the configuration,
journal, and database files that you add or change.
Examples
The following example shows you how to use an environment variable and a built-in argument passed in during a
push with a Perl script:
#! / usr / bi n/ per l
#Get t he home di r ect or y f or user qi p f r omenvi r onment var i abl e.
$QI P_USER_HOME_DI R = ENV${ QI P_USER_HOME_DI R };
#Get t he ser ver s name t hat was passed i nt o scr i pt dur i ng push
$SERVER_NAME = ENV${ SERVER_NAME }
The following example shows you how to use an environment variable and a built-in argument passed in during a
push with a shell script:
#! / bi n/ sh
#Get t he home di r ect or y f or user qi p f r omenvi r onment var i abl e.
QI P_USER_HOME_DI R=${QI P_USER_HOME_DI R}
#Get t he ser ver s name t hat was passed i nt o scr i pt dur i ng push
SERVER_NAME=${SERVER_NAME}
Enabling VitalQIP on the Grid
After you upload the binary bundles and policy files to the grid master, select the remote service core bundle and
policy file you want to run on the grid. Also, select and enable DNS, DHCP, and SNMP.
To enable a VitalQIP version on a grid:
1. From the VitalQIP perspective, click VitalQIP Members -> grid -> Edit -> Grid VitalQIP Properties.
2. Select the following for the grid in the Grid VitalQIP Properties section:
VitalQIP Binary Bundle: Select the remote service core bundle of the VitalQIP version the grid supports. The
list displays the remote service core bundles you uploaded to the grid master.
VitalQIP Policy File: Select a policy file from the drop-down list. The list displays the policy files you
uploaded to the grid master.
VitalQIP Services: Click Add to open the QIP Service Bundle dialog box, and then enter the following:
Service Bundle Name: Select the bundle for the SNMP, DNS, or DHCP service that you want to run on
the grid. The list displays the service bundles you uploaded to the grid master.
Enable service: Select this check box to enable the service on the grid.
Click OK to close the QIP Service Bundle dialog box.
3. Select the following for the grid in the Grid VitalQIP User Exits Distribution Properties section:
Storage Limit (in Megabytes): Enter the storage limit for the user exit files.
Click the checkbox to include the user exits files and directories in the system backup.
4. Select the following for the grid in the Grid VitalQIP DNS User Exits section:
VitalQIP Pre-DNS User Exits: Enter an executable user exit filename or click Browse and select an
executable file that is invoked during the VitalQIP enterprise server DNS push before the configuration files
are generated. The push type in the VitalQIP enterprise server is either Update or Configuration and data.
VitalQIP Post-DNS User Exits: Enter an executable user exit filename or click Browse and select an
executable file that is invoked during the VitalQIP enterprise server DNS push after the configuration files
5. Select the following for the grid in the Grid VitalQIP DHCP User Exits section:
VitalQIP Post-DHCP User Exit: Enter an executable user exit filename or click Browse and select an
executable file that is invoked during the VitalQIP enterprise server DHCP push after the configuration files
are generated, before DHCP is restarted.
6. Select the following for the grid in the Grid VitalQIP Scheduled User Exits section:
VitalQIP Scheduled User Exit List: Click Add to open the VitalQIP Scheduled User Exit dialog box, and then
enter the following:
VitalQIP
Interval: Specify the duration for the command to run.
Interval type: Select minutes, hours, or days from the pulldown menu.
Command: Enter an executable user exit filename or click Browse and select an executable file.
The scheduled user exit commands appear in the VitalQIP Scheduled User Exit list box. You can select a
command and click Modify to change its interval, interval type, or the command itself, or click Remove to delete
it. You can run scheduled user exit scripts for periodic maintenance or to update DHCP MAC filters.
In the Restart Service dialog box, select Immediately.
Click OK to restart the service on the grid and enable VitalQIP.
The appliance displays the service and status in the VitalQIP Services list box. You can select a service bundle
and click Modify to change its status or click Remove to delete it.
You can also override the grid-level settings and run a different VitalQIP version or service on an individual grid
member, as long as you uploaded the necessary files to the grid master.
To enable a different VitalQIP version on a grid member:
1. From the VitalQIP perspective, click VitalQIP Members -> + (for grid) -> grid_member -> Edit -> Member VitalQIP
Properties.
2. Select the following:
Enable VitalQIP Services: VitalQIP is enabled by default. To disable VitalQIP support on the grid member,
clear this check box.
Override Grid File Selections: Select this check box to run a VitalQIP version that is different from the
version running on the grid.
VitalQIP Binary Bundle: Select the remote service bundle for the grid member from the drop-down list. The
drop-down list contains the binary bundles you uploaded to the grid.
VitalQIP Policy File: Select the policy file you want to run on the grid member. The drop-down list contains
the policy files you uploaded to the grid.
VitalQIP Services: Click Add to open the QIP Service Bundle dialog box, and then enter the following:
Service Bundle Name: Select the bundle for the SNMP, DNS or DHCP service that you want to run on the
grid member. The list displays the service bundles you uploaded to the grid master.
Enable service: Select this check box to enable the service on the grid member.
Click OK to close the QIP Service Bundle dialog box.
3. Select the following for the grid member in the Member VitalQIP DNS User Exits section:
Override Grid DNS User Exit: Select this check box to run a VitalQIP DNS user exit version that is different
from the version running on the grid.
VitalQIP Pre-DNS User Exit: Enter an executable user exit filename or click Browse and select an executable
file that is invoked during the VitalQIP enterprise server DNS push before the configuration files are
generated. The push type in the VitalQIP enterprise server is either Update or Configuration and data.
VitalQIP Post-DNS User Exit: Enter an executable user exit filename or click Browse and select an
executable file that is invoked during the VitalQIP enterprise server DNS push after the configuration files
4. Select the following for the grid member in the Member VitalQIP DHCP User Exits section:
Override Grid DHCP User Exit: Select this check box to run a VitalQIP DHCP user exit version that is different
VitalQIP Post-DHCP User Exit: Enter an executable user exit filename or click Browse and select an
executable file that is invoked during the VitalQIP enterprise server DHCP push after the configuration files
are generated, before DHCP is restarted.
5. Select the following for the grid member in the Member VitalQIP Scheduled User Exits section:
Override Grid Scheduled User Exit: Select this check box to run a scheduled user exit version that is
different from the version running on the grid.
VitalQIP Scheduled User Exit List: Click Add to open the VitalQIP Scheduled User Exit dialog box, and then
enter the following:
Interval: Specify the duration for the command to run.
Interval type: Select minutes, hours, or days from the pulldown menu.
Command: Enter an executable user exit filename or click Browse and select an executable file.
it.
In the Restart Service dialog box, select Restart Services (if needed).
Click OK to restart the service on the grid member and launch VitalQIP.
It takes up to 15 seconds to start running VitalQIP and implement any configuration changes you made. If the grid or
grid member is running VitalQIP for the first time, it unpacks the files and launches the VitalQIP remote services.
On the enterprise server, configure the grid members as remote servers and push DNS and DHCP configurations to
the grid members, as described in Configuring Grid Members on the VitalQIP Enterprise Server on page 656.
Launching VitalQIP on the Grid
After you push the DNS and DHCP configuration and data files from the enterpriser server to the grid members, you
must restart the service on the grid. When you restart the service, select Force Restart Services to enable the grid
members to start serving data as DNS and DHCP remote servers.
You need to do a force restart only once when you first push the DNS and DHCP configuration and data files. The
VitalQIP Remote Service reloads Lucent DNS and Lucent DHCP following a push.
If the NIOS appliance is currently running VitalQIP, it does one of the following:
If only the qip.pcy file changed, the member stops all VitalQIP services, updates the qip.pcy file and relaunches
services.
If the binary bundle changed, the member backs up the VitalQIP environment (log files, configuration files,
DHCP active leases, and so on) and stops all VitalQIP services. Then, the member deploys the new binary
bundle and qip.pcy files, restores the VitalQIP environment it previously backed up, and relaunches VitalQIP
services.
In this situation, you must again push the necessary DNS and DHCP configurations from the VitalQIP enterprise
server because you are changing the code instead of just updating the configuration and data files. After you
push the DNS and DHCP configurations, you must restart the service on the grid member by selecting Force
Restart Services.
If you select None for both the binary bundle and policy file, the grid member removes the VitalQIP
environment.
Managing VitalQIP Files on a Grid
When you change the binary bundle that a grid or a member is running and the new bundle contains a different major
version of BIND, you must first delete the VitalQIP environment, which includes all configuration and log files.
1. Delete the current VitalQIP environment:
a. From the VitalQIP perspective, click VitalQIP Members -> + (for grid) -> grid_member -> Edit -> Member
VitalQIP Properties.
b. Select None for both the VitalQIP Binary Bundle and VitalQIP Policy File.
c. Click the Save and Restart Service icons.
At the grid level, in the Restart Service dialog box, select Immediately.
At the member level, in the Restart Service dialog box, select Force Restart Services.
VitalQIP
d. Click OK to restart the service.
The appliance deletes the existing VitalQIP environment. (This process can take up to 45 seconds.) Check
the VitalQIP Process Statistics log to verify that the files were removed and VitalQIP processes are not
running.
2. Select the new binary bundle as described in Enabling VitalQIP on the Grid on page 653.
Configuring Grid Members on the VitalQIP Enterprise Server
For the enterprise server to manage the IP address data and QDNS and QDHCP software configuration on the grid
members, you must configure each grid member as a DNS and/or DHCP server on the enterprise server. If the grid
member is an HA pair, see Configuring an HA Pair as a DNS Server on page 657 and Configuring an HA Pair as a DHCP
Server on page 657 for information specific to HA pair configurations.
Perform the following tasks on the enterprise server to enable it to communicate with the Infoblox grid members:
1. Add each grid member as a static server object.
If the grid member is an HA pair, you must add the following as separate static server objects:
The LAN IP address of each node
The VIP of the HA pair
Infoblox recommends that you add static server objects for the HA IP addresses of the HA pair to prevent
administrators from assigning these addresses to other network devices. When you create these server
objects, enter descriptive names that clearly identify these objects as inactive objects used for tracking
purposes only.
2. Add a DNS and DHCP server for each grid member.
If the grid member is an HA pair, see Configuring an HA Pair as a DNS Server on page 657 and Configuring
an HA Pair as a DHCP Server on page 657 for guidelines.
Set parameters according to the server type, as described in Table 23.1.
Table 23.1 DHCP and DNS Server Parameters
Server Type Required Parameters
DHCP Server
Set the default directory to /opt/qip/dhcp/
If the DHCP server is for the VIP of the HA pair, specify a default directory that
identifies it as an inactive server, such as /tmp/inactive_DHCP
See Configuring an HA Pair as a DHCP Server on page 657 for information.
Lucent DNS 3.x Server
Set the default directory to /var/named/
3. Push the appropriate DNS and DHCP data and configuration file to each grid member.
Configuring an HA Pair as a DNS Server
You must configure each node in an HA pair as a DNS server. Following are some guidelines for configuring an HA pair
grid member as a DNS server on the VitalQIP enterprise server:
VitalQIP supports a multi-master DNS configuration. If the HA pair is the master server for a domain, then on the
enterprise server, you must configure each node as a master server for the domain. As master (or primary)
servers for the domain, each node provides DNS services, serving the same information. Each node also
receives DDNS updates from the VitalQIP DNS Update Service.
Infoblox strongly recommends that you do not use non-VitalQIP managed servers as external secondary
servers in a multi-master configuration where the primary servers are HA pair grid members.
Push the same DNS configuration and data files to each node.
When a node fails and comes back up, the databases of the two nodes might not be synchronized, especially if
the node was down for a long time. To ensure that the databases of the two nodes are synchronized, push the
DNS data files to the two nodes from the enterprise server.
To propagate external updates to both nodes of an HA pair, you must enable the Import External Updates option
for each zone on the enterprise server, and then enable each resource record type you want updated. These
options are disabled by default. The Import External Updates option require a virtual DNS server to be created
on the VIP address of an HA pair. This resolves issues with multi-home systems where updates come from an IP
address that the VitalQIP does not know. In such cases, VitalQIP rejects the updates and they are not reflected
in the database and are not propagated to the other master name server(s).
Configuring an HA Pair as a DHCP Server
VitalQIP supports a many-to-one primary and failover DHCP server configuration, where multiple primary servers are
supported by one failover server. The failover server does not provide DHCP services when all its primary servers are
operational. The failover server takes over only when a primary server fails.
When you configure an HA pair as DHCP servers on the enterprise server, configure the active node as the primary
server, and the passive node as the failover server. The failover server does not provide DHCP services when both
nodes are operational. If the active node fails, the passive node takes over and serves DHCP to the clients of the
active node. When the original active node comes back up, it forces a failover so it becomes the active node and
resumes providing DHCP services.
Lucent DNS 4.x Server Set the default directory to /var/named/
Set the default RNDC path to /usr/sbin/
If the enterpriser server is running version 6.1, you must do one of the
following to generate an rndc.conf file:
Push the DNS files from the VitalQIP enterprise server to the grid member
using the Update push type. (This enables the internal user exit of the grid
member to automatically generate the rndc.conf file based on the
named.conf file.)
Run the following VitalQIP CLI command to generate the rndc.conf file in
the /usr/sbin folder:
r ndc- conf gen d " RNDC shar ed secr et i n Vi t al QI P GUI " >
/ var / named/ r ndc. conf
Example: / r ndc- conf gen d " I nf obl ox" >/ var / named/ r ndc. conf
Copy the rndc.conf file from the legacy VitalQIP remote server to the
/var/named/ directory of the Infoblox remote server
If the enterpriser server is running version 6.2, set the Create rndc.conf option
to True.
Server Type Required Parameters
VitalQIP
Note: Infoblox recommends that you do not run DHCP failover on the grid master because it can cause the following
problems:
During an upgrade to NIOS 4.x, HA members might have both nodes upgrade at the same time causing a
service outage.
Because DHCP failover can force the grid master to perform automatic HA failovers, it can cause unexpected
interruptions in grid communications.
Following are some guidelines for configuring an HA pair grid member as a DHCP server on the VitalQIP enterprise
server:
Configure the failover server first, and then configure the primary server. You must configure the passive node in
the HA pair as the failover server, and the active node as the primary server. When you configure the servers,
enter the LAN IP address of each node. Do not enter the VIP address of the HA pair.
Configure the passive node as the failover server for the active node only. Do not configure the passive node as
a failover server for other primary servers.
Note: You cannot use the many-to-one failover server configuration when the failover server is a node in an HA
pair.
Push the configuration and data files to the primary server. The failover server automatically receives the files as
well.
Configure a DHCP server for the VIP of the HA pair. When an HA pair that is a DHCP server sends DDNS updates
to the enterprise server, the DHCP server uses its VIP as the source address. Therefore you must add the VIP as
a DHCP server on the enterprise server so it can successfully validate the source address of DDNS updates from
a DHCP server that is an HA pair.
This DHCP server is used for validation of DDNS updates only. Therefore, when you create this server, do not
configure an IP address range for it. In addition, you must specify a default directory that identifies this as
an inactive server, such as /tmp/inactive_DHCP. Also, configure the Remote Proxy setting to the IP address
1.2.3.4 because it prevents a push from being accidentally sent to the active HA member.
You cannot configure DHCP failover between an HA pair and another system.
Using LDRM
Before you use LDRM (Lucent DHCP Rules Manager) 2.0, ensure that you have installed VitalQIP 6.2 or later and DHCP
5.4 build 22 or later on your system.
To use LDRM 2.0 on Infoblox remote servers, download the related service bundle from the Infoblox Technical Support
website and then upload and use this service bundle on the Infoblox remote server. You can also download sample
scripts and recommended processes to change the configuration files for the LDRM service bundle.
Note: When you upgrade the NIOS software, it does not retain the configuration changes you make to LDRM. Only
the service bundle you upload remains the same after you upgrade.
You can modify the following configuration files for LDRM using a user exit script or an editor in the restricted shell
environment.
$QI PHOME/ l dr m/ conf / l dr m. pr oper t i es
$QI PHOME/ l dr m/ conf / l dr m- l og4j . pr oper t i es
$QI PHOME/ dhcp/ LDRMCal l out . pcy
Use the following steps to run the sample script ldrm-check-update.sh and change the configuration files:
1. Add a directory called ldrm under the user exit directory root.
2. Add a directory called script under the user exit directory root.
3. Add the file ldrm-check-update.sh under the script directory.
4. From the VitalQIP perspective, click VitalQIP Members -> + (for grid) -> grid_member -> Edit -> Member VitalQIP
Properties.
5. Select the following for the grid member in the Member VitalQIP Scheduled User Exits section:
Override Grid Scheduled User Exit: Select this check box to run a scheduled user exit version that is different
VitalQIP Scheduled User Exit List: Click Add to open the VitalQIP Scheduled User Exit dialog box, and then enter
the following:
Interval: 1. This is the duration for the command to run.
Interval type: Select minutes.
Command: script/ldrm-check-update.sh
it.
If you modified a configuration file such as ldrm.properties, under the ldrm directory add the file ldrm.properties.
Note: You must use the same filenames (ldrm.properties,ldrm-log4j.properties,LDRMCallout.pcy) when you add
files to the ldrm directory. The ldrm-check-update.sh script compares the original version with the changed
configuration file and restarts service accordingly.
To verify, you can check that the LDRM/LDHCP service is restarted through the GUI, or go to the restricted shell and
check that the file is updated.
VitalQIP
DHCP API
To use the VitalQIP DHCP Server API, you must compile your code into a shared library (libQdhcp_api.so) and then
upload it to the /home/qip/api directory through the restricted shell environment. The built-in user exit scripts copy
the DHCP API file from the /home/qip/api directory to the $QIPHOME/usr/lib directory during a DHCP push operation
from the enterprise server, and then restart DHCP service.
Note: When you upgrade the NIOS software, it does not retain the DHCP API changes in the $QIPHOME/usr/lib
(/opt/qip/usr/lib) directory; however, it preserves the /home/qip directory. After an upgrade the DHCP API
does not work until you perform a DHCP push operation from the enterprise server to each node. During a push
operation, the user exit scripts copy the contents of the /home/qip/api directory to the $QIPHOME/usr/lib
directory; therefore, the DHCP API file contains the changes made before the upgrade.
Monitoring VitalQIP Services
In addition to the Infoblox logs, the NIOS appliance provides support for different types of VitalQIP logs. For
information about Infoblox logs, refer to Chapter 5, Monitoring the Appliance, on page 159. To view logs for a grid,
log in to the grid master, from the VitalQIP perspective, click View and select the log you want to view. You can view
the following logs for each grid member:
For detailed information about the VitalQIP logs, refer to the documentation of the VitalQIP version you are running.
VitalQIP Log Description
VitalQIP Policy File Displays the qip.pcy file. View this file to verify that all the settings are as
defined in Deploying Grid Members as VitalQIP Remote Servers on page 651.
VitalQIP DNS Configuration Displays the DNS configuration file.
VitalQIP DHCP Configuration Displays the DHCP configuration file
VitalQIP DHCP Policy File Displays the dhcpd.pcy file.
VitalQIP Process Statistics Provides information about VitalQIP processes and the versions that are
running.
If this log indicates that named or dhcpd is not running, but qip-msgd and
qip-rmtd are running on a particular member, restart the service on that
member by clicking the Restart Service icon. In the Restart Member Services
dialog box, select Force restart services, and then click OK to restart the
service.
VitalQIP DHCP Log Provides information about DHCP processes.
VitalQIP Active Lease Service Log Provides information about the active leases.
VitalQIP Message Service Log Provides information about communications between services and various
components.
VitalQIP Remote Service Log Provides information about the remote service process, which builds name
and address configuration files.
Monitoring VitalQIP Services
SNMP
NIOS appliances can provide support for both NIOS and VitalQIP SNMP services. The NIOS SNMP agent monitors the
Infoblox grid services and status, and supports the Infoblox MIB (Management Information Base) files. The VitalQIP
SNMP agent monitors the DNS and DHCP remote server status and supports the VitalQIP MIB files. The appliance
responds to queries for data from the NIOS MIB files and the VitalQIP MIB files, as long as the query contains the
configured community string. The appliance also generates traps for both NIOS and VitalQIP events. For information
about NIOS SNMP, see Chapter 6, Monitoring with SNMP, on page 175. For information about VitalQIP SNMP
functions and MIBs, refer to the Lucent VitalQIP documentation.
Perform the following tasks to enable support for both the NIOS and VitalQIP SNMP services:
Enable SNMP on the grid, as described in ibIPWC MIB on page 212.
On the grid master, download the VitalQIP SNMP bundle and enable SNMP service, as described in Uploading
and Enabling VitalQIP Files on page 651.
Troubleshooting Tools
NIOS appliances provide CLI commands that you can use to view VitalQIP log files and monitor VitalQIP services. The
appliances enable you to access the VitalQIP configuration and data files using a restricted secure shell. You can look
at the log files and scripts for failure diagnostics, problem reproduction, debugging, and troubleshooting. For
information about these commands, refer to the Infoblox CLI Guide.
VitalQIP

Part 4 API Interface
This section provides information on the application programming interface (API) that works with the NIOS appliance.
It includes the following chapter:
Chapter 24, "Infoblox DMAPI", on page 665

Chapter 24 Infoblox DMAPI
Infoblox appliances support an application programming interface (API) that provides a convenient way to simplify
otherwise lengthy, recurring, and repetitive tasks, such as the following:
Customizing the operation of the Infoblox appliance
Performing periodic updates and scheduled backups
Importing IPAM data
Performing bulk data imports
Using scripts to perform a single operation such as adding a host
Connecting with existing DNS management tools
This document explains the software you need to use the Infoblox DMAPI (Data and Management API), where to get
it, and how to install it. It then provides some general guidelines and a few examples with step-by-step instructions
on how to use it. It contains the following sections:
Introduction to Infoblox DMAPI on page 666
Required Tools on page 667
Installing Perl and Infoblox DMAPI Packages on page 668
Infoblox Scripting Pack on page 668
Running a Script on page 671
Writing a Script on page 673
Perl Information Resources on page 683
Infoblox DMAPI
Introduction to Infoblox DMAPI
Perl is a scripting language that supports both procedural and object-oriented programming. You can use predefined
Perl scripts (see the Infoblox Scripting Pack, available at http://support.infoblox.com) or design your own custom
scripts to run operations through the Infoblox DMAPI (Data and Management API). A script is a program that you send
to the Infoblox appliance through the Infoblox DMAPI to perform one or more operations. The Infoblox DMAPI is a Perl
language binding to the Infoblox appliance and delivered as a set of packages using the Perl object-oriented style.
Figure 24.1 Using the Infoblox DMAPI
Infoblox
Device
API Server
Internal Programs
Infoblox
DMAPI Packages
Script API Path
Infoblox DMAPI
HTTPS Tunnel
(Port 443)
Function Calls
Management
Station
Required Tools
Required Tools
To set up your system to use the Infoblox DMAPI (Data and Management API), you need the following components:
Computer (also referred to as management system )
75 MB hard disk space for a typical installation
Ethernet connectivity to the Internet and to an Infoblox appliance
(Windows) ActivePerl v5.8.x or later with PPM (Perl Package Manager) 3.x or later
(UNIX) interpreter for Perl v5.8.x configured to use CPAN
Crypt::SSLeay package (and its dependencies: ssleay32.dll and libeay32.dll) for making HTTPS connections to
the Infoblox appliance
Infoblox DMAPI packages
Infoblox Scripting Pack (optional; use to run predefined scriptssee Infoblox Scripting Pack on page 668)
Figure 24.2 Downloading Perl, Crypt::SSLeay and Infoblox DMAPI Packages, and the Infoblox Scripting Pack
The following section, Installing Perl and Infoblox DMAPI Packages on page 668, explains how to download and
install Perl and the Infoblox DMAPI packages on your management system. For instructions on downloading the
Infoblox scripting pack, see Infoblox Scripting Pack on page 668.
Management
System
Infoblox
Device
Internet
Infoblox DMAPI
Packages
Perl Infoblox
Scripting Pack
Crypt::SSLeay
Infoblox DMAPI
Installing Perl and Infoblox DMAPI Packages
To use the Infoblox DMAPI, you must install and use Perl v5.8.x or later. You must also download a set of Infoblox
DMAPI packages from the Infoblox appliance to your management system. The installation instructions can be found
in two locations within the Infoblox GUI. Within these instructions, refer to the appropriate section for installations in
either a Windows or UNIX/Linux environment:
From any perspective, click Help -> API Documentation. The appliance displays the instructions.
Infoblox DMAPI Documentation
Infoblox DMAPI packages and objects are thoroughly documented. The documentation can be access either through
the Infoblox GUi or directly from a browser.
From the GUI menu, Click Help -> API Documentation
In your browser window, type in: https://<IP address of device>/api/doc/
Once the documentation is displayed, there is an index on the left hand side to direct you to a particular object.
Infoblox Scripting Pack
Infoblox provides a set of scripts in the Infoblox Scripting Pack. To obtain a pack, do the following:
1. Visit the Infoblox Technical Support site: support.infoblox.com
2. Enter your support subscription e-mail ID and password in the Support Center Login section, and then click
Login .
The Infoblox Support Center page appears.
3. In the NIOS (DNSone v4) Downloads section, click Scripting Packs.
The Downloads page appears.
4. In the Scripting Packs section, click the link that corresponds to the version of NIOS running on your Infoblox
appliance.
5. Save the pack to a local directory, and extract the compressed files.
(Windows) Use WinZip to extract the compressed .tar file.
(Linux) Enter the following command: tar xzf release-support-pack.tgz
The following tables list the file names and descriptions of many of the available scripts.
Note: Check the pack contents to see if more scripts have been added since the time of this writing.
Infoblox Scripting Pack
Table 24.1 Miscellaneous Scripts
Table 24.2 Configuration and Data Summary Scripts
Script Description
testconn.pl Tests Perl SSL connectivity to the Infoblox appliance.
backup.pl Backs up the database of an Infoblox appliance.
add_dns_comments.pl Imports comments for hosts to an Infoblox appliance from a flat file in TSV
(tab-separated values) format.
add_secondary.pl Adds a secondary server to all the zones on an Infoblox appliance.
check_version.pl Checks the version of code running on an Infoblox appliance.
csv_add_data.pl Adds data in CSV (comma separated value) file format.
download_perlmodule.pl Downloads the Perl library files from an Infoblox appliance.
extract_leases.pl Extracts DHCP leases from an Infoblox appliance to a file.
list_grid_zone.pl Lists all the zones in an ID grid.
make_members.pl Adds members to an ID grid from a flat file in CSV (comma-separated values) format.
make_secondary.pl Makes a configuration for a secondary DNS server based on the configuration for a
primary server.
v2db_xml_summary.pl Searches for and summarizes v2 XML databases from a backup file.
xml_search.pl Searches the NIOS XML database for a specific record.
xml_summary.pl Sorts and summarizes the NIOS XML database from a backup file.
win2kboot.pl Facilitates data importing from a computer running Microsoft Windows 2000.
winntboot.pl Facilitates data importing from a computer running Microsoft Windows.
Script Description
aix_dhcp_summary.pl Summarizes DHCP data on an IBM server running the AIX (Advanced Interactive
eXecutive) operating system.
dhcpd_conf_summary.pl Summarizes the configuration of an ISC DHCP server.
metaip_dhcp_summary.pl Summarizes the DHCP data on a MetaIP DHCP server.
ms_dhcp_summary.pl Summarizes the DHCP data on a Microsoft DHCP server.
named_conf_summary.pl Summarizes the named.conf file from a BIND v8 or 9 DNS server.
netid_dhcp_summary.pl Summarizes various DHCP file formats from a Nortel NetID server.
zone_rr_types.pl Summarizes one or more BIND database files
Infoblox DMAPI
Table 24.3 Configuration and Data Import Scripts
Note: For importing DNS and DHCP data, Infoblox recommends using the Data Import Wizard, which you can
download from the Infoblox Technical Support site: support.infoblox.com.
Script Description
bind4_import.pl Imports data from a BIND v4 DNS server.
bind89_import.pl Imports data from a BIND v8 or 9 DNS server.
aix_dhcp_import.pl Imports data from an IBM DHCP server running AIX.
dhcpd_conf_import.pl Imports the configuration from an ISC DHCP server.
dhcp_lease_import.pl Imports ISC DHCP leases.
metaip_dhcp_import.pl Imports the DHCP data from a MetaIP DHCP server.
ms_dhcp_import.pl Imports the DHCP data from a Microsoft DHCP server.
ms_dns_import.pl Imports the DNS data from a Microsoft server.
ms_leases_import.pl Imports DHCP leases from a Microsoft server.
netid_dhcp_import.pl Imports DHCP data from a Nortel NetID server.
qip_dhcp_import.pl Imports the various file formats from a Lucent QIP DHCP/DNS server.
Running a Script
Running a Script
This section explains how to run two of the scripts from the Infoblox Scripting Pack (see page 668).
Note: If you experience any difficulties when using a script, refer to the API and Perl Script Pack Troubleshooting
Guide (TROUBLESHOOTING.html), which is included in the script pack.
Testing the Connection
The testconn.pl script tests if Perl is correctly set up for TLS (Transport Layer Security) by sending a GET for the 127.0.0
reverse zone, an item that is sure to be present in the configuration. This is a useful script to run before attempting
others. Furthermore, it is an equally useful troubleshooting tool.
Figure 24.3 Running the testconn.pl Script
Note: The following procedure assumes that you have already loaded Perl, the Infoblox DMAPI, and the Infoblox
Scripting Pack as explained in Required Tools on page 667 and Infoblox Scripting Pack on page 668.
To run the testconn.pl script, do the following:
1. Make sure that you can reach the Infoblox appliance across the network. You can test your connectivity by trying
to log in through a web browser or by pinging it.
2. To run scripts in the C:\Perl\NIOS-release-perl-script-pack directory, open a command window and either change
the prompt to that directory or specify the path to the script file in the command.
3. Type the following command:
C: \ Per l \ NIOS-release-perl-script-pack>perl testconn.pl -s 10.1.1.1 -u admin -p infoblox
Note: All Infoblox Scripting Pack scripts require you to specify the IP address of the Infoblox appliance (- s
ip_addr ), your user name (- u name_string ), and your password (- p string ) in the command line.
If the connection test is successful, the following output appears.
Checki ng t he I nf obl ox Per l Modul e r out i nes.
Tr yi ng a connect i on.
Checki ng SSLeay i nst al l at i on.
Zone l ookup f or 0. 0. 127. i n- addr . ar pa : passed.
I f no er r or s wer e seen, t he t est has ended successf ul l y.
Management
System
10.1.1.10
Infoblox
Device
10.1.1.1
The testconn.pl script
performs the following
tasks:
TLS
(Transport Layer Security)
Tunnel
Reverse Zone GET
GET Passed
Login
1 Checks Infoblox Perl packages and
the SSL library installation on the
management system.
2 Builds a TLS tunnel.
3 Logs in and performs a
reverse zone GET.
reverse zone =
0.0.127.IN-ADDR.ARPA
Infoblox DMAPI
Backing Up the Database
The backup.pl script downloads the NIOS database to a local directory. This is a prudent precaution to take when
upgrading and even just a matter of good practice at periodic intervals.
Figure 24.4 Running the backup.pl Script
1. Make sure that you can reach the Infoblox appliance across the network. You can test your connectivity by trying
to log in through a web browser or by pinging it.
2. To run scripts in the C:\Perl\NIOS-release-perl-script-pack directory, open a command window and either change
the prompt to that directory or specify the path to the script file in the command itself.
3. Type the following command, where the "-o" operator indicates where to save the output (that is, the backup
database file) and what to name part of the saved file. In this example, you save the file to the C:\Perl\backup
directory and prepend the name "10.1.1.1" to the automatically generated file name:
perl backup.pl -s 10.1.1.1 -u admin -p infoblox -o C:\Perl\backup\10.1.1.1
Note: When typing a Windows directory path that incudes directory names with spaces, you need to enclose the
entire path inside quotation marks .
Your computer saves the backed up database in the local directory specified.
C: \ Per l \ NI OS- release- per l - scr i pt - pack> per l backup. pl - s 10. 1. 1. 1
- u admi n - p i nf obl ox - o C: \ Per l \ backup\ 10. 1. 1. 1
Savi ng dat a as [ C: / Per l / backup/ 10. 1. 1. 1- 20051121. t ar . gz]
The name of the tar archive is name-yyyymmdd.tar.gz. It contains three files: onedb.xml (the complete
database), active_ip.txt (IP address of the Infoblox appliance), and active_pnoid.txt (indicates whether the
Infoblox appliance is an active"0"or passive"1"member of an HA pair).
Management
System
10.1.1.10
Infoblox
Device
10.1.1.1
The backup.pl
script performs the
following tasks:
Database Download
Login
2 Authenticates the admin and
downloads the database to a
local directory.
C:\Perl\backup\
10.1.1.1-20051121.tar.gz
Backup
File
Writing a Script
Writing a Script
You can write your own scripts to use with the Infoblox appliance. This section presents a simple guide to writing
scripts that perform tasks through the Infoblox DMAPI (Data and Management API).
To help explain the various elements in a script, each section of a sample script is examined. This sample script
accomplishes the following objectives:
Establishes an HTTPS connection (HTTP inside a TLS tunnel) to an Infoblox appliance (IP address = 10.1.1.1;
username = admin; password = infoblox)
Defines and adds a zone named test.com
Defines and adds a host (IP address = 10.1.1.5, fully-qualified domain name = pc.test.com)
Figure 24.5 Adding a Zone and a Host through a Script
You can write your script using any text-editing program.
Note: You must use straight quotation marks in Perl scripts, not smart, curly, or typographers quotes. If your text
editor automatically changes straight quotes to smart quotes, disable this feature.
Overview of a Script
Include the following basic elements when writing any Perl script that uses the Infoblox DMAPI:
Indicating Directory Paths
Checking for Script Errors
Including Required Modules
Making a Connection
Creating Objects
Performing Tasks with Objects
Checking the Return Status
Checking the Status during a Call
Concluding the Script
Putting It All Together
Zone
test.com
Host
10.1.1.5
pc.test.com
Add Zone and Host
to the configuration.
Management
System
10.1.1.2
Infoblox
Device
10.1.1.1
Login
Instructions
2 Authenticates user and instructs the
DNSone device to add a zone
(test.com) and a host (10.1.1.5,
pc.test.com) to its configuration.
The script in this
section performs the
following tasks:
Infoblox DMAPI
Indicating Directory Paths
To run scripts in the Perl\NIOS-release-perl-script-pack directory, open a command window and change the
prompt to be in that directory or specify the path to the script in the command itself. Also, for UNIX-based
operating systems, you must specify the location of the Perl program.
1. For a script to run properly on a UNIX-based operating system, reference the directory containing the local
Perl installation in the first line of the script. For example, if Perl is installed in the /usr/bin directory, write
the first line as follows:
#!/usr/bin/perl
Note: For a Windows operating system, this line is unnecessary.
Checking for Script Errors
Infoblox recommends that you put the use st r i ct ; and war ni ngs; statements at the top of all your Perl
scripts. When you run a script, the Perl compiler checks for common programming errors and lists them if found.
2. As the second line of your script, type the following:
use strict;
use warnings;
#
Because Perl ignores any text in a line following a pound sign # , you can use "#" to insert comments or
empty lines into your script.
Including Required Modules
You only need to reference the Infoblox package in your script for it to use the Infoblox Perl API. All other
required modules are imported from this one, called module.
3. Type the following after the line you wrote in Step 2:
# Include the Infoblox Module
#
use Infoblox;
Making a Connection
You create an Infoblox::Session object to open an HTTPS connection to the Infoblox appliance. It has the same
requirements as an administrative login through the GUI. For a depiction of how a script connects to the
Infoblox appliance, see Figure 24.1 on page 666.
The Session object is the main handler through which all other objects are pushed and pulled. To make a
successful connection, it must contain values or variables for the following three key names:
master IP address of the Infoblox appliance
username Administrators user name
password Administrators password
When defining the key value pairs, you have two options:
You can define the values for ip_addr , name, and string directly in the key pairs. See Step 4a .
You can use the variables $server, $user, and $password in the key pairs, and then provide definitions
for those variables when entering command line options. See Step 4b .
Note: For each call to a new( ) method in the Infoblox::Session class, the script initiates a new session with a
separate login to the Infoblox appliance. Until a script calls a new( ) method, it does not initiate a
connection. You can see samples of new( ) methods in Performing Tasks with Objects on page 676.
Writing a Script
4a. To create a new( ) method in the Infoblox::Session class that allows you to log in as admin1 with password
infoblox1 to an Infoblox appliance at 10.1.1.1, write the following:
# Create a new session
#
my $session = Infoblox::Session->new(
master => '10.1.1.1',
username => 'admin',
password => 'infoblox'
);
As you can see in the syntax above, you define objects through the new ( ) method. Also, note that Perl uses
the double colon :: to separate package name spaces and also to form a path to locate a package that an
object calls.
4b. To place variables in the script, type the following after the last line you wrote in Step 3:
use Getopt::Long;
my $server;
my $user;
my $password;
GetOptions(
"s=s" => \$server,
"u=s" => \$user,
"p=s" => \$password
);
#
#
master => $server,
username => $user,
password => $password
);
Get opt : : Long is a standard Perl module that parses and returns the command line options. In this case, the
options s , u , and p define the variables $ser ver , $user , and $Passwor d respectively. The = operator
indicates that a value is required. (A colon : indicates that a value is optional.) The s following each =
indicates that the value is in the form of a string. (An i indicates that the value is an integer.)
Note: Variable names are case sensitive.
By using I nf obl ox: : Sessi on connection parameters in a script, you do not have to change the script when
you connect to different Infoblox appliances. You can enter the specific IP address, username, and password in
the Perl command line when you run the script.
For example, to run the backup.pl script (stored locally in the C:\Perl\NIOS-release-perl-script-pack directory) on
an Infoblox appliance at 10.1.1.1 with the user name admin1 and a password of infoblox1 and save the backup
database as 10.1.1.1-yyyymmdd.tar.gz. in C:\Perl\backup, open a command window in the
C:\Perl\NIOS-release-perl-script-pack directory, and enter the following command:
perl backup.pl -s 10.1.1.1 -u admin1 -p infoblox1 -o C:\Perl\backup\10.1.1.1
Infoblox DMAPI
Then if you want to back up the database of another Infoblox appliance at a different IP address with different
login requirementsIP address = 10.2.2.2, username = admin2, password = infoblox2, saving as
10.1.1.1-yyyymmdd.tar.gz. in C:\Perl\backupchange the options accordingly and enter the following
command:
perl backup.pl -s 10.2.2.2 -u admin2 -p infoblox2 -o C:\Perl\backup\10.2.2.2
If you use a script exclusively with one Infoblox appliance, there is no need to change the connection and login
information. You can state the specific values in the script by replacing the variables with the information
needed to complete a connection.
Creating Objects
In Making a Connection on page 674, you can see how to create a session object. You can also create a wide
variety of other objects, such as zone objects, network objects, ID grid member objects, host objects, and so on.
Note: To see a list of the DMAPI objects, see the Infoblox section in the ActivePerl Help (Windows), or use the
per l doc I nf obl ox command (UNIX), as explained in Infoblox DMAPI Documentation on page 668.
5. To create the following two objects in the script
a zone object named test.com with the network administrators e-mail address "admin@test.com", and
a host object named pc.test.com with IP address 10.1.1.5 and the comment add host.test.com,
type the following after the last line you wrote in the preceding step:
# Create a new zone
#
my $zone = Infoblox::DNS::Zone->new(
name => 'test.com',
email => 'admin\@test.com'
);
# Create a new host
#
my $host = Infoblox::DNS::Host->new(
name => 'pc.test.com',
ipv4addrs => [ '10.1.1.5' ] ,
comment => 'add host.test.com',
);
Performing Tasks with Objects
After creating an object, you must instruct the Infoblox appliance what to do with it. You do this by passing the
objects (my $zone and my $host in the above example) to the session handler and specifying an operation
such as add , modify , remove, get , or search . These objects send methods to the Infoblox::Session class, which
makes function calls through a secure channel to the Infoblox appliance. The following list shows some of the
main operations that you can do with the my $host object:
Add the object to the configuration
$session->add( $host )
Modify an object that already exists in the configuration
$session->modify ( $host )
Remove it from the configuration
$session->remove ( $host );
or
Writing a Script
$session->remove ( "object" => obj_type, "key-param1" => value )
Search for a single item in the configuration
$session->get ( $host );
Search for a list of items in the configuration
$session->search ( $host );
6. To add the zone and host you created in the Creating Objects section, type the following after the last line
you wrote in Step 5 :
#
# Add a zone
$session->add ( $zone );
#
# Add a host
$session->add ( $host );
#
Note: You must first add the zone to the configuration before you can add a host to that zone.
Checking the Return Status
The session handler returns (1) if a call works and (0) if there is an error. To get more details about an error or
the status of a call, you can check the session handler. The Infoblox appliance stores the results of all calls to
the session handler as an attribute in the session.
7. The Session handler has two values, the return code and a detailed message. To see this information, type
the session object descriptors below after the last line you wrote in Step 6 :
# Get status
#
my $result = $session->status_code();
my $response = $session->status_detail();
Checking the Status during a Call
You can leverage the above behavior to send a call to the session handler whenever the Infoblox appliance
returns an error code.
8. To check if the addition of the zone and host objects succeeds or not, type the following after the last line
you wrote in Step 7:
# Catch zone errors on the fly
#
unless ( $session->add ($Zone) ) {
# returned (0), so there is a problem
print "ERROR : [$result] $response\n";
}
else {
print "SUCCESS\n";
}#Add host
# Catch host errors on the fly
Infoblox DMAPI
#
unless ( $session->add ($Host) ) {
}
else {
print "SUCCESS\n";
}
Concluding the Script
Signal the end of a script by using the exi t statement.
Note: Include the semicolon ; at the end of every statement, even the final one.
9. Type the following at the end of your text file:
exit;
10. Name the text file (for example, script1.pl ), and save it in the C:\Perl\NIOS-release-perl-script-pack
directory.
Putting It All Together
All of the above elements assembled into a single script looks like one of the following. The first version uses
embedded login definitions (see Step 4a ). The second version uses embedded login variables (see Step 4b ).
The section that differs between the two versions is highlighted in red and is marked by a red bar ( | ) in the left
margin.
Version 1 (Embedded Definitions)
#!/usr/bin/perl
use strict;
#
#
use Infoblox;
#
my $session= Infoblox::Session->new(
master => '10.1.1.1',
username => 'admin',
password => 'infoblox'
);
# Create a new zone
#
Writing a Script
name => 'test.com',
);
# Create a new host
#
ipv4addrs => [ '10.1.1.5' ] ,
);
#
# Add a zone
#
# Add a host
#
# Get status
#
#
unless ( $session->add ($zone) ) {
}
else {
print "SUCCESS\n";
}#Add host
#
unless ( $session->add ($host) ) {
}
else {
print "SUCCESS\n";
Infoblox DMAPI
}
exit;
Writing a Script
Version 2 (Embedded Variables)
#!/usr/bin/perl
use strict;
#
#
use Infoblox;
use Getopt::Long;
my $server;
my $user;
my $password;
GetOptions(
"s=s" => \$server,
"u=s" => \$user,
"p=s" => \$password
);
#
master => '$server',
username => '$user',
password => '$password'
);
# Create a new zone
#
name => 'test.com',
);
# Create a new host
#
ipv4addrs => [ '10.1.1.5' ] ,
);
#
# Add a zone
#
# Add a host
Infoblox DMAPI
#
# Get status
#
#
unless ( $session->add ($Zone) ) {
}
else {
print "SUCCESS\n";
}#Add host
#
unless ( $session->add ($host) ) {
}
else {
print "SUCCESS\n";
}
exit;
Perl Information Resources
Perl Information Resources
To learn more about Perl so that you can make full use of the Infoblox DMAPI, Infoblox suggests the following
resources:
Infoblox-Specific Perl Resources
For information specific to the Infoblox DMAPI, see the online documentation explained in Infoblox DMAPI
Documentation on page 668.
Also, see the HTML files in the NIOS-release-perl-script-pack\docs subdirectory, which is included in the Infoblox
Scripting Pack that you can download from the Infoblox Support site (see Infoblox Scripting Pack on page 668):
EXAMPLES.html: Several examples illustrating how to use the Infoblox DMAPI
TROUBLESHOOTING.html: Suggestions for troubleshooting problems when running a script
Perl Resources
To learn about Perl in general, the following websites provide valuable information:
Websites
http://learn.perl.org/
http://www.perl.com/
http://www.perl.com/pub/q/documentation
http://www.perl.org/
http://www.activestate.com/
http://www.cpan.org/
Infoblox DMAPI

Part 5 Reference Material
This section provides reference information about RFC compliance, supported regular expressions, Open Source
license and copyright statements, and hardware-specific information in the following appendices:
Appendix A, "Product Compliance", on page 687
Appendix B, "Regular Expressions", on page 693
Appendix C, "Open Source Copyright and License Statements", on page 695
Appendix D, "Hardware Information", on page 721

Appendix A Product Compliance
This appendix describes the hardware components, requirements, and specifications, plus compliance and safety
for the Infoblox appliance in the following sections:
Power Safety Information on page 688
AC on page 688
DC on page 688
Agency Compliance on page 689
FCC on page 689
Canadian Compliance on page 689
VCCI on page 690
RFC Compliance on page 690
DNS RFC Compliance on page 690
DHCP RFC Compliance on page 692
Product Compliance
Power Safety Information
The main external power connector for the Infoblox appliance is located on the back of the system. Ensure power to
the system is off before connecting the power cord into the power connector. Please read the following power safety
statements for your AC- or DC-powered appliance:
AC
English
WARNING: This product relies on the building's installation for short-circuit (overcurrent) protection.
Ensure that a fuse or circuit breaker no larger than 120VAC, 15AU.S. (240VAC, 10A international)
is used on the phase conductors (all current-carrying conductors).
French
WARNING: Pour ce qui est de la protection contre les courts-circuits (surtension), ce produit dpend de
l'installation lectrique du local. Vrifier qu'un fusible ou qu'un disjoncteur de 120V alt., 15A
U.S. maximum (240V alt., 10A international) est utilis sur les conducteurs de phase (conducteurs
de charge).
German
WARNING: Dieses Produkt ist darauf angewiesen, da im Gebude ein Kurzschlu - bzw. berstromschutz
installiert ist. Stellen Sie sicher, da eine Sicherung oder ein Unterbrecher von nicht mehr als
240V Wechselstrom, 10A (bzw. in den USA120V Wechselstrom, 15A) an den Phasenleitern (allen
stromf hrenden Leitern) verwendet wird.
DC
English
WARNING: When stranded wiring is required, use approved wiring terminations, such as closed-loop or
spade-type with upturned lugs. These terminations should be the appropriate size for the wires
and should clamp both the insulation and conductor.
Agency Compliance
Agency Compliance
The Infoblox appliance is compliant with these EMI and safety agency regulations:
Table A.1 Agency Regulation Compliance
FCC
The FCC label on the back of the system indicates this network appliance is compliant with limits for a Class A digital
device in accordance with Part 15 of the FCC Rules. These limits are designed to provide reasonable protection
against harmful interference when this equipment is operated in a commercial environment. Operation is subject to
the following two conditions:
This device might not cause harmful interference.
This device must accept any interference received, including interference that may cause undesired operation.
This device generates, uses, and can radiate radio frequency energy if not installed and used in accordance with the
instructions in this manual. Operating this equipment in a residential area is likely to cause harmful interference, and
the customer will be required to rectify the interference at his or her own expense. This product requires the use of
external shielded cables to maintain compliance pursuant to Part 15 of the FCC Rules.
Canadian Compliance
English
This Class A digital apparatus complies with Canadian ICES-003.
French
Cet appareil numrique de la classe A est conforme la norme NMB-003 du Canada.
Standard Agency Marks
FCC Part 15 FCC FCC
EN55022, EN55024, EN61000-3-2,
EN61000-3-3
TUV CE
UL60950/CSA60950 UL cULus
EN60950 TUV GS
CB Scheme IECEE Report and Certificate IEC 60950-1:2001
VCCI-A VCCI VCCI
AS/NZS 3548 ACMA C-Tick
Product Compliance
VCCI
The Infoblox appliance complies with this VCCI regulation (compliance statement follow by its translation):
This is a Class A product based on the Technical Requirements of the Voluntary Control Council for Interference
Technology (VCCI). In a domestic environment this product may cause radio interference, in which case the user
may be required to take corrective action.
Caution: Lithium battery included with this board. Do not puncture, mutilate, or dispose of battery in fire. Danger of
explosion if battery is incorrectly replaced. Replace only with the same or equivalent type recommended by
manufacturer. Dispose of used battery according to manufacturer instructions and in accordance with your
local regulations.
RFC Compliance
Compliant with Qualys and Nessus security requirements.
Compliant with these DNS RFCs:
DNS RFC Compliance
DHCP RFC Compliance on page 692
DNS RFC Compliance
These are the DNS RFCs the Infoblox appliance supports:
Table A.2 RFC Compliance
RFC Number RFC Title
805 Computer Mail Meeting Notes
811 Hostnames Server
819 The Domain Naming Convention for Internet User Applications
881 The Domain Names Plan and Schedule
882 Domain Names: Concepts and Facilities
883 Domain Names: Implementation Specification
897 Domain Name System Implementation Schedule
920 Domain Requirements
921 Domain Name System Implementation Schedule Revised
973 Domain System Changes and Observations
974 Mail Routing and the Domain System
1032 Domain Administrators Guide
RFC Compliance
1033 Domain Administrators Operations Guide
1034 Domain Names Concepts and Facilities
1035 Domain Names Implementation and Specification
1101 DNS Encoding of Network Names and Other Types
1122 Requirements for Internet Hosts Communication Layers
1123 Requirements for Internet Hosts Application and Support
1178 Choosing a Name for Your Computer
1348 DNS NSAP RRs
1386 The US Domain
1464 Using the Domain Name System to Store Arbitrary String Attributes
1535 A Security Problem and Proposed Correction with Widely Deployed DNS Software
1536 Common DNS Implementation Errors and Suggested Fixes
1537 Common DNS Data File Configuration Errors
1591 Domain Name System Structure and Delegation
1611 DNS Server MIB Extensions
1612 DNS Resolver MIB Extensions
1637 DNS NSAP Resource Records
1664 Using the Internet DNS to Distribute RFC 1327 Mail Address Mapping Tables
1713 Tools for DNS debugging
1794 DNS Support for Load Balancing
1811 U.S. Government Internet Domain Names
1912 Common DNS Operational and Configuration Errors
1956 Registration in the MIL Domain
1982 Serial Number Arithmetic
1995 Incremental Zone Transfer in DNS
1996 A Mechanism for Prompt Notification of Zone Changes
2010 Operational Criteria for Root Name Servers
2052 A DNS RR for specifying the location of services (DNS SRV)
2053 The AM (Armenia) Domain
2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
2142 Mailbox Names for Common Services, Roles and Functions
2168 Resolution of Uniform Resource Identifiers using the Domain Name System
Product Compliance
DHCP RFC Compliance
These are the DHCP RFCs the Infoblox appliance supports:
Table A.3 RFC Compliance Information for DHCP Protocol
2181 Clarifications to the DNS Specification
2182 Selection and Operation of Secondary DNS Servers
2219 Use of DNS Aliases for Network Services
2240 A Legal Basis for Domain Name Allocation
2308 Negative Caching of DNS Queries (DNS NCACHE)
2317 Classless IN-ADDR.ARPA Delegation
2352 A Convention for Using Legal Names as Domain Names
2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
2606 Reserved Top Level DNS Names
2782 A DNS RR for Specifying the Location of Services (DNS SRV)
2845 Secret Key Transaction Authentication for DNS (TSIG)
3768 Virtual Router Redundancy Protocol (VRRP)
1531 Dynamic Host Configuration Protocol
1534 Interoperation Between DHCP and BOOTP
1542 Clarifications and Extensions for the Bootstrap Protocol
2131 Dynamic Host Configuration Protocol
2132 DHCP Options and BOOTP Vendor Extensions

Appendix B Regular Expressions
Supported Expressions for Search Parameters
NIOS appliances support POSIX extended regular expressions as defined in the POSIX 1003.2 standard. You can use
the following special characters when defining search parameters:
Regular Expressions Purpose Example Meaning
. Match any character c . t Matches c-any character-t.
* Match the previous character 0 or
more times, instead of only once.
a*bc Matches 0, 1, or multiple
occurrences of a, followed by bc:
bc, abc, aabc, aaabc,
+ Match the previous character 1 or
more times.
a+bc Matches 1 or more occurrences of
a, followed by bc: abc, aabc,
aaabc,
? Match the previous character 0 or 1
time.
a?bc Matches 0 or 1 occurrences of a,
followed by bc: bc or abc.
^ Match the beginning of a text string ^c Matches any string beginning with
c: cat but not abc
$ Match the end of a text string $c Matches any string ending with c:
abc but not cat
[number-number ] Match numbers in the specified
range, including the start and end
points.
[0-3] Matches 0, 1, 2, 3.
[number|number ] Match either number specified. [0|3] Matches 0 or 3.
{number1,number2 } Match the previous character at
least number1 times and as many
as number2 times.
a{1,3}bc Matches 1,2, or 3 occurrences of a,
followed by bc: abc, aabc, aaabc.
Regular Expressions
Note: You can change a special charactersuch as the period ( . ), asterisk ( * ), plus sign ( + ), or question mark ( ? )
into a literal character by prefixing it with a backslash ( \ ). For example, to specify a literal period, asterisk,
plus sign, or question mark, use the characters within the following parentheses: ( \. ) , ( \* ), ( \+ ), ( \? ), ( \^ ),
( \$ ).

Appendix C Open Source Copyright and
License Statements
Infoblox has made every attempt to adhere to the guidelines for use and contribution to the open source community.
Please report back to Infoblox any suspected violations of the copyrights, use of open source contributions via the
distribution of binaries and/or source from Infoblox. It is the intent of Infoblox to comply with the open source rules
of use, and comply with the various copyrights found in the distribution of the products from Infoblox.
This appendix contains the copyright notices for the binary-only distribution from Infoblox. Source changes are
contributed back to the open source community when the copyright holder states this is desired. As stated by the
enclosed copyrights, a copy of open source files used in our binary-only distribution is available from Infoblox. There
is a nominal cost to obtain a CD containing the source files, to cover our costs of duplication and distribution. To
obtain a copy of the source, contact us via e-mail at info@infoblox.com, or call us at 1.408.625.4200. The sections
in this appendix include:
GNU General Public License on page 696
GNU Lesser General Public License on page 699
Apache Software License version 1.1 on page 705
ISC BIND Copyright on page 708
ISC BIND Copyright on page 708
ISC DHCP Copyright on page 709
Julian Seward Copyright on page 709
Carnegie Mellon University Copyright on page 710
Thai Open Source Software Center Copyright on page 711
Ian F. Darwin Copyright on page 711
Lawrence Berkeley Copyright on page 712
MIT Kerberos Copyright on page 712
BSD License on page 713
David L. Mills Copyright on page 714
OpenLDAP License on page 714
OpenSSL License on page 715
VIM License on page 716
ZLIB License on page 717
Wietse Venema Copyright on page 718
ECLIPSE SOFTWARE on page 718
Open Source Copyright and License Statements
GNU General Public License
GNU GENERAL PUBLI C LI CENSE
Ver si on 2, J une 1991
Copyr i ght ( C) 1989, 1991 Fr ee Sof t war e Foundat i on, I nc.
59 Templ e Pl ace, Sui t e 330, Bost on, MA 02111- 1307 USA
Ever yone i s per mi t t ed t o copy and di st r i but e ver bat i mcopi es of t hi s l i cense document ,
but changi ng i t i s not al l owed.
Pr eambl e
The l i censes f or most sof t war e ar e desi gned t o t ake away your f r eedomt o shar e and
change i t . By cont r ast , t he GNU Gener al Publ i cLi cense i s i nt ended t o guar ant ee your
f r eedomt o shar e and change f r ee sof t war e- - t o make sur e t he sof t war e i s f r ee f or al l i t s
user s. Thi s Gener al Publ i c Li cense appl i es t o most of t he Fr ee Sof t war e Foundat i ons
sof t war e and t o any ot her pr ogr amwhose aut hor s commi t t o usi ng i t . ( Some ot her Fr ee
Sof t war e Foundat i on sof t war e i s cover ed by t he GNU Li br ar y Gener al Publ i c Li cense
i nst ead. ) You can appl y i t t o your pr ogr ams, t oo.
When we speak of f r ee sof t war e, we ar e r ef er r i ng t o f r eedom, not pr i ce. Our Gener al
Publ i c Li censes ar e desi gned t o make sur e t hat you have t he f r eedomt o di st r i but e copi es
of f r ee sof t war e ( and char ge f or t hi s ser vi ce i f you wi sh) , t hat you r ecei ve sour ce code
or can get i t i f you want i t , t hat you can change t he sof t war e or use pi eces of i t i n
new f r ee pr ogr ams; and t hat you know you can do t hese t hi ngs.
To pr ot ect your r i ght s, we need t o make r est r i ct i ons t hat f or bi d anyone t o deny you
t hese r i ght s or t o ask you t o sur r ender t he r i ght s. These r est r i ct i ons t r ansl at e t o
cer t ai n r esponsi bi l i t i es f or you i f you di st r i but e copi es of t he sof t war e, or i f you
modi f y i t .
For exampl e, i f you di st r i but e copi es of such a pr ogr am, whet her gr at i s or f or a f ee,
you must gi ve t he r eci pi ent s al l t he r i ght s t hat you have. You must make sur e t hat t hey,
t oo, r ecei ve or can get t he sour ce code. And you must show t hemt hese t er ms so t hey know
t hei r r i ght s.
We pr ot ect your r i ght s wi t h t wo st eps: ( 1) copyr i ght t he sof t war e, and ( 2) of f er you
t hi s l i cense whi ch gi ves you l egal per mi ssi on t o copy, di st r i but e and/ or modi f y t he
sof t war e.
Al so, f or each aut hor s pr ot ect i on and our s, we want t o make cer t ai n t hat ever yone
under st ands t hat t her e i s no war r ant y f or t hi s f r ee sof t war e. I f t he sof t war e i s modi f i ed
by someone el se and passed on, we want i t s r eci pi ent s t o know t hat what t hey have i s not
t he or i gi nal , so t hat any pr obl ems i nt r oduced by ot her s wi l l not r ef l ect on t he or i gi nal
aut hor s r eput at i ons.
Fi nal l y, any f r ee pr ogr ami s t hr eat ened const ant l y by sof t war e pat ent s. We wi sh t o
avoi d t he danger t hat r edi st r i but or s of a f r ee pr ogr amwi l l i ndi vi dual l y obt ai n pat ent
l i censes, i n ef f ect maki ng t he pr ogr ampr opr i et ar y. To pr event t hi s, we have made i t
cl ear t hat any pat ent must be l i censed f or ever yones f r ee use or not l i censed at al l .
The pr eci se t er ms and condi t i ons f or copyi ng, di st r i but i on and modi f i cat i on f ol l ow.
GNU GENERAL PUBLI C LI CENSE
TERMS AND CONDI TI ONS FOR COPYI NG, DI STRI BUTI ON AND MODI FI CATI ON
0. Thi s Li cense appl i es t o any pr ogr amor ot her wor k whi ch cont ai ns a not i ce pl aced by
t he copyr i ght hol der sayi ng i t may be di st r i but ed under t he t er ms of t hi s Gener al Publ i c
Li cense. The "Pr ogr am" , bel ow, r ef er s t o any such pr ogr amor wor k, and a " wor k based on
t he Pr ogr am" means ei t her t he Pr ogr amor any der i vat i ve wor k under copyr i ght l aw: t hat
i s t o say, a wor k cont ai ni ng t he Pr ogr amor a por t i on of i t , ei t her ver bat i mor wi t h
modi f i cat i ons and/ or t r ansl at ed i nt o anot her l anguage. ( Her ei naf t er , t r ansl at i on i s
i ncl uded wi t hout l i mi t at i on i n t he t er m" modi f i cat i on" . ) Each l i censee i s addr essed as
" you" .
GNU General Public License
Act i vi t i es ot her t han copyi ng, di st r i but i on and modi f i cat i on ar e not cover ed by t hi s
Li cense; t hey ar e out si de i t s scope. The act of r unni ng t he Pr ogr ami s not r est r i ct ed,
and t he out put f r omt he Pr ogr ami s cover ed onl y i f i t s cont ent s const i t ut e a wor k based
on t he Pr ogr am( i ndependent of havi ng been made by r unni ng t he Pr ogr am) . Whet her t hat i s
t r ue depends on what t he Pr ogr amdoes.
1. You may copy and di st r i but e ver bat i mcopi es of t he Pr ogr ams sour ce code as you
r ecei ve i t , i n any medi um, pr ovi ded t hat you conspi cuousl y and appr opr i at el y publ i sh on
each copy an appr opr i at e copyr i ght not i ce and di scl ai mer of war r ant y; keep i nt act al l
t he not i ces t hat r ef er t o t hi s Li cense and t o t he absence of any war r ant y; and gi ve any
ot her r eci pi ent s of t he Pr ogr ama copy of t hi s Li cense al ong wi t h t he Pr ogr am.
You may char ge a f ee f or t he physi cal act of t r ansf er r i ng a copy, and you may at your
opt i on of f er war r ant y pr ot ect i on i n exchange f or a f ee.
2. You may modi f y your copy or copi es of t he Pr ogr amor any por t i on of i t , t hus f or mi ng
a wor k based on t he Pr ogr am, and copy and di st r i but e such modi f i cat i ons or wor k under
t he t er ms of Sect i on 1 above, pr ovi ded t hat you al so meet al l of t hese condi t i ons:
a) You must cause t he modi f i ed f i l es t o car r y pr omi nent not i ces st at i ng t hat you changed
t he f i l es and t he dat e of any change.
b) You must cause any wor k t hat you di st r i but e or publ i sh, t hat i n whol e or i n par t
cont ai ns or i s der i ved f r omt he Pr ogr amor any par t t her eof , t o be l i censed as a whol e
at no char ge t o al l t hi r d par t i es under t he t er ms of t hi s Li cense.
c) I f t he modi f i ed pr ogr amnor mal l y r eads commands i nt er act i vel y when r un, you must cause
i t , when st ar t ed r unni ng f or such i nt er act i ve use i n t he most or di nar y way, t o pr i nt or
di spl ay an announcement i ncl udi ng an appr opr i at e copyr i ght not i ce and a not i ce t hat t her e
i s no war r ant y ( or el se, sayi ng t hat you pr ovi de a war r ant y) and t hat user s may
r edi st r i but e t he pr ogr amunder t hese condi t i ons, and t el l i ng t he user how t o vi ew a copy
of t hi s Li cense. ( Except i on: i f t he Pr ogr ami t sel f i s i nt er act i ve but does not nor mal l y
pr i nt such an announcement , your wor k based on t he Pr ogr ami s not r equi r ed t o pr i nt an
announcement . )
These r equi r ement s appl y t o t he modi f i ed wor k as a whol e. I f i dent i f i abl e sect i ons of
t hat wor k ar e not der i ved f r omt he Pr ogr am, and can be r easonabl y consi der ed i ndependent
and separ at e wor ks i n t hemsel ves, t hen t hi s Li cense, and i t s t er ms, do not appl y t o t hose
sect i ons when you di st r i but e t hemas separ at e wor ks. But when you di st r i but e t he same
sect i ons as par t of a whol e whi ch i s a wor k based on t he Pr ogr am, t he di st r i but i on of
t he whol e must be on t he t er ms of t hi s Li cense, whose per mi ssi ons f or ot her l i censees
ext end t o t he ent i r e whol e, and t hus t o each and ever y par t r egar dl ess of who wr ot e i t .
Thus, i t i s not t he i nt ent of t hi s sect i on t o cl ai mr i ght s or cont est your r i ght s t o wor k
wr i t t en ent i r el y by you; r at her , t he i nt ent i s t o exer ci se t he r i ght t o cont r ol t he
di st r i but i on of der i vat i ve or col l ect i ve wor ks based on t he Pr ogr am.
I n addi t i on, mer e aggr egat i on of anot her wor k not based on t he Pr ogr amwi t h t he Pr ogr am
( or wi t h a wor k based on t he Pr ogr am) on a vol ume of
a st or age or di st r i but i on medi umdoes not br i ng t he ot her wor k under
t he scope of t hi s Li cense.
3. You may copy and di st r i but e t he Pr ogr am( or a wor k based on i t , under Sect i on 2) i n
obj ect code or execut abl e f or munder t he t er ms of Sect i ons 1 and 2 above pr ovi ded t hat
you al so do one of t he f ol l owi ng:
a) Accompany i t wi t h t he compl et e cor r espondi ng machi ne- r eadabl e sour ce code, whi ch must
be di st r i but ed under t he t er ms of Sect i ons 1 and 2 above on a medi umcust omar i l y used
f or sof t war e i nt er change; or ,
b) Accompany i t wi t h a wr i t t en of f er , val i d f or at l east t hr ee year s, t o gi ve any t hi r d
par t y, f or a char ge no mor e t han your cost of physi cal l y per f or mi ng sour ce di st r i but i on,
a compl et e machi ne- r eadabl e copy of t he cor r espondi ng sour ce code, t o be 11 di st r i but ed
under t he t er ms of Sect i ons 1 and 2 above on a medi umcust omar i l y used f or sof t war e
i nt er change; or ,
c) Accompany i t wi t h t he i nf or mat i on you r ecei ved as t o t he of f er t o di st r i but e
cor r espondi ng sour ce code. ( Thi s al t er nat i ve i s al l owed onl y f or noncommer ci al
di st r i but i on and onl y i f you r ecei ved t he pr ogr ami n obj ect code or execut abl e f or mwi t h
such an of f er , i n accor d wi t h Subsect i on b above. )
The sour ce code f or a wor k means t he pr ef er r ed f or mof t he wor k f or maki ng modi f i cat i ons
t o i t . For an execut abl e wor k, compl et e sour ce code means al l t he sour ce code f or al l
modul es i t cont ai ns, pl us any associ at ed i nt er f ace def i ni t i on f i l es, pl us t he scr i pt s
used t o cont r ol compi l at i on and i nst al l at i on of t he execut abl e. However , as a speci al
except i on, t he sour ce code di st r i but ed need not i ncl ude anyt hi ng t hat i s nor mal l y
di st r i but ed ( i n ei t her sour ce or bi nar y f or m) wi t h t he maj or component s ( compi l er ,
ker nel , and so on) of t he oper at i ng syst emon whi ch t he execut abl e r uns, unl ess t hat
component i t sel f accompani es t he execut abl e.
I f di st r i but i on of execut abl e or obj ect code i s made by of f er i ng access t o copy f r oma
desi gnat ed pl ace, t hen of f er i ng equi val ent access t o copy t he sour ce code f r omt he same
pl ace count s as di st r i but i on of t he sour ce code, even t hough t hi r d par t i es ar e not
compel l ed t o copy t he sour ce al ong wi t h t he obj ect code.
4. You may not copy, modi f y, subl i cense, or di st r i but e t he Pr ogr amexcept as expr essl y
pr ovi ded under t hi s Li cense. Any at t empt ot her wi se t o copy, modi f y, subl i cense or
di st r i but e t he Pr ogr ami s voi d, and wi l l aut omat i cal l y t er mi nat e your r i ght s under t hi s
Li cense. However , par t i es who have r ecei ved copi es, or r i ght s, f r omyou under t hi s Li cense
wi l l not have t hei r l i censes t er mi nat ed so l ong as such par t i es r emai n i n f ul l compl i ance.
5. You ar e not r equi r ed t o accept t hi s Li cense, si nce you have not si gned i t . However ,
not hi ng el se gr ant s you per mi ssi on t o modi f y or di st r i but e t he Pr ogr amor i t s der i vat i ve
wor ks. These act i ons ar e pr ohi bi t ed by l aw i f you do not accept t hi s Li cense. Ther ef or e,
by modi f yi ng or di st r i but i ng t he Pr ogr am( or any wor k based on t he Pr ogr am) , you i ndi cat e
your accept ance of t hi s Li cense t o do so, and al l i t s t er ms and condi t i ons f or copyi ng,
di st r i but i ng or modi f yi ng t he Pr ogr amor wor ks based on i t .
6. Each t i me you r edi st r i but e t he Pr ogr am( or any wor k based on t he Pr ogr am) , t he
r eci pi ent aut omat i cal l y r ecei ves a l i cense f r omt he or i gi nal l i censor t o copy, di st r i but e
or modi f y t he Pr ogr amsubj ect t o t hese t er ms and condi t i ons. You may not i mpose any
f ur t her r est r i ct i ons on t he r eci pi ent s exer ci se of t he r i ght s gr ant ed her ei n. You ar e
not r esponsi bl e f or enf or ci ng compl i ance by t hi r d par t i es t o t hi s Li cense.
7. I f , as a consequence of a cour t j udgment or al l egat i on of pat ent i nf r i ngement or
f or any ot her r eason ( not l i mi t ed t o pat ent i ssues) , condi t i ons ar e i mposed on you
( whet her by cour t or der , agr eement or ot her wi se) t hat cont r adi ct t he condi t i ons of t hi s
Li cense, t hey do not excuse you f r omt he condi t i ons of t hi s Li cense. I f you cannot
di st r i but e so as t o sat i sf y si mul t aneousl y your obl i gat i ons under t hi s Li cense and any
ot her per t i nent obl i gat i ons, t hen as a consequence you may not di st r i but e t he Pr ogr amat
al l . For exampl e, i f a pat ent l i cense woul d not per mi t r oyal t y- f r ee r edi st r i but i on of
t he Pr ogr amby al l t hose who r ecei ve copi es di r ect l y or i ndi r ect l y t hr ough you, t hen t he
onl y way you coul d sat i sf y bot h i t and t hi s Li cense woul d be t o r ef r ai n ent i r el y f r om
di st r i but i on of t he Pr ogr am.
I f any por t i on of t hi s sect i on i s hel d i nval i d or unenf or ceabl e under any par t i cul ar
ci r cumst ance, t he bal ance of t he sect i on i s i nt ended t o appl y and t he sect i on as a whol e
i s i nt ended t o appl y i n ot her ci r cumst ances.
I t i s not t he pur pose of t hi s sect i on t o i nduce you t o i nf r i nge any pat ent s or ot her
pr oper t y r i ght cl ai ms or t o cont est val i di t y of any such cl ai ms; t hi s sect i on has t he
sol e pur pose of pr ot ect i ng t he i nt egr i t y of t he f r ee sof t war e di st r i but i on syst em, whi ch
i s i mpl ement ed by publ i c l i cense pr act i ces. Many peopl e have made gener ous cont r i but i ons
t o t he wi de r ange of sof t war e di st r i but ed t hr ough t hat syst emi n r el i ance on consi st ent
appl i cat i on of t hat syst em; i t i s up t o t he aut hor / donor t o deci de i f he or she i s wi l l i ng
t o di st r i but e sof t war e t hr ough any ot her syst emand a l i censee cannot i mpose t hat choi ce.
Thi s sect i on i s i nt ended t o make t hor oughl y cl ear what i s bel i eved t o be a consequence
of t he r est of t hi s Li cense.
GNU Lesser General Public License
8. I f t he di st r i but i on and/ or use of t he Pr ogr ami s r est r i ct ed i n cer t ai n count r i es
ei t her by pat ent s or by copyr i ght ed i nt er f aces, t he or i gi nal copyr i ght hol der who pl aces
t he Pr ogr amunder t hi s Li cense may add an expl i ci t geogr aphi cal di st r i but i on l i mi t at i on
excl udi ng t hose count r i es, so t hat di st r i but i on i s per mi t t ed onl y i n or among count r i es
not t hus excl uded. I n such case, t hi s Li cense i ncor por at es t he l i mi t at i on as i f wr i t t en
i n t he body of t hi s Li cense.
9. The Fr ee Sof t war e Foundat i on may publ i sh r evi sed and/ or new ver si ons of t he Gener al
Publ i c Li cense f r omt i me t o t i me. Such new ver si ons wi l l be si mi l ar i n spi r i t t o t he
pr esent ver si on, but may di f f er i n det ai l t o addr ess new pr obl ems or concer ns.
Each ver si on i s gi ven a di st i ngui shi ng ver si on number . I f t he Pr ogr amspeci f i es a ver si on
number of t hi s Li cense whi ch appl i es t o i t and " any l at er ver si on" , you have t he opt i on
of f ol l owi ng t he t er ms and condi t i ons ei t her of t hat ver si on or of any l at er ver si on
publ i shed by t he Fr ee Sof t war e Foundat i on. I f t he Pr ogr amdoes not speci f y a ver si on
number of t hi s Li cense, you may choose any ver si on ever publ i shed by t he Fr ee Sof t war e
Foundat i on.
10. I f you wi sh t o i ncor por at e par t s of t he Pr ogr ami nt o ot her f r ee pr ogr ams whose
di st r i but i on condi t i ons ar e di f f er ent , wr i t e t o t he aut hor t o ask f or per mi ssi on. For
sof t war e whi ch i s copyr i ght ed by t he Fr ee Sof t war e Foundat i on, wr i t e t o t he Fr ee Sof t war e
Foundat i on; we somet i mes make except i ons f or t hi s. Our deci si on wi l l be gui ded by t he
t wo goal s of pr eser vi ng t he f r ee st at us of al l der i vat i ves of our f r ee sof t war e and of
pr omot i ng t he shar i ng and r euse of sof t war e gener al l y.
NO WARRANTY
11. BECAUSE THE PROGRAM I S LI CENSED FREE OF CHARGE, THERE I S NO WARRANTY FOR THE
PROGRAM, TO THE EXTENT PERMI TTED BY APPLI CABLE LAW. EXCEPT WHEN OTHERWI SE STATED I N
WRI TI NG THE COPYRI GHT HOLDERS AND/ OR OTHER PARTI ES PROVI DE THE PROGRAM " AS I S" WI THOUT
WARRANTY OF ANY KI ND, EI THER EXPRESSED OR I MPLI ED, I NCLUDI NG, BUT NOT LI MI TED TO, THE
I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR PURPOSE. THE ENTI RE
RI SK AS TO THE QUALI TY AND PERFORMANCE OF THE PROGRAM I S WI TH YOU. SHOULD THE PROGRAM
PROVE DEFECTI VE, YOU ASSUME THE COST OF ALL NECESSARY SERVI CI NG, REPAI R OR CORRECTI ON.
12. I N NO EVENT UNLESS REQUI RED BY APPLI CABLE LAWOR AGREED TO I N WRI TI NG WI LL ANY
COPYRI GHT HOLDER, OR ANY OTHER PARTY WHO MAY MODI FY AND/ OR REDI STRI BUTE THE PROGRAM AS
PERMI TTED ABOVE, BE LI ABLE TO YOU FOR DAMAGES, I NCLUDI NG ANY GENERAL, SPECI AL, I NCI DENTAL
OR CONSEQUENTI AL DAMAGES ARI SI NG OUT OF THE USE OR I NABI LI TY TO USE THE PROGRAM( I NCLUDI NG
BUT NOT LI MI TED TO LOSS OF DATA OR DATA BEI NG RENDERED I NACCURATE OR LOSSES SUSTAI NED BY
YOU OR THI RD PARTI ES OR A FAI LURE OF THE PROGRAM TO OPERATE WI TH ANY OTHER PROGRAMS) ,
EVEN I F SUCH HOLDER OR OTHER PARTY HAS BEEN ADVI SED OF THE POSSI BI LI TY OF SUCH DAMAGES.
END OF TERMS AND CONDI TI ONS
GNU LESSER GENERAL PUBLI C LI CENSE
Ver si on 2. 1, Febr uar y 1999
Copyr i ght ( C) 1991, 1999 Fr ee Sof t war e Foundat i on, I nc.
59 Templ e Pl ace, Sui t e 330, Bost on, MA 02111- 1307 USA
Ever yone i s per mi t t ed t o copy and di st r i but e ver bat i mcopi es of t hi s i cense document ,
but changi ng i t i s not al l owed.
[ Thi s i s t he f i r st r el eased ver si on of t he Lesser GPL. I t al so count s as t he successor
of t he GNU Li br ar y Publ i c Li cense, ver si on 2, hence t he ver si on number 2. 1. ]
Pr eambl e
The l i censes f or most sof t war e ar e desi gned t o t ake away your f r eedomt o shar e and
change i t . By cont r ast , t he GNU Gener al Publ i c Li censes ar e i nt ended t o guar ant ee your
f r eedomt o shar e and change f r ee sof t war e- - t o make sur e t he sof t war e i s f r ee f or al l i t s
user s.
Thi s l i cense, t he Lesser Gener al Publ i c Li cense, appl i es t o some speci al l y desi gnat ed
sof t war e packages- - t ypi cal l y l i br ar i es- - of t he Fr ee Sof t war e Foundat i on and ot her aut hor s
who deci de t o use i t . You can use i t t oo, but we suggest you f i r st t hi nk car ef ul l y about
whet her t hi s l i cense or t he or di nar y Gener al Publ i c Li cense i s t he bet t er st r at egy t o
use i n any par t i cul ar case, based on t he expl anat i ons bel ow.
When we speak of f r ee sof t war e, we ar e r ef er r i ng t o f r eedomof use, not pr i ce. Our
Gener al Publ i c Li censes ar e desi gned t o make sur e t hat you have t he f r eedomt o di st r i but e
copi es of f r ee sof t war e ( and char ge f or t hi s ser vi ce i f you wi sh) ; t hat you r ecei ve sour ce
code or can get i t i f you want i t ; t hat you can change t he sof t war e and use pi eces of i t
i n new f r ee pr ogr ams; and t hat you ar e i nf or med t hat you can do t hese t hi ngs.
To pr ot ect your r i ght s, we need t o make r est r i ct i ons t hat f or bi d di st r i but or s t o deny
you t hese r i ght s or t o ask you t o sur r ender t hese r i ght s. These r est r i ct i ons t r ansl at e
t o cer t ai n r esponsi bi l i t i es f or you i f you di st r i but e copi es of t he l i br ar y or i f you
modi f y i t .
For exampl e, i f you di st r i but e copi es of t he l i br ar y, whet her gr at i s or f or a f ee, you
must gi ve t he r eci pi ent s al l t he r i ght s t hat we gave you. You must make sur e t hat t hey,
t oo, r ecei ve or can get t he sour ce code. I f you l i nk ot her code wi t h t he l i br ar y, you
must pr ovi de compl et e obj ect f i l es t o t he r eci pi ent s, so t hat t hey can r el i nk t hemwi t h
t he l i br ar y af t er maki ng changes t o t he l i br ar y and r ecompi l i ng i t . And you must show
t hemt hese t er ms so t hey know t hei r r i ght s.
We pr ot ect your r i ght s wi t h a t wo- st ep met hod: ( 1) we copyr i ght t he l i br ar y, and ( 2)
we of f er you t hi s l i cense, whi ch gi ves you l egal per mi ssi on t o copy, di st r i but e and/ or
modi f y t he l i br ar y.
To pr ot ect each di st r i but or , we want t o make i t ver y cl ear t hat t her e i s no war r ant y
f or t he f r ee l i br ar y. Al so, i f t he l i br ar y i s modi f i ed by someone el se and passed on,
t he r eci pi ent s shoul d know t hat what t hey have i s not t he or i gi nal ver si on, so t hat t he
or i gi nal aut hor s r eput at i on wi l l not be af f ect ed by pr obl ems t hat mi ght be i nt r oduced by
ot her s.
Fi nal l y, sof t war e pat ent s pose a const ant t hr eat t o t he exi st ence of any f r ee pr ogr am.
We wi sh t o make sur e t hat a company cannot ef f ect i vel y r est r i ct t he user s of a f r ee
pr ogr amby obt ai ni ng a r est r i ct i ve l i cense f r oma pat ent hol der . Ther ef or e, we i nsi st
t hat any pat ent l i cense obt ai ned f or a ver si on of t he l i br ar y must be consi st ent wi t h
t he f ul l f r eedomof use speci f i ed i n t hi s l i cense.
Most GNU sof t war e, i ncl udi ng some l i br ar i es, i s cover ed by t he or di nar y GNU Gener al
Publ i c Li cense. Thi s l i cense, t he GNU Lesser Gener al Publ i c Li cense, appl i es t o cer t ai n
desi gnat ed l i br ar i es, and i s qui t e di f f er ent f r omt he or di nar y Gener al Publ i c Li cense.
We use t hi s l i cense f or cer t ai n l i br ar i es i n or der t o per mi t l i nki ng t hose l i br ar i es i nt o
non- f r ee pr ogr ams.
When a pr ogr ami s l i nked wi t h a l i br ar y, whet her st at i cal l y or usi ng a shar ed l i br ar y,
t he combi nat i on of t he t wo i s l egal l y speaki ng a combi ned wor k, a der i vat i ve of t he
or i gi nal l i br ar y. The or di nar y Gener al Publ i c Li cense t her ef or e per mi t s such l i nki ng onl y
i f t he ent i r e combi nat i on f i t s i t s cr i t er i a of f r eedom. The Lesser Gener al Publ i c Li cense
per mi t s mor e l ax cr i t er i a f or l i nki ng ot her code wi t h t he l i br ar y.
We cal l t hi s l i cense t he " Lesser " Gener al Publ i c Li cense because i t does Less t o pr ot ect
t he user s f r eedomt han t he or di nar y Gener al Publ i c Li cense. I t al so pr ovi des ot her f r ee
sof t war e devel oper s Less of an advant age over compet i ng non- f r ee pr ogr ams. These
di sadvant ages ar e t he r eason we use t he or di nar y Gener al Publ i c Li cense f or many
l i br ar i es. However , t he Lesser l i cense pr ovi des advant ages i n cer t ai n speci al
ci r cumst ances.
For exampl e, on r ar e occasi ons, t her e may be a speci al need t o encour age t he wi dest
possi bl e use of a cer t ai n l i br ar y, so t hat i t becomes a de- f act o st andar d. To achi eve
t hi s, non- f r ee pr ogr ams must be al l owed t o use t he l i br ar y. A mor e f r equent case i s t hat
a f r ee l i br ar y does t he same j ob as wi del y used non- f r ee l i br ar i es. I n t hi s case, t her e
i s l i t t l e t o gai n by l i mi t i ng t he f r ee l i br ar y t o f r ee sof t war e onl y, so we use t he Lesser
Gener al Publ i c Li cense.
I n ot her cases, per mi ssi on t o use a par t i cul ar l i br ar y i n non- f r ee pr ogr ams enabl es a
gr eat er number of peopl e t o use a l ar ge body of f r ee sof t war e. For exampl e, per mi ssi on
t o use t he GNU C Li br ar y i n non- f r ee pr ogr ams enabl es many mor e peopl e t o use t he whol e
GNU oper at i ng syst em, as wel l as i t s var i ant , t he GNU/ Li nux oper at i ng syst em.
Al t hough t he Lesser Gener al Publ i c Li cense i s Less pr ot ect i ve of t he user s f r eedom, i t
does ensur e t hat t he user of a pr ogr amt hat i s l i nked wi t h t he Li br ar y has t he f r eedom
and t he wher ewi t hal t o r un t hat pr ogr amusi ng a modi f i ed ver si on of t he Li br ar y.
The pr eci se t er ms and condi t i ons f or copyi ng, di st r i but i on and modi f i cat i on f ol l ow.
Pay cl ose at t ent i on t o t he di f f er ence bet ween a " wor k based on t he l i br ar y" and a " wor k
t hat uses t he l i br ar y" . The f or mer cont ai ns code der i ved f r omt he l i br ar y, wher eas t he
l at t er must be combi ned wi t h t he l i br ar y i n or der t o r un.
GNU LESSER GENERAL PUBLI C LI CENSE
TERMS AND CONDI TI ONS FOR COPYI NG, DI STRI BUTI ON AND MODI FI CATI ON
0. Thi s Li cense Agr eement appl i es t o any sof t war e l i br ar y or ot her pr ogr amwhi ch
cont ai ns a not i ce pl aced by t he copyr i ght hol der or ot her aut hor i zed par t y sayi ng i t may
be di st r i but ed under t he t er ms of t hi s Lesser Gener al Publ i c Li cense ( al so cal l ed " t hi s
Li cense" ) . Each l i censee i s addr essed as " you" .
A " l i br ar y" means a col l ect i on of sof t war e f unct i ons and/ or dat a pr epar ed so as t o be
conveni ent l y l i nked wi t h appl i cat i on pr ogr ams ( whi ch use some of t hose f unct i ons and
dat a) t o f or mexecut abl es.
The " Li br ar y" , bel ow, r ef er s t o any such sof t war e l i br ar y or wor k whi ch has been
di st r i but ed under t hese t er ms. A "wor k based on t he Li br ar y" means ei t her t he Li br ar y or
any der i vat i ve wor k under copyr i ght l aw: t hat i s t o say, a wor k cont ai ni ng t he Li br ar y
or a por t i on of i t , ei t her ver bat i mor wi t h modi f i cat i ons and/ or t r ansl at ed
st r ai ght f or war dl y i nt o anot her l anguage. ( Her ei naf t er , t r ansl at i on i s i ncl uded wi t hout
l i mi t at i on i n t he t er m" modi f i cat i on" . )
" Sour ce code" f or a wor k means t he pr ef er r ed f or mof t he wor k f or maki ng modi f i cat i ons
t o i t . For a l i br ar y, compl et e sour ce code means al l t he sour ce code f or al l modul es i t
cont ai ns, pl us any associ at ed i nt er f ace def i ni t i on f i l es, pl us t he scr i pt s used t o
cont r ol compi l at i on and i nst al l at i on of t he l i br ar y.
Act i vi t i es ot her t han copyi ng, di st r i but i on and modi f i cat i on ar e not cover ed by t hi s
Li cense; t hey ar e out si de i t s scope. The act of r unni ng a pr ogr amusi ng t he Li br ar y i s
not r est r i ct ed, and out put f r omsuch a pr ogr ami s cover ed onl y i f i t s cont ent s const i t ut e
a wor k based on t he Li br ar y ( i ndependent of t he use of t he Li br ar y i n a t ool f or wr i t i ng
i t ) . Whet her t hat i s t r ue depends on what t he Li br ar y does and what t he pr ogr amt hat uses
t he Li br ar y does.
1. You may copy and di st r i but e ver bat i mcopi es of t he Li br ar ys compl et e sour ce code as
you r ecei ve i t , i n any medi um, pr ovi ded t hat you conspi cuousl y and appr opr i at el y publ i sh
on each copy an appr opr i at e copyr i ght not i ce and di scl ai mer of war r ant y; keep i nt act al l
t he not i ces t hat r ef er t o t hi s Li cense and t o t he absence of any war r ant y; and di st r i but e
a copy of t hi s Li cense al ong wi t h t he Li br ar y.
You may char ge a f ee f or t he physi cal act of t r ansf er r i ng a copy, and you may at your
opt i on of f er war r ant y pr ot ect i on i n exchange f or a f ee.
2. You may modi f y your copy or copi es of t he Li br ar y or any por t i on of i t , t hus f or mi ng
a wor k based on t he Li br ar y, and copy and di st r i but e such modi f i cat i ons or wor k under
t he t er ms of Sect i on 1 above, pr ovi ded t hat you al so meet al l of t hese condi t i ons:
a) The modi f i ed wor k must i t sel f be a sof t war e l i br ar y.
b) You must cause t he f i l es modi f i ed t o car r y pr omi nent not i ces st at i ng t hat you changed
t he f i l es and t he dat e of any change.
c) You must cause t he whol e of t he wor k t o be l i censed at nochar ge t o al l t hi r d par t i es
under t he t er ms of t hi s Li cense.
d) I f a f aci l i t y i n t he modi f i ed Li br ar y r ef er s t o a f unct i on or a t abl e of dat a t o be
suppl i ed by an appr opr i at e pr ogr amt hat uses t he f aci l i t y, ot her t han as an ar gument
passed when t he f aci l i t y i s i nvoked, t hen you must make a good f ai t h ef f or t t o ensur e
t hat , i n t he event an appl i cat i on does not suppl y such f unct i on or t abl e, t he f aci l i t y
st i l l oper at es, and per f or ms what ever par t of i t s pur pose r emai ns meani ngf ul .
( For exampl e, a f unct i on i n a l i br ar y t o comput e squar e r oot s has a pur pose t hat i s
ent i r el y wel l - def i ned i ndependent of t he appl i cat i on. Ther ef or e, Subsect i on 2d r equi r es
t hat any appl i cat i on- suppl i ed f unct i on or t abl e used by t hi s f unct i on must be opt i onal :
i f t he appl i cat i on does not suppl y i t , t he squar e r oot f unct i on must st i l l comput e squar e
r oot s. )
These r equi r ement s appl y t o t he modi f i ed wor k as a whol e. I f i dent i f i abl e sect i ons of
t hat wor k ar e not der i ved f r omt he Li br ar y, and can be r easonabl y consi der ed i ndependent
and separ at e wor ks i n t hemsel ves, t hen t hi s Li cense, and i t s t er ms, do not appl y t o t hose
sect i ons when you di st r i but e t hemas separ at e wor ks. But when you di st r i but e t he same
sect i ons as par t of a whol e whi ch i s a wor k based on t he Li br ar y, t he di st r i but i on of
t he whol e must be on t he t er ms of t hi s Li cense, whose per mi ssi ons f or ot her l i censees
ext end t o t he ent i r e whol e, and t hus t o each and ever y par t r egar dl ess of who wr ot e i t .
Thus, i t i s not t he i nt ent of t hi s sect i on t o cl ai mr i ght s or cont est your r i ght s t o wor k
wr i t t en ent i r el y by you; r at her , t he i nt ent i s t o exer ci se t he r i ght t o cont r ol t he
di st r i but i on of der i vat i ve or col l ect i ve wor ks based on t he Li br ar y.
I n addi t i on, mer e aggr egat i on of anot her wor k not based on t he Li br ar y wi t h t he Li br ar y
( or wi t h a wor k based on t he Li br ar y) on a vol ume of a st or age or di st r i but i on medi um
does not br i ng t he ot her wor k under t he scope of t hi s Li cense.
3. You may opt t o appl y t he t er ms of t he or di nar y GNU Gener al Publ i c Li cense i nst ead
of t hi s Li cense t o a gi ven copy of t he Li br ar y. To do t hi s, you must al t er al l t he not i ces
t hat r ef er t o t hi s Li cense, so t hat t hey r ef er t o t he or di nar y GNU Gener al Publ i c Li cense,
ver si on 2, i nst ead of t o t hi s Li cense. ( I f a newer ver si on t han ver si on 2 of t he or di nar y
GNU Gener al Publ i c Li cense has appear ed, t hen you can speci f y t hat ver si on i nst ead i f
you wi sh. ) Do not make any ot her change i n t hese not i ces.
Once t hi s change i s made i n a gi ven copy, i t i s i r r ever si bl e f or t hat copy, so t he
or di nar y GNU Gener al Publ i c Li cense appl i es t o al l subsequent copi es and der i vat i ve wor ks
made f r omt hat copy.
Thi s opt i on i s usef ul when you wi sh t o copy par t of t he code of t he Li br ar y i nt o a
pr ogr amt hat i s not a l i br ar y.
4. You may copy and di st r i but e t he Li br ar y ( or a por t i on or der i vat i ve of i t , under
Sect i on 2) i n obj ect code or execut abl e f or munder t he t er ms of Sect i ons 1 and 2 above
pr ovi ded t hat you accompany i t wi t h t he compl et e cor r espondi ng machi ne- r eadabl e sour ce
code, whi ch must be di st r i but ed under t he t er ms of Sect i ons 1 and 2 above on a medi um
cust omar i l y used f or sof t war e i nt er change.
I f di st r i but i on of obj ect code i s made by of f er i ng access t o copy f r oma desi gnat ed
pl ace, t hen of f er i ng equi val ent access t o copy t he sour ce code f r omt he same pl ace
sat i sf i es t he r equi r ement t o di st r i but e t he sour ce code, even t hough t hi r d par t i es ar e
not compel l ed t o copy t he sour ce al ong wi t h t he obj ect code.
5. A pr ogr amt hat cont ai ns no der i vat i ve of any por t i on of t he Li br ar y, but i s desi gned
t o wor k wi t h t he Li br ar y by bei ng compi l ed or l i nked wi t h i t , i s cal l ed a " wor k t hat uses
t he Li br ar y" . Such a wor k, i n i sol at i on, i s not a der i vat i ve wor k of t he Li br ar y, and
t her ef or e f al l s out si de t he scope of t hi s Li cense.
However , l i nki ng a " wor k t hat uses t he Li br ar y" wi t h t he Li br ar y cr eat es an execut abl e
t hat i s a der i vat i ve of t he Li br ar y ( because i t cont ai ns por t i ons of t he Li br ar y) , r at her
t han a " wor k t hat uses t he l i br ar y" . The execut abl e i s t her ef or e cover ed by t hi s Li cense.
Sect i on 6 st at es t er ms f or di st r i but i on of such execut abl es.
When a " wor k t hat uses t he Li br ar y" uses mat er i al f r oma header f i l e t hat i s par t of
t he Li br ar y, t he obj ect code f or t he wor k may be a der i vat i ve wor k of t he Li br ar y even
t hough t he sour ce code i s not . Whet her t hi s i s t r ue i s especi al l y si gni f i cant i f t he wor k
can be l i nked wi t hout t he Li br ar y, or i f t he wor k i s i t sel f a l i br ar y. The t hr eshol d f or
t hi s t o be t r ue i s not pr eci sel y def i ned by l aw.
I f such an obj ect f i l e uses onl y numer i cal par amet er s, dat a st r uct ur e l ayout s and
accessor s, and smal l macr os and smal l i nl i ne f unct i ons ( t en l i nes or l ess i n l engt h) ,
t hen t he use of t he obj ect f i l e i s unr est r i ct ed, r egar dl ess of whet her i t i s l egal l y a
der i vat i ve wor k. ( Execut abl es cont ai ni ng t hi s obj ect code pl us por t i ons of t he Li br ar y
wi l l st i l l f al l under Sect i on 6. )
Ot her wi se, i f t he wor k i s a der i vat i ve of t he Li br ar y, you may di st r i but e t he obj ect
code f or t he wor k under t he t er ms of Sect i on 6. Any execut abl es cont ai ni ng t hat wor k al so
f al l under Sect i on 6, whet her or not t hey ar e l i nked di r ect l y wi t h t he Li br ar y i t sel f .
6. As an except i on t o t he Sect i ons above, you may al so combi ne or l i nk a " wor k t hat
uses t he Li br ar y" wi t h t he Li br ar y t o pr oduce a wor k cont ai ni ng por t i ons of t he Li br ar y,
and di st r i but e t hat wor k under t er ms of your choi ce, pr ovi ded t hat t he t er ms per mi t
modi f i cat i on of t he wor k f or t he cust omer s own use and r ever se engi neer i ng f or debuggi ng
such modi f i cat i ons.
You must gi ve pr omi nent not i ce wi t h each copy of t he wor k t hat t he Li br ar y i s used i n
i t and t hat t he Li br ar y and i t s use ar e cover ed by t hi s Li cense. You must suppl y a copy
of t hi s Li cense. I f t he wor k dur i ng execut i on di spl ays copyr i ght not i ces, you must i ncl ude
t he copyr i ght not i ce f or t he Li br ar y among t hem, as wel l as a r ef er ence di r ect i ng t he
user t o t he copy of t hi s Li cense. Al so, you must do one of t hese t hi ngs:
a) Accompany t he wor k wi t h t he compl et e cor r espondi ng machi ne- r eadabl e sour ce code f or
t he Li br ar y i ncl udi ng what ever changes wer e used i n t he wor k ( whi ch must be di st r i but ed
under Sect i ons 1 and 2 above) ; and, i f t he wor k i s an execut abl e l i nked wi t h t he Li br ar y,
wi t h t he compl et e machi ne- r eadabl e " wor k t hat uses t he Li br ar y" , as obj ect code and/ or
sour ce code, so t hat t he user can modi f y t he Li br ar y and t hen r el i nk t o pr oduce a modi f i ed
execut abl e cont ai ni ng t he modi f i ed Li br ar y. ( I t i s under st ood t hat t he user who changes
t he cont ent s of def i ni t i ons f i l es i n t he Li br ar y wi l l not necessar i l y be abl e t o r ecompi l e
t he appl i cat i on t o use t he modi f i ed def i ni t i ons. )
b) Use a sui t abl e shar ed l i br ar y mechani smf or l i nki ng wi t h t he Li br ar y. A sui t abl e
mechani smi s one t hat ( 1) uses at r un t i me a copy of t he l i br ar y al r eady pr esent on t he
user s comput er syst em, r at her t han copyi ng l i br ar y f unct i ons i nt o t he execut abl e, and
( 2) wi l l oper at e pr oper l y wi t h a modi f i ed ver si on of t he l i br ar y, i f t he user i nst al l s
one, as l ong as t he modi f i ed ver si on i s i nt er f ace- compat i bl e wi t h t he ver si on t hat t he
wor k was made wi t h.
c) Accompany t he wor k wi t h a wr i t t en of f er , val i d f or at l east t hr ee year s, t o gi ve t he
same user t he mat er i al s speci f i ed i n Subsect i on 6a, above, f or a char ge no mor e t han t he
cost of per f or mi ng t hi s di st r i but i on.
d) I f di st r i but i on of t he wor k i s made by of f er i ng access t o copy f r oma desi gnat ed pl ace,
of f er equi val ent access t o copy t he above speci f i ed mat er i al s f r omt he same pl ace.
e) Ver i f y t hat t he user has al r eady r ecei ved a copy of t hese mat er i al s or t hat you have
al r eady sent t hi s user a copy.
For an execut abl e, t he r equi r ed f or mof t he " wor k t hat uses t he Li br ar y" must i ncl ude
any dat a and ut i l i t y pr ogr ams needed f or r epr oduci ng t he execut abl e f r omi t . However , as
a speci al except i on, t he mat er i al s t o be di st r i but ed need not i ncl ude anyt hi ng t hat i s
nor mal l y di st r i but ed ( i n ei t her sour ce or bi nar y f or m) wi t h t he maj or component s
( compi l er , ker nel , and so on) of t he oper at i ng syst emon whi ch t he execut abl e r uns, unl ess
t hat component i t sel f accompani es t he execut abl e.
I t may happen t hat t hi s r equi r ement cont r adi ct s t he l i cense r est r i ct i ons of ot her
pr opr i et ar y l i br ar i es t hat do not nor mal l y accompany t he oper at i ng syst em. Such a
cont r adi ct i on means you cannot use bot h t hemand t he Li br ar y t oget her i n an execut abl e
t hat you di st r i but e.
7. You may pl ace l i br ar y f aci l i t i es t hat ar e a wor k based on t he Li br ar y si de- by- si de
i n a si ngl e l i br ar y t oget her wi t h ot her l i br ar y f aci l i t i es not cover ed by t hi s Li cense,
and di st r i but e such a combi ned l i br ar y, pr ovi ded t hat t he separ at e di st r i but i on of t he
wor k based on t he Li br ar y and of t he ot her l i br ar y f aci l i t i es i s ot her wi se per mi t t ed,
and pr ovi ded t hat you do t hese t wo t hi ngs:
a) Accompany t he combi ned l i br ar y wi t h a copy of t he same wor k based on t he Li br ar y,
uncombi ned wi t h any ot her l i br ar y f aci l i t i es. Thi s must be di st r i but ed under t he t er ms
of t he Sect i ons above.
b) Gi ve pr omi nent not i ce wi t h t he combi ned l i br ar y of t he f act t hat par t of i t i s a wor k
based on t he Li br ar y, and expl ai ni ng wher e t o f i nd t he accompanyi ng uncombi ned f or mof
t he same wor k.
8. You may not copy, modi f y, subl i cense, l i nk wi t h, or di st r i but e t he Li br ar y except
as expr essl y pr ovi ded under t hi s Li cense. Any at t empt ot her wi se t o copy, modi f y,
subl i cense, l i nk wi t h, or di st r i but e t he Li br ar y i s voi d, and wi l l aut omat i cal l y
t er mi nat e your r i ght s under t hi s Li cense. However , par t i es who have r ecei ved copi es, or
r i ght s, f r omyou under t hi s Li cense wi l l not have t hei r l i censes t er mi nat ed so l ong as
such par t i es r emai n i n f ul l compl i ance.
9. You ar e not r equi r ed t o accept t hi s Li cense, si nce you have not si gned i t . However ,
not hi ng el se gr ant s you per mi ssi on t o modi f y or di st r i but e t he Li br ar y or i t s der i vat i ve
wor ks. These act i ons ar e pr ohi bi t ed by l aw i f you do not accept t hi s Li cense. Ther ef or e,
by modi f yi ng or di st r i but i ng t he Li br ar y ( or any wor k based on t he Li br ar y) , you i ndi cat e
your accept ance of t hi s Li cense t o do so, and al l i t s t er ms and condi t i ons f or copyi ng,
di st r i but i ng or modi f yi ng t he Li br ar y or wor ks based on i t .
10. Each t i me you r edi st r i but e t he Li br ar y ( or any wor k based on t he Li br ar y) , t he
r eci pi ent aut omat i cal l y r ecei ves a l i cense f r omt he or i gi nal l i censor t o copy,
di st r i but e, l i nk wi t h or modi f y t he Li br ar y subj ect t o t hese t er ms and condi t i ons. You
may not i mpose any f ur t her r est r i ct i ons on t he r eci pi ent s exer ci se of t he r i ght s gr ant ed
her ei n. You ar e not r esponsi bl e f or enf or ci ng compl i ance by t hi r d par t i es wi t h t hi s
Li cense.
11. I f , as a consequence of a cour t j udgment or al l egat i on of pat ent i nf r i ngement or
f or any ot her r eason ( not l i mi t ed t o pat ent i ssues) , condi t i ons ar e i mposed on you
( whet her by cour t or der , agr eement or ot her wi se) t hat cont r adi ct t he condi t i ons of t hi s
Li cense, t hey do not excuse you f r omt he condi t i ons of t hi s Li cense. I f you cannot
di st r i but e so as t o sat i sf y si mul t aneousl y your obl i gat i ons under t hi s Li cense and any
ot her per t i nent obl i gat i ons, t hen as a consequence you may not di st r i but e t he Li br ar y at
al l . For exampl e, i f a pat ent l i cense woul d not per mi t r oyal t y- f r ee r edi st r i but i on of
t he Li br ar y by al l t hose who r ecei ve copi es di r ect l y or i ndi r ect l y t hr ough you, t hen t he
onl y way you coul d sat i sf y bot h i t and t hi s Li cense woul d be t o r ef r ai n ent i r el y f r om
di st r i but i on of t he Li br ar y.
I f any por t i on of t hi s sect i on i s hel d i nval i d or unenf or ceabl e under any par t i cul ar
ci r cumst ance, t he bal ance of t he sect i on i s i nt ended t o appl y, and t he sect i on as a whol e
i s i nt ended t o appl y i n ot her ci r cumst ances.
I t i s not t he pur pose of t hi s sect i on t o i nduce you t o i nf r i nge any pat ent s or ot her
pr oper t y r i ght cl ai ms or t o cont est val i di t y of any such cl ai ms; t hi s sect i on has t he
sol e pur pose of pr ot ect i ng t he i nt egr i t y of t he f r ee sof t war e di st r i but i on syst emwhi ch
i s i mpl ement ed by publ i c l i cense pr act i ces. Many peopl e have made gener ous cont r i but i ons
t o t he wi de r ange of sof t war e di st r i but ed t hr ough t hat syst emi n r el i ance on consi st ent
appl i cat i on of t hat syst em; i t i s up t o t he aut hor / donor t o deci de i f he or she i s wi l l i ng
t o di st r i but e sof t war e t hr ough any ot her syst emand a l i censee cannot i mpose t hat choi ce.
Thi s sect i on i s i nt ended t o make t hor oughl y cl ear what i s bel i eved t o be a consequence
of t he r est of t hi s Li cense.
12. I f t he di st r i but i on and/ or use of t he Li br ar y i s r est r i ct ed i n cer t ai n count r i es
ei t her by pat ent s or by copyr i ght ed i nt er f aces, t he or i gi nal copyr i ght hol der who pl aces
t he Li br ar y under t hi s Li cense may add an expl i ci t geogr aphi cal di st r i but i on l i mi t at i on
excl udi ng t hose count r i es, so t hat di st r i but i on i s per mi t t ed onl y i n or among count r i es
not t hus excl uded. I n such case, t hi s Li cense i ncor por at es t he l i mi t at i on as i f wr i t t en
i n t he body of t hi s Li cense.
13. The Fr ee Sof t war e Foundat i on may publ i sh r evi sed and/ or new ver si ons of t he Lesser
Gener al Publ i c Li cense f r omt i me t o t i me. Such new ver si ons wi l l be si mi l ar i n spi r i t t o
t he pr esent ver si on, but may di f f er i n det ai l t o addr ess new pr obl ems or concer ns.
Each ver si on i s gi ven a di st i ngui shi ng ver si on number . I f t he Li br ar y speci f i es a ver si on
number of t hi s Li cense whi ch appl i es t o i t and " any l at er ver si on" , you have t he opt i on
of f ol l owi ng t he t er ms and condi t i ons ei t her of t hat ver si on or of any l at er ver si on
publ i shed by t he Fr ee Sof t war e Foundat i on. I f t he Li br ar y does not speci f y a l i cense
ver si on number , you may choose any ver si on ever publ i shed by t he Fr ee Sof t war e Foundat i on.
Apache Software License version 1.1
14. I f you wi sh t o i ncor por at e par t s of t he Li br ar y i nt o ot her f r ee pr ogr ams whose
di st r i but i on condi t i ons ar e i ncompat i bl e wi t h t hese, wr i t e t o t he aut hor t o ask f or
per mi ssi on. For sof t war e whi ch i s copyr i ght ed by t he Fr ee Sof t war e Foundat i on, wr i t e t o
t he Fr ee Sof t war e Foundat i on; we somet i mes make except i ons f or t hi s. Our deci si on wi l l
be gui ded by t he t wo goal s of pr eser vi ng t he f r ee st at us of al l der i vat i ves of our f r ee
sof t war e and of pr omot i ng t he shar i ng and r euse of sof t war e gener al l y.
NO WARRANTY
15. BECAUSE THE LI BRARY I S LI CENSED FREE OF CHARGE, THERE I S NO WARRANTY FOR THE LI BRARY,
TO THE EXTENT PERMI TTED BY APPLI CABLE LAW. EXCEPT WHEN OTHERWI SE STATED I N WRI TI NG THE
COPYRI GHT HOLDERS AND/ OR OTHER PARTI ES PROVI DE THE LI BRARY " AS I S" WI THOUT WARRANTY OF
ANY KI ND, EI THER EXPRESSED OR I MPLI ED, I NCLUDI NG, BUT NOT LI MI TED TO, THE I MPLI ED
WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR PURPOSE. THE ENTI RE RI SK AS
TO THE QUALI TY AND PERFORMANCE OF THE LI BRARY I S WI TH YOU. SHOULD THE LI BRARY PROVE
DEFECTI VE, YOU ASSUME THE COST OF ALL NECESSARY SERVI CI NG, REPAI R OR CORRECTI ON.
16. I N NO EVENT UNLESS REQUI RED BY APPLI CABLE LAWOR AGREED TO I N WRI TI NG WI LL ANY
COPYRI GHT HOLDER, OR ANY OTHER PARTY WHO MAY MODI FY AND/ OR REDI STRI BUTE THE LI BRARY AS
PERMI TTED ABOVE, BE LI ABLE TO YOU FOR DAMAGES, I NCLUDI NG ANY GENERAL, SPECI AL, I NCI DENTAL
OR CONSEQUENTI AL DAMAGES ARI SI NG OUT OF THE USE OR I NABI LI TY TO USE THE LI BRARY ( I NCLUDI NG
BUT NOT LI MI TED TO LOSS OF DATA OR DATA BEI NG RENDERED I NACCURATE OR LOSSES SUSTAI NED BY
YOU OR THI RD PARTI ES OR A FAI LURE OF THE LI BRARY TO OPERATE WI TH ANY OTHER SOFTWARE) ,
EVEN I F SUCH HOLDER OR OTHER PARTY HAS BEEN ADVI SED OF THE POSSI BI LI TY OF SUCH DAMAGES.
END OF TERMS AND CONDI TI ONS
Apache Software License version 1.1
/ * ====================================================================
* The Apache Sof t war e Li cense, Ver si on 1. 1
*
* Copyr i ght ( c) 2000 The Apache Sof t war e Foundat i on. Al l r i ght s r eser ved.
*
* Redi st r i but i on and use i n sour ce and bi nar y f or ms, wi t h or wi t hout
* modi f i cat i on, ar e per mi t t ed pr ovi ded t hat t he f ol l owi ng condi t i ons ar e met :
*
* 1. Redi st r i but i ons of sour ce code must r et ai n t he above copyr i ght
* not i ce, t hi s l i st of condi t i ons and t he f ol l owi ng di scl ai mer .
*
* 2. Redi st r i but i ons i n bi nar y f or mmust r epr oduce t he above copyr i ght
* not i ce, t hi s l i st of condi t i ons and t he f ol l owi ng di scl ai mer i n
* t he document at i on and/ or ot her mat er i al s pr ovi ded wi t h t he di st r i but i on.
*
* 3. The end- user document at i on i ncl uded wi t h t he r edi st r i but i on,
* i f any, must i ncl ude t he f ol l owi ng acknowl edgment
* " Thi s pr oduct i ncl udes sof t war e devel oped by t he
* Apache Sof t war e Foundat i on ( ht t p: / / www. apache. or g/ ) . "
* Al t er nat el y, t hi s acknowl edgment may appear i n t he sof t war e i t sel f ,
* i f and wher ever such t hi r d- par t y acknowl edgment s nor mal l y appear .
*
* 4. The names " Apache" and " Apache Sof t war e Foundat i on" must
* not be used t o endor se or pr omot e pr oduct s der i ved f r omt hi s
* sof t war e wi t hout pr i or wr i t t en per mi ssi on. For wr i t t en
* per mi ssi on, pl ease cont act apache@apache. or g.
*
* 5. Pr oduct s der i ved f r omt hi s sof t war e may not be cal l ed "Apache" ,
* nor may " Apache" appear i n t hei r name, wi t hout pr i or wr i t t en
* per mi ssi on of t he Apache Sof t war e Foundat i on.
*
* THI S SOFTWARE I S PROVI DED AS I S AND ANY EXPRESSED OR I MPLI ED
* WARRANTI ES, I NCLUDI NG, BUT NOT LI MI TED TO, THE I MPLI ED WARRANTI ES
* OF MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR PURPOSE ARE
* DI SCLAI MED. I N NO EVENT SHALL THE APACHE SOFTWARE FOUNDATI ON OR
* I TS CONTRI BUTORS BE LI ABLE FOR ANY DI RECT, I NDI RECT, I NCI DENTAL,
* SPECI AL, EXEMPLARY, OR CONSEQUENTI AL DAMAGES ( I NCLUDI NG, BUT NOT
* LI MI TED TO, PROCUREMENT OF SUBSTI TUTE GOODS OR SERVI CES; LOSS OF
* USE, DATA, OR PROFI TS; OR BUSI NESS I NTERRUPTI ON) HOWEVER CAUSED AND
* ON ANY THEORY OF LI ABI LI TY, WHETHER I N CONTRACT, STRI CT LI ABI LI TY,
* OR TORT ( I NCLUDI NG NEGLI GENCE OR OTHERWI SE) ARI SI NG I N ANY WAY OUT
* OF THE USE OF THI S SOFTWARE, EVEN I F ADVI SED OF THE POSSI BI LI TY OF
* SUCH DAMAGE.
* ====================================================================
*
* Thi s sof t war e consi st s of vol unt ar y cont r i but i ons made by many
* i ndi vi dual s on behal f of t he Apache Sof t war e Foundat i on. For mor e
* i nf or mat i on on t he Apache Sof t war e Foundat i on, pl ease see
* <ht t p: / / www. apache. or g/ >.
*
* Por t i ons of t hi s sof t war e ar e based upon publ i c domai n sof t war e
* or i gi nal l y wr i t t en at t he Nat i onal Cent er f or Super comput i ng Appl i cat i ons,
* Uni ver si t y of I l l i noi s, Ur bana- Champai gn.
*/
perl Artistic License
The " Ar t i st i c Li cense"
Pr eambl e
The i nt ent of t hi s document i s t o st at e t he condi t i ons under whi ch a Package may be
copi ed, such t hat t he Copyr i ght Hol der mai nt ai ns some sembl ance of ar t i st i c cont r ol over
t he devel opment of t he package, whi l gi vi ng t he user s of t he package t he r i ght t o use
and di st r i but e t he Package i n a mor e- or - l ess cust omar y f ashi on, pl us t he r i ght t o make
r easonabl e modi f i cat i ons.
Def i ni t i ons:
" Package" r ef er s t o t he col l ect i on of f i l es di st r i but ed by t he Copyr i ght Hol der , and
der i vat i ves of t hat col l ect i on of f i l es cr eat ed t hr ough t ext ual modi f i cat i on.
" St andar d Ver si on" r ef er s t o such a Package i f i t has not been modi f i ed, or has been
modi f i ed i n accor dance wi t h t he wi shes of t he Copyr i ght Hol der as speci f i ed bel ow.
perl Artistic License
" Copyr i ght Hol der " i s whoever i s named i n t he copyr i ght or copyr i ght s f or t he package.
" You" i s you, i f your e t hi nki ng about copyi ng or di st r i but i ng t hi s Package.
" Reasonabl e copyi ng f ee" i s what ever you can j ust i f y on t he basi s of medi a cost ,
dupl i cat i on char ges, t i me of peopl e i nvol ved, and so on. ( You wi l l not be r equi r ed t o
j ust i f y i t t o t he Copyr i ght Hol der , but onl y t o t he comput i ng communi t y at l ar ge as a
mar ket t hat must bear t he f ee. )
" Fr eel y Avai l abl e" means t hat no f ee i s char ged f or t he i t emi t sel f , t hough t her e may be
f ees i nvol ved i n handl i ng t he i t em. I t al so means t hat r eci pi ent s of t he i t emmay
r edi st r i but e i t under t he same condi t i ons t hey r ecei ved i t .
1. You may make and gi ve away ver bat i mcopi es of t he sour ce f or mof t he St andar d Ver si on
of t hi s Package wi t hout r est r i ct i on, pr ovi ded t hat you dupl i cat e al l of t he or i gi nal
copyr i ght not i ces and associ at ed di scl ai mer s.
2. You may appl y bug f i xes, por t abi l i t y f i xes and ot her modi f i cat i ons der i ved f r omt he
Publ i c Domai n or f r omt he Copyr i ght Hol der . A Package modi f i ed i n such a way shal l st i l l
be consi der ed t he St andar d Ver si on.
3. You may ot her wi se modi f y your copy of t hi s Package i n any way, pr ovi ded t hat you i nser t
a pr omi nent not i ce i n each changed f i l e st at i ng how and when you changed t hat f i l e, and
pr ovi ded t hat you do at l east ONE of t he f ol l owi ng:
a) pl ace your modi f i cat i ons i n t he Publ i c Domai n or ot her wi se make t hemFr eel y Avai l abl e,
such as by post i ng sai d modi f i cat i ons t o Usenet or an equi val ent medi um, or pl aci ng t he
modi f i cat i ons on a maj or ar chi ve si t e such as uunet . uu. net , or by al l owi ng t he Copyr i ght
Hol der t o i ncl ude your modi f i cat i ons i n t he St andar d Ver si on of t he Package.
b) use t he modi f i ed Package onl y wi t hi n your cor por at i on or or gani zat i on.
c) r ename any non- st andar d execut abl es so t he names do not conf l i ct wi t h st andar d
execut abl es, whi ch must al so be pr ovi ded, and pr ovi de a separ at e manual page f or each
non- st andar d execut abl e t hat cl ear l y document s how i t di f f er s f r omt he St andar d Ver si on.
d) make ot her di st r i but i on ar r angement s wi t h t he Copyr i ght Hol der .
4. You may di st r i but e t he pr ogr ams of t hi s Package i n obj ect code or execut abl e f or m,
pr ovi ded t hat you do at l east ONE of t he f ol l owi ng:
a) di st r i but e a St andar d Ver si on of t he execut abl es and l i br ar y f i l es, t oget her wi t h
i nst r uct i ons ( i n t he manual page or equi val ent ) on wher e t o get t he St andar d Ver si on.
b) accompany t he di st r i but i on wi t h t he machi ne- r eadabl e sour ce of t he Package wi t h your
modi f i cat i ons.
c) gi ve non- st andar d execut abl es non- st andar d names, and cl ear l y document t he di f f er ences
i n manual pages ( or equi val ent ) , t oget her wi t h i nst r uct i ons on wher e t o get t he St andar d
Ver si on.
d) make ot her di st r i but i on ar r angement s wi t h t he Copyr i ght Hol der .
5. You may char ge a r easonabl e copyi ng f ee f or any di st r i but i on of t hi s Package. You may
char ge any f ee you choose f or suppor t of t hi s Package. You may not char ge a f ee f or t hi s
Package i t sel f . However , you may di st r i but e t hi s Package i n aggr egat e wi t h ot her
( possi bl y commer ci al ) pr ogr ams as par t of a l ar ger ( possi bl y commer ci al ) sof t war e
di st r i but i on pr ovi ded t hat you do not adver t i se t hi s Package as a pr oduct of your own.
You may embed t hi s Packages i nt er pr et er wi t hi n an execut abl e of your s ( by l i nki ng) ; t hi s
shal l be const r ued as a mer e f or mof aggr egat i on, pr ovi ded t hat t he compl et e St andar d
Ver si on of t he i nt er pr et er i s so embedded.
6. The scr i pt s and l i br ar y f i l es suppl i ed as i nput t o or pr oduced as out put f r omt he
pr ogr ams of t hi s Package do not aut omat i cal l y f al l under t he copyr i ght of t hi s Package,
but bel ong t o whoever gener at ed t hem, and may be sol d commer ci al l y, and may be aggr egat ed
wi t h t hi s Package. I f such scr i pt s or l i br ar y f i l es ar e aggr egat ed wi t h t hi s Package vi a
t he so- cal l ed " undump" or " unexec" met hods of pr oduci ng a bi nar y execut abl e i mage, t hen
di st r i but i on of such an i mage shal l nei t her be const r ued as a di st r i but i on of t hi s Package
nor shal l i t f al l under t he r est r i ct i ons of Par agr aphs 3 and 4, pr ovi ded t hat you do not
r epr esent such an execut abl e i mage as a St andar d Ver si on of t hi s Package.
7. C subr out i nes ( or compar abl y compi l ed subr out i nes i n ot her l anguages) suppl i ed by you
and l i nked i nt o t hi s Package i n or der t o emul at e subr out i nes and var i abl es of t he l anguage
def i ned by t hi s Package shal l not be consi der ed par t of t hi s Package, but ar e t he
equi val ent of i nput as i n Par agr aph 6, pr ovi ded t hese subr out i nes do not change t he
l anguage i n any way t hat woul d cause i t t o f ai l t he r egr essi on t est s f or t he l anguage.
8. Aggr egat i on of t hi s Package wi t h a commer ci al di st r i but i on i s al ways per mi t t ed
pr ovi ded t hat t he use of t hi s Package i s embedded; t hat i s, when no over t at t empt i s made
t o make t hi s Packages i nt er f aces vi si bl e t o t he end user of t he commer ci al di st r i but i on.
Such use shal l not be const r ued as a di st r i but i on of t hi s Package.
9. The name of t he Copyr i ght Hol der may not be used t o endor se or pr omot e pr oduct s der i ved
f r omt hi s sof t war e wi t hout speci f i c pr i or wr i t t en per mi ssi on.
10. THI S PACKAGE I S PROVI DED " AS I S" AND WI THOUT ANY EXPRESS OR I MPLI ED WARRANTI ES,
I NCLUDI NG, WI THOUT LI MI TATI ON, THE I MPLI ED WARRANTI ES OF MERCHANTI BI LI TY AND FI TNESS FOR
A PARTI CULAR PURPOSE.
The End
ISC BIND Copyright
Copyr i ght ( C) 1996- 2002 I nt er net Sof t war e Consor t i um.
Per mi ssi on t o use, copy, modi f y, and di st r i but e t hi s sof t war e f or any pur pose wi t h or
wi t hout f ee i s her eby gr ant ed, pr ovi ded t hat t he above copyr i ght not i ce and t hi s
per mi ssi on not i ce appear i n al l copi es.
THE SOFTWARE I S PROVI DED " AS I S" AND I NTERNET SOFTWARE CONSORTI UM DI SCLAI MS ALL
WARRANTI ES WI TH REGARD TO THI S SOFTWARE I NCLUDI NG ALL I MPLI ED WARRANTI ES OF
MERCHANTABI LI TY AND FI TNESS. I N NO EVENT SHALL I NTERNET SOFTWARE CONSORTI UM BE LI ABLE
FOR ANY SPECI AL, DI RECT, I NDI RECT, OR CONSEQUENTI AL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTI NG FROMLOSS OF USE, DATA OR PROFI TS, WHETHER I N AN ACTI ON OF CONTRACT, NEGLI GENCE
OR OTHER TORTI OUS ACTI ON, ARI SI NG OUT OF OR I N CONNECTI ON WI TH THE USE OR PERFORMANCE OF
THI S SOFTWARE.
Por t i ons Copyr i ght ( C) 1996- 2001 Nomi mum, I nc.
Per mi ssi on t o use, copy, modi f y, and di st r i but e t hi s sof t war e f or any pur pose wi t h or
wi t hout f ee i s her eby gr ant ed, pr ovi ded t hat t he above copyr i ght not i ce and t hi s
per mi ssi on not i ce appear i n al l copi es.
THE SOFTWARE I S PROVI DED " AS I S" AND NOMI NUMDI SCLAI MS ALL WARRANTI ES WI TH REGARD TO THI S
SOFTWARE I NCLUDI NG ALL I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS. I N NO EVENT
SHALL NOMI NUM BE LI ABLE FOR ANY SPECI AL, DI RECT, I NDI RECT, OR CONSEQUENTI AL DAMAGES OR
ANY DAMAGES WHATSOEVER RESULTI NG FROMLOSS OF USE, DATA OR PROFI TS, WHETHER I N AN ACTI ON
OF CONTRACT, NEGLI GENCE OR OTHER TORTI OUS ACTI ON, ARI SI NG OUT OF OR I N CONNECTI ON WI TH
THE USE OR PERFORMANCE OF THI S SOFTWARE.
ISC DHCP Copyright
ISC DHCP Copyright
Copyr i ght ( c) 1995, 1996, 1997, 1998, 1999 I nt er net Sof t war e Consor t i um- DHCP. Al l r i ght s
r eser ved.
Redi st r i but i on and use i n sour ce and bi nar y f or ms, wi t h or wi t hout modi f i cat i on, ar e
per mi t t ed pr ovi ded t hat t he f ol l owi ng condi t i ons ar e met :
1. Redi st r i but i ons of sour ce code must r et ai n t he above copyr i ght not i ce, t hi s l i st of
condi t i ons and t he f ol l owi ng di scl ai mer .
2. Redi st r i but i ons i n bi nar y f or mmust r epr oduce t he above copyr i ght not i ce, t hi s l i st
of condi t i ons and t he f ol l owi ng di scl ai mer i n t he document at i on and/ or ot her mat er i al s
pr ovi ded wi t h t he di st r i but i on.
3. Nei t her t he name of I nt er net Sof t war e Consor t i um- DHCP nor t he names of i t s
cont r i but or s may be used t o endor se or pr omot e pr oduct s der i ved f r omt hi s sof t war e wi t hout
speci f i c pr i or wr i t t en per mi ssi on. THI S SOFTWARE I S PROVI DED BY I NTERNET SOFTWARE
CONSORTI UM AND CONTRI BUTORS " AS I S" AND ANY EXPRESS OR I MPLI ED WARRANTI ES, I NCLUDI NG,
BUT NOT LI MI TED TO, THE I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR
PURPOSE ARE DI SCLAI MED. I N NO EVENT SHALL I NTERNET SOFTWARE CONSORTI UM OR CONTRI BUTORS
BE LI ABLE FOR ANY DI RECT, I NDI RECT, I NCI DENTAL, SPECI AL, EXEMPLARY, OR CONSEQUENTI AL
DAMAGES ( I NCLUDI NG, BUT NOT LI MI TED TO, PROCUREMENT OF SUBSTI TUTE GOODS OR SERVI CES; LOSS
OF USE, DATA, OR PROFI TS; OR BUSI NESS I NTERRUPTI ON) HOWEVER CAUSED AND ON ANY THEORY OF
LI ABI LI TY, WHETHER I N CONTRACT, STRI CT LI ABI LI TY, OR TORT ( I NCLUDI NG NEGLI GENCE OR
OTHERWI SE) ARI SI NG I N ANY WAY OUT OF THE USE OF THI S SOFTWARE, EVEN I F ADVI SED OF THE
POSSI BI LI TY OF SUCH DAMAGE.
Julian Seward Copyright
Thi s pr ogr am, " bzi p2" and associ at ed l i br ar y " l i bbzi p2" , ar e copyr i ght ( C) 1996- 2002
J ul i an R Sewar d. Al l r i ght s r eser ved.
2. The or i gi n of t hi s sof t war e must not be mi sr epr esent ed; you must not cl ai mt hat you
wr ot e t he or i gi nal sof t war e. I f you use t hi s sof t war e i n a pr oduct , an acknowl edgment i n
t he pr oduct document at i on woul d be appr eci at ed but i s not r equi r ed.
3. Al t er ed sour ce ver si ons must be pl ai nl y mar ked as such, and must not be mi sr epr esent ed
as bei ng t he or i gi nal sof t war e.
4. The name of t he aut hor may not be used t o endor se or pr omot e pr oduct s der i ved f r om
t hi s sof t war e wi t hout speci f i c pr i or wr i t t en per mi ssi on.
THI S SOFTWARE I S PROVI DED BY THE AUTHOR AS I S AND ANY EXPRESS OR I MPLI ED WARRANTI ES,
I NCLUDI NG, BUT NOT LI MI TED TO, THE I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR
A PARTI CULAR PURPOSE ARE DI SCLAI MED. I N NO EVENT SHALL THE AUTHOR BE LI ABLE FOR ANY
DI RECT, I NDI RECT, I NCI DENTAL, SPECI AL, EXEMPLARY, OR CONSEQUENTI AL DAMAGES ( I NCLUDI NG,
BUT NOT LI MI TED TO, PROCUREMENT OF SUBSTI TUTE GOODS OR SERVI CES; LOSS OF USE, DATA, OR
PROFI TS; OR BUSI NESS I NTERRUPTI ON) HOWEVER CAUSED AND ON ANY THEORY OF LI ABI LI TY, WHETHER
I N CONTRACT, STRI CT LI ABI LI TY, OR TORT ( I NCLUDI NG NEGLI GENCE OR OTHERWI SE) ARI SI NG I N
ANY WAY OUT OF THE USE OF THI S SOFTWARE, EVEN I F ADVI SED OF THE POSSI BI LI TY OF SUCH DAMAGE.
J ul i an Sewar d, Cambr i dge, UK.
j sewar d@acm. or g
bzi p2/ l i bbzi p2 ver si on 1. 0. 2 of 30 December 2001
Carnegie Mellon University Copyright
/ *
* Copyr i ght ( c) 2001 Car negi e Mel l on Uni ver si t y. Al l r i ght s r eser ved.
*
* modi f i cat i on, ar e per mi t t ed pr ovi ded t hat t he f ol l owi ng condi t i ons ar e met :
*
*
* t he document at i on and/ or ot her mat er i al s pr ovi ded wi t h t he
* di st r i but i on.
*
* 3. The name " Car negi e Mel l on Uni ver si t y" must not be used t o
* endor se or pr omot e pr oduct s der i ved f r omt hi s sof t war e wi t hout
* pr i or wr i t t en per mi ssi on. For per mi ssi on or any ot her l egal
* det ai l s, pl ease cont act
* Of f i ce of Technol ogy Tr ansf er
* Car negi e Mel l on Uni ver si t y
* 5000 For bes Avenue
* Pi t t sbur gh, PA 15213- 3890
* ( 412) 268- 4387, f ax: ( 412) 268- 7395
* t ech- t r ansf er @andr ew. cmu. edu
*
* 4. Redi st r i but i ons of any f or mwhat soever must r et ai n t he f ol l owi ng
* acknowl edgment :
* " Thi s pr oduct i ncl udes sof t war e devel oped by Comput i ng Ser vi ces
* at Car negi e Mel l on Uni ver si t y ( ht t p: / / www. cmu. edu/ comput i ng/ ) . "
*
* CARNEGI E MELLON UNI VERSI TY DI SCLAI MS ALL WARRANTI ES WI TH REGARD TO
* THI S SOFTWARE, I NCLUDI NG ALL I MPLI ED WARRANTI ES OF MERCHANTABI LI TY
* AND FI TNESS, I N NO EVENT SHALL CARNEGI E MELLON UNI VERSI TY BE LI ABLE
* FOR ANY SPECI AL, I NDI RECT OR CONSEQUENTI AL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTI NG FROM LOSS OF USE, DATA OR PROFI TS, WHETHER I N
* AN ACTI ON OF CONTRACT, NEGLI GENCE OR OTHER TORTI OUS ACTI ON, ARI SI NG
* OUT OF OR I N CONNECTI ON WI TH THE USE OR PERFORMANCE OF THI S SOFTWARE.
*/
Thai Open Source Software Center Copyright
Thai Open Source Software Center Copyright
Copyr i ght ( c) 1998, 1999, 2000 Thai Open Sour ce Sof t war e Cent er Lt d
and Cl ar k Cooper
Copyr i ght ( c) 2001, 2002 Expat mai nt ai ner s.
Per mi ssi on i s her eby gr ant ed, f r ee of char ge, t o any per son obt ai ni ng a copy of t hi s
sof t war e and associ at ed document at i on f i l es ( t he " Sof t war e" ) , t o deal i n t he Sof t war e
wi t hout r est r i ct i on, i ncl udi ng wi t hout l i mi t at i on t he r i ght s t o use, copy, modi f y, mer ge,
publ i sh, di st r i but e, subl i cense, and/ or sel l copi es of t he Sof t war e, and t o per mi t
per sons t o whomt he Sof t war e i s f ur ni shed t o do so, subj ect t o t he f ol l owi ng condi t i ons:
The above copyr i ght not i ce and t hi s per mi ssi on not i ce shal l be i ncl uded i n al l copi es or
subst ant i al por t i ons of t he Sof t war e.
THE SOFTWARE I S PROVI DED " AS I S" , WI THOUT WARRANTY OF ANY KI ND, EXPRESS OR I MPLI ED,
I NCLUDI NG BUT NOT LI MI TED TO THE WARRANTI ES OF MERCHANTABI LI TY, FI TNESS FOR A PARTI CULAR
PURPOSE AND NONI NFRI NGEMENT. I N NO EVENT SHALL THE AUTHORS OR COPYRI GHT HOLDERS BE LI ABLE
FOR ANY CLAI M, DAMAGES OR OTHER LI ABI LI TY, WHETHER I N AN ACTI ON OF CONTRACT, TORT OR
OTHERWI SE, ARI SI NG FROM, OUT OF OR I N CONNECTI ON WI TH THE SOFTWARE OR THE USE OR OTHER
DEALI NGS I N THE SOFTWARE.
Ian F. Darwin Copyright
Copyr i ght ( c) I an F. Dar wi n 1986, 1987, 1989, 1990, 1991, 1992, 1994, 1995.
Sof t war e wr i t t en by I an F. Dar wi n and ot her s;
mai nt ai ned 1994- 1999 Chr i st os Zoul as.
Thi s sof t war e i s not subj ect t o any expor t pr ovi si on of t he Uni t ed St at es Depar t ment of
Commer ce, and may be expor t ed t o any count r y or pl anet .
1. Redi st r i but i ons of sour ce code must r et ai n t he above copyr i ght not i ce i mmedi at el y at
t he begi nni ng of t he f i l e, wi t hout modi f i cat i on, t hi s l i st of condi t i ons, and t he
f ol l owi ng di scl ai mer .
3. Al l adver t i si ng mat er i al s ment i oni ng f eat ur es or use of t hi s sof t war e must di spl ay
t he f ol l owi ng acknowl edgement :
Thi s pr oduct i ncl udes sof t war e devel oped by I an F. Dar wi n and ot her s.
4. The name of t he aut hor may not be used t o endor se or pr omot e pr oduct s der i ved f r om
THI S SOFTWARE I S PROVI DED BY THE AUTHOR AND CONTRI BUTORS AS I S AND ANY EXPRESS OR
I MPLI ED WARRANTI ES, I NCLUDI NG, BUT NOT LI MI TED TO, THE I MPLI ED WARRANTI ES OF
MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR PURPOSE ARE DI SCLAI MED. I N NO EVENT SHALL
THE AUTHOR OR CONTRI BUTORS BE LI ABLE FOR ANY DI RECT, I NDI RECT, I NCI DENTAL, SPECI AL,
EXEMPLARY, OR CONSEQUENTI AL DAMAGES ( I NCLUDI NG, BUT NOT LI MI TED TO, PROCUREMENT OF
SUBSTI TUTE GOODS OR SERVI CES; LOSS OF USE, DATA, OR PROFI TS; OR BUSI NESS I NTERRUPTI ON)
HOWEVER CAUSED AND ON ANY THEORY OF LI ABI LI TY, WHETHER I N CONTRACT, STRI CT LI ABI LI TY, OR
TORT ( I NCLUDI NG NEGLI GENCE OR OTHERWI SE) ARI SI NG I N ANY WAY OUT OF THE USE OF THI S
SOFTWARE, EVEN I F ADVI SED OF THE POSSI BI LI TY OF SUCH DAMAGE.
Lawrence Berkeley Copyright
Copyr i ght ( c) 1990 The Regent s of t he Uni ver si t y of Cal i f or ni a.
Al l r i ght s r eser ved.
Thi s code i s der i ved f r omsof t war e cont r i but ed t o Ber kel ey by Ver n Paxson.
The Uni t ed St at es Gover nment has r i ght s i n t hi s wor k pur suant t o cont r act no.
DE- AC03- 76SF00098 bet ween t he Uni t ed St at es Depar t ment of Ener gy and t he Uni ver si t y of
Cal i f or ni a.
Redi st r i but i on and use i n sour ce and bi nar y f or ms wi t h or wi t hout modi f i cat i on ar e
per mi t t ed pr ovi ded t hat : ( 1) sour ce di st r i but i ons r et ai n t hi s ent i r e copyr i ght not i ce
and comment , and ( 2) di st r i but i ons i ncl udi ng bi nar i es di spl ay t he f ol l owi ng
acknowl edgement : Thi s pr oduct i ncl udes sof t war e devel oped by t he Uni ver si t y of
Cal i f or ni a, Ber kel ey and i t s cont r i but or s i n t he document at i on or ot her mat er i al s
pr ovi ded wi t h t he di st r i but i on and i n al l adver t i si ng mat er i al s ment i oni ng f eat ur es or
use of t hi s sof t war e. Nei t her t he name of t he Uni ver si t y nor t he names of i t s cont r i but or s
may be used t o endor se or pr omot e pr oduct s der i ved f r omt hi s sof t war e wi t hout speci f i c
pr i or wr i t t en per mi ssi on.
THI S SOFTWARE I S PROVI DED AS I S AND WI THOUT ANY EXPRESS OR I MPLI ED WARRANTI ES,
I NCLUDI NG, WI THOUT LI MI TATI ON, THE I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR
MIT Kerberos Copyright
Copyr i ght Not i ce and Legal Admi ni st r i vi a
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Copyr i ght ( C) 1985- 2002 by t he Massachuset t s I nst i t ut e of Technol ogy.
Al l r i ght s r eser ved.
Expor t of t hi s sof t war e f r omt he Uni t ed St at es of Amer i ca may r equi r e a speci f i c l i cense
f r omt he Uni t ed St at es Gover nment . I t i s t he r esponsi bi l i t y of any per son or or gani zat i on
cont empl at i ng expor t t o obt ai n such a l i cense bef or e expor t i ng.
WI THI N THAT CONSTRAI NT, per mi ssi on t o use, copy, modi f y, and di st r i but e t hi s sof t war e
and i t s document at i on f or any pur pose and wi t hout f ee i s her eby gr ant ed, pr ovi ded t hat
t he above copyr i ght not i ce appear i n al l copi es and t hat bot h t hat copyr i ght not i ce and
t hi s per mi ssi on not i ce appear i n suppor t i ng document at i on, and t hat t he name of M. I . T.
not be used i n adver t i si ng or publ i ci t y per t ai ni ng t o di st r i but i on of t he sof t war e wi t hout
speci f i c, wr i t t en pr i or per mi ssi on. Fur t her mor e i f you modi f y t hi s sof t war e you must
l abel your sof t war e as modi f i ed sof t war e and not di st r i but e i t i n such a f ashi on t hat i t
mi ght be conf used wi t h t he or i gi nal MI T sof t war e.
M. I . T. makes no r epr esent at i ons about t he sui t abi l i t y of t hi s sof t war e f or any pur pose.
I t i s pr ovi ded " as i s" wi t hout expr ess or i mpl i ed war r ant y.
I NCLUDI NG, WI THOUT LI MI TATI ON, THE I MPLI ED WARRANTI ES OF MERCHANTI BI LI TY AND FI TNESS FOR
I ndi vi dual sour ce code f i l es ar e copyr i ght MI T, Cygnus Suppor t , OpenVi si on, Or acl e, Sun
Sof t , FundsXpr ess, and ot her s.
Pr oj ect At hena, At hena, At hena MUSE, Di scuss, Hesi od, Ker ber os, Moi r a, and Zephyr ar e
t r ademar ks of t he Massachuset t s I nst i t ut e of Technol ogy ( MI T) . No commer ci al use of t hese
t r ademar ks may be made wi t hout
pr i or wr i t t en per mi ssi on of MI T.
BSD License
" Commer ci al use" means use of a name i n a pr oduct or ot her f or - pr of i t manner . I t does
NOT pr event a commer ci al f i r mf r omr ef er r i ng t o t he MI T t r ademar ks i n or der t o convey
i nf or mat i on ( al t hough i n doi ng so, r ecogni t i on of t hei r t r ademar k st at us shoul d be
gi ven) .
- - - -
The f ol l owi ng copyr i ght and per mi ssi on not i ce appl i es t o t he OpenVi si on Ker ber os
Admi ni st r at i on syst eml ocat ed i n kadmi n/ cr eat e, kadmi n/ dbut i l , kadmi n/ passwd,
kadmi n/ ser ver , l i b/ kadm5, and por t i ons of l i b/ r pc:
Copyr i ght , OpenVi si on Technol ogi es, I nc. , 1996, Al l Ri ght s Reser ved
WARNI NG: Ret r i evi ng t he OpenVi si on Ker ber os Admi ni st r at i on syst emsour ce code, as
descr i bed bel ow, i ndi cat es your accept ance of t he f ol l owi ng t er ms. I f you do not agr ee
t o t he f ol l owi ng t er ms, do not r et r i eve t he OpenVi si on Ker ber os admi ni st r at i on syst em.
You may f r eel y use and di st r i but e t he Sour ce Code and Obj ect Code compi l ed f r omi t , wi t h
or wi t hout modi f i cat i on, but t hi s Sour ce Code i s pr ovi ded t o you " AS I S" EXCLUSI VE OF
ANY WARRANTY, I NCLUDI NG, WI THOUT LI MI TATI ON, ANY WARRANTI ES OF MERCHANTABI LI TY OR FI TNESS
FOR A PARTI CULAR PURPOSE, OR ANY OTHER WARRANTY, WHETHER EXPRESS OR I MPLI ED. I N NO EVENT
WI LL OPENVI SI ON HAVE ANY LI ABI LI TY FOR ANY LOST PROFI TS, LOSS OF DATA OR COSTS OF
PROCUREMENT OF SUBSTI TUTE GOODS OR SERVI CES, OR FOR ANY SPECI AL, I NDI RECT, OR
CONSEQUENTI AL DAMAGES ARI SI NG OUT OF THI S AGREEMENT, I NCLUDI NG, WI THOUT LI MI TATI ON, THOSE
RESULTI NG FROMTHE USE OF THE SOURCE CODE, OR THE FAI LURE OF THE SOURCE CODE TO PERFORM,
OR FOR ANY OTHER REASON.
OpenVi si on r et ai ns al l copyr i ght s i n t he donat ed Sour ce Code. OpenVi si on al so r et ai ns
copyr i ght t o der i vat i ve wor ks of t he Sour ce Code, whet her cr eat ed by OpenVi si on or by a
t hi r d par t y. The OpenVi si on copyr i ght not i ce must be pr eser ved i f der i vat i ve wor ks ar e
made based on t he donat ed Sour ce Code.
OpenVi si on Technol ogi es, I nc. has donat ed t hi s Ker ber os Admi ni st r at i on syst emt o MI T f or
i ncl usi on i n t he st andar d Ker ber os 5 di st r i but i on. Thi s donat i on under scor es our
commi t ment t o cont i nui ng Ker ber os t echnol ogy devel opment and our gr at i t ude f or t he
val uabl e wor k whi ch has been per f or med by MI T and t he Ker ber os communi t y.
- - - -
Por t i ons cont r i but ed by Mat t Cr awf or d <cr awdad@f nal . gov> wer e wor k per f or med at Fer mi
Nat i onal Accel er at or Labor at or y, whi ch i s oper at ed by Uni ver si t i es Resear ch Associ at i on,
I nc. , under cont r act DE- AC02- 76CHO3000 wi t h t he U. S. Depar t ment of Ener gy.
BSD License
3. The names of t he aut hor s may not be used t o endor se or pr omot e pr oduct s der i ved f r om
I NCLUDI NG, WI THOUT LI MI TATI ON, THE I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR
David L. Mills Copyright
************************************************************************
* *
* Copyr i ght ( c) Davi d L. Mi l l s 1992- 2003 *
* *
* Per mi ssi on t o use, copy, modi f y, and di st r i but e t hi s sof t war e and *
* i t s document at i on f or any pur pose and wi t hout f ee i s her eby *
* gr ant ed, pr ovi ded t hat t he above copyr i ght not i ce appear s i n al l *
* copi es and t hat bot h t he copyr i ght not i ce and t hi s per mi ssi on *
* not i ce appear i n suppor t i ng document at i on, and t hat t he name *
* Uni ver si t y of Del awar e not be used i n adver t i si ng or publ i ci t y *
* per t ai ni ng t o di st r i but i on of t he sof t war e wi t hout speci f i c, *
* wr i t t en pr i or per mi ssi on. The Uni ver si t y of Del awar e makes no *
* r epr esent at i ons about t he sui t abi l i t y t hi s sof t war e f or any *
* pur pose. I t i s pr ovi ded " as i s" wi t hout expr ess or i mpl i ed *
* war r ant y. *
* *
**************************************************************************
OpenLDAP License
The OpenLDAP Publ i c Li cense
Ver si on 2. 8, 17 August 2003
Redi st r i but i on and use of t hi s sof t war e and associ at ed document at i on ( " Sof t war e" ) , wi t h
or wi t hout modi f i cat i on, ar e per mi t t ed pr ovi ded t hat t he f ol l owi ng condi t i ons ar e met :
1. Redi st r i but i ons i n sour ce f or mmust r et ai n copyr i ght st at ement s and not i ces,
2. Redi st r i but i ons i n bi nar y f or mmust r epr oduce appl i cabl e copyr i ght st at ement s and
not i ces, t hi s l i st of condi t i ons, and t he f ol l owi ng di scl ai mer i n t he document at i on
and/ or ot her mat er i al s pr ovi ded wi t h t he di st r i but i on, and
3. Redi st r i but i ons must cont ai n a ver bat i mcopy of t hi s document .
The OpenLDAP Foundat i on may r evi se t hi s l i cense f r omt i me t o t i me. Each r evi si on i s
di st i ngui shed by a ver si on number . You may use t hi s Sof t war e under t er ms of t hi s l i cense
r evi si on or under t he t er ms of any subsequent r evi si on of t he l i cense.
THI S SOFTWARE I S PROVI DED BY THE OPENLDAP FOUNDATI ON AND I TS CONTRI BUTORS AS I S AND
ANY EXPRESSED OR I MPLI ED WARRANTI ES, I NCLUDI NG, BUT NOT LI MI TED TO, THE I MPLI ED
WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR PURPOSE ARE DI SCLAI MED. I N NO
EVENT SHALL THE OPENLDAP FOUNDATI ON, I TS CONTRI BUTORS, OR THE AUTHOR( S) OR OWNER( S) OF
THE SOFTWARE BE LI ABLE FOR ANY DI RECT, I NDI RECT, I NCI DENTAL, SPECI AL, EXEMPLARY, OR
CONSEQUENTI AL DAMAGES ( I NCLUDI NG, BUT NOT LI MI TED TO, PROCUREMENT OF SUBSTI TUTE GOODS OR
SERVI CES; LOSS OF USE, DATA, OR PROFI TS; OR BUSI NESS I NTERRUPTI ON) HOWEVER CAUSED AND ON
ANY THEORY OF LI ABI LI TY, WHETHER I N CONTRACT, STRI CT LI ABI LI TY, OR TORT ( I NCLUDI NG
NEGLI GENCE OR OTHERWI SE) ARI SI NG I N ANY WAY OUT OF THE USE OF THI S SOFTWARE, EVEN I F
ADVI SED OF THE POSSI BI LI TY OF SUCH DAMAGE.
The names of t he aut hor s and copyr i ght hol der s must not be used i n adver t i si ng or
ot her wi se t o pr omot e t he sal e, use or ot her deal i ng i n t hi s Sof t war e wi t hout speci f i c,
wr i t t en pr i or per mi ssi on. Ti t l e t o copyr i ght i n t hi s Sof t war e shal l at al l t i mes r emai n
wi t h copyr i ght hol der s.
OpenLDAP i s a r egi st er ed t r ademar k of t he OpenLDAP Foundat i on.
Copyr i ght 1999- 2003 The OpenLDAP Foundat i on, Redwood Ci t y, Cal i f or ni a, USA. Al l Ri ght s
Reser ved. Per mi ssi on t o copy and di st r i but e ver bat i mcopi es of t hi s document i s gr ant ed.
OpenSSL License
OpenSSL License
/ * ====================================================================
* Copyr i ght ( c) 1998- 2003 The OpenSSL Pr oj ect . Al l r i ght s r eser ved.
*
* modi f i cat i on, ar e per mi t t ed pr ovi ded t hat t he f ol l owi ng condi t i ons
* ar e met :
*
*
* t he document at i on and/ or ot her mat er i al s pr ovi ded wi t h t he
* di st r i but i on.
*
* 3. Al l adver t i si ng mat er i al s ment i oni ng f eat ur es or use of t hi s
* sof t war e must di spl ay t he f ol l owi ng acknowl edgment :
* " Thi s pr oduct i ncl udes sof t war e devel oped by t he OpenSSL Pr oj ect
* f or use i n t he OpenSSL Tool ki t . ( ht t p: / / www. openssl . or g/ ) "
*
* 4. The names " OpenSSL Tool ki t " and " OpenSSL Pr oj ect " must not be used t o
* endor se or pr omot e pr oduct s der i ved f r omt hi s sof t war e wi t hout
* pr i or wr i t t en per mi ssi on. For wr i t t en per mi ssi on, pl ease cont act
* openssl - cor e@openssl . or g.
*
* 5. Pr oduct s der i ved f r omt hi s sof t war e may not be cal l ed "OpenSSL"
* nor may " OpenSSL" appear i n t hei r names wi t hout pr i or wr i t t en
* per mi ssi on of t he OpenSSL Pr oj ect .
*
* 6. Redi st r i but i ons of any f or mwhat soever must r et ai n t he f ol l owi ng
* acknowl edgment :
* " Thi s pr oduct i ncl udes sof t war e devel oped by t he OpenSSL Pr oj ect
* f or use i n t he OpenSSL Tool ki t ( ht t p: / / www. openssl . or g/ ) "
*
* THI S SOFTWARE I S PROVI DED BY THE OpenSSL PROJ ECT AS I S AND ANY
* EXPRESSED OR I MPLI ED WARRANTI ES, I NCLUDI NG, BUT NOT LI MI TED TO, THE
* I MPLI ED WARRANTI ES OF MERCHANTABI LI TY AND FI TNESS FOR A PARTI CULAR
* PURPOSE ARE DI SCLAI MED. I N NO EVENT SHALL THE OpenSSL PROJ ECT OR
* I TS CONTRI BUTORS BE LI ABLE FOR ANY DI RECT, I NDI RECT, I NCI DENTAL,
* SPECI AL, EXEMPLARY, OR CONSEQUENTI AL DAMAGES ( I NCLUDI NG, BUT
* NOT LI MI TED TO, PROCUREMENT OF SUBSTI TUTE GOODS OR SERVI CES;
* LOSS OF USE, DATA, OR PROFI TS; OR BUSI NESS I NTERRUPTI ON)
* HOWEVER CAUSED AND ON ANY THEORY OF LI ABI LI TY, WHETHER I N CONTRACT,
* STRI CT LI ABI LI TY, OR TORT ( I NCLUDI NG NEGLI GENCE OR OTHERWI SE)
* ARI SI NG I N ANY WAY OUT OF THE USE OF THI S SOFTWARE, EVEN I F ADVI SED
* OF THE POSSI BI LI TY OF SUCH DAMAGE.
* ====================================================================
*
* Thi s pr oduct i ncl udes cr ypt ogr aphi c sof t war e wr i t t en by Er i c Young
* ( eay@cr ypt sof t . com) . Thi s pr oduct i ncl udes sof t war e wr i t t en by Ti m
* Hudson ( t j h@cr ypt sof t . com) .
*
*/
VIM License
COPYI NG
Vi mi s Char i t ywar e. You can use and copy i t as much as you l i ke, but you ar e encour aged
t o make a donat i on t o or phans i n Uganda. Pl ease r ead t he f i l e " r unt i me/ doc/ uganda. t xt "
f or det ai l s.
Ther e ar e no r est r i ct i ons on di st r i but i ng an unmodi f i ed copy of Vi m. Par t s of Vi mmay
al so be di st r i but ed, but t hi s t ext must al ways be i ncl uded. You ar e al l owed t o i ncl ude
execut abl es t hat you made f r omt he unmodi f i ed Vi msour ces, your own usage exampl es and
Vi mscr i pt s.
I f you di st r i but e a modi f i ed ver si on of Vi m, you ar e encour aged t o send t he mai nt ai ner
a copy, i ncl udi ng t he sour ce code. Or make i t avai l abl e t o t he mai nt ai ner t hr ough f t p;
l et hi mknow wher e i t can be f ound. I f t he number of changes i s smal l ( e. g. , a modi f i ed
Makef i l e) e- mai l i ng t he di f f s wi l l do. When t he mai nt ai ner asks f or i t ( i n any way) you
must make your changes, i ncl udi ng sour ce code, avai l abl e t o hi m.
The mai nt ai ner r eser ves t he r i ght t o i ncl ude any changes i n t he of f i ci al ver si on of Vi m.
Thi s i s negot i abl e. You ar e not al l owed t o di st r i but e a modi f i ed ver si on of Vi mwhen you
ar e not wi l l i ng t o make t he sour ce code avai l abl e t o t he mai nt ai ner .
The cur r ent mai nt ai ner i s Br amMool enaar <Br am@vi m. or g>. I f t hi s changes, i t wi l l be
announced i n appr opr i at e pl aces ( most l i kel y www. vi m. or g and comp. edi t or s) . When i t i s
compl et el y i mpossi bl e t o cont act t he mai nt ai ner , t he obl i gat i on t o send hi mmodi f i ed
sour ce code ceases.
I t i s not al l owed t o r emove t hese r est r i ct i ons f r omt he di st r i but i on of t he Vi msour ces
or par t s of i t . These r est r i ct i ons may al so be used f or pr evi ous Vi mr el eases i nst ead of
t he t ext t hat was i ncl uded wi t h i t .
Vi mi s Char i t ywar e. You can use and copy i t as much as you l i ke, but you ar e encour aged
t o make a donat i on f or needy chi l dr en i n Uganda. Pl ease see | kcc| bel ow or vi si t t he I CCF
web si t e, avai l abl e at t hese mi r r or s:
ht t p: / / i ccf - hol l and. or g/
ht t p: / / www. vi m. or g/ i ccf /
ht t p: / / www. i ccf . nl /
The Open Publ i cat i on Li cense appl i es t o t he Vi mdocument at i on, see
| manual - copyr i ght | .
=== begi n of l i cense ===
VI M LI CENSE
Ther e ar e no r est r i ct i ons on di st r i but i ng unmodi f i ed copi es of Vi mexcept t hat t hey must
i ncl ude t hi s l i cense t ext . You can al so di st r i but e unmodi f i ed par t s of Vi m, l i kewi se
unr est r i ct ed except t hat t hey must i ncl ude t hi s l i cense t ext . You ar e al so al l owed t o
i ncl ude execut abl es t hat you made f r omt he unmodi f i ed Vi msour ces, pl us your own usage
exampl es and Vi mscr i pt s.
I t i s al l owed t o di st r i but e a modi f i ed ( or ext ended) ver si on of Vi m, i ncl udi ng execut abl es
and/ or sour ce code, when t he f ol l owi ng f our condi t i ons ar e met :
1) Thi s l i cense t ext must be i ncl uded unmodi f i ed.
2) The modi f i ed Vi mmust be di st r i but ed i n one of t he f ol l owi ng f i ve
ways:
ZLIB License
a) I f you make changes t o Vi myour sel f , you must cl ear l y descr i be i n t he di st r i but i on
how t o cont act you. When t he mai nt ai ner asks you ( i n any way) f or a copy of t he modi f i ed
Vi myou di st r i but ed, you must make your changes, i ncl udi ng sour ce code, avai l abl e t o t he
mai nt ai ner wi t hout f ee. The mai nt ai ner r eser ves t he r i ght t o i ncl ude your changes i n t he
of f i ci al ver si on of Vi m. What t he mai nt ai ner wi l l do wi t h your changes and under what
l i cense t hey wi l l be di st r i but ed i s negot i abl e. I f t her e has been no negot i at i on t hen
t hi s l i cense, or a l at er ver si on, al so appl i es t o your changes. The cur r ent mai nt ai ner
i s Br amMool enaar <Br am@vi m. or g>. I f t hi s changes i t wi l l be announced i n appr opr i at e
pl aces ( most l i kel y vi m. sf . net , www. vi m. or g and/ or comp. edi t or s) . When i t i s compl et el y
i mpossi bl e t o cont act t he mai nt ai ner , t he obl i gat i on t o send hi myour changes ceases.
Once t he mai nt ai ner has conf i r med t hat he has r ecei ved your changes t hey wi l l not have
t o be sent agai n.
b) I f you have r ecei ved a modi f i ed Vi mt hat was di st r i but ed as ment i oned under a) you
ar e al l owed t o f ur t her di st r i but e i t unmodi f i ed, as ment i oned at I ) . I f you make
addi t i onal changes t he t ext under a) appl i es t o t hose changes.
c) Pr ovi de al l t he changes, i ncl udi ng sour ce code, wi t h ever y copy of t he modi f i ed Vi m
you di st r i but e. Thi s may be done i n t he f or mof a cont ext di f f . You can choose what
l i cense t o use f or new code you add. The changes and t hei r l i cense must not r est r i ct
ot her s f r ommaki ng t hei r own changes t o t he of f i ci al ver si on of Vi m.
d) When you have a modi f i ed Vi mwhi ch i ncl udes changes as ment i oned under c) , you can
di st r i but e i t wi t hout t he sour ce code f or t he changes i f t he f ol l owi ng t hr ee condi t i ons
ar e met :
- The l i cense t hat appl i es t o t he changes per mi t s you t o di st r i but e t he changes t o t he
Vi mmai nt ai ner wi t hout f ee or r est r i ct i on, and per mi t s t he Vi mmai nt ai ner t o i ncl ude t he
changes i n t he of f i ci al ver si on of Vi mwi t hout f ee or r est r i ct i on.
- You keep t he changes f or at l east t hr ee year s af t er l ast di st r i but i ng t he
cor r espondi ng modi f i ed Vi m. When t he mai nt ai ner or someone who you di st r i but ed t he
modi f i ed Vi mt o asks you ( i n any way) f or t he changes wi t hi n t hi s per i od, you must make
t hemavai l abl e t o hi m.
- You cl ear l y descr i be i n t he di st r i but i on how t o cont act you. Thi s cont act i nf or mat i on
must r emai n val i d f or at l east t hr ee year s af t er l ast di st r i but i ng t he cor r espondi ng
modi f i ed Vi m, or as l ong as possi bl e.
e) When t he GNU Gener al Publ i c Li cense ( GPL) appl i es t o t he changes, you can di st r i but e
t he modi f i ed Vi munder t he GNU GPL ver si on 2 or any l at er ver si on.
3) A message must be added, at l east i n t he out put of t he " : ver si on" command and i n
t he i nt r o scr een, such t hat t he user of t he modi f i ed Vi mi s abl e t o see t hat i t was
modi f i ed. When di st r i but i ng as ment i oned under 2) e) addi ng t he message i s onl y r equi r ed
f or as f ar as t hi s does not conf l i ct wi t h t he l i cense used f or t he changes.
4) The cont act i nf or mat i on as r equi r ed under 2) a) and 2) d) must not be r emoved or
changed, except t hat t he per son hi msel f can make cor r ect i ons.
I f you di st r i but e a modi f i ed ver si on of Vi m, you ar e encour aged t o use t he Vi ml i cense
f or your changes and make t hemavai l abl e t o t he mai nt ai ner , i ncl udi ng t he sour ce code.
The pr ef er r ed way t o do t hi s i s by e- mai l or by upl oadi ng t he f i l es t o a ser ver and
e- mai l i ng t he URL. I f t he number of changes i s smal l ( e. g. , a modi f i ed Makef i l e) e- mai l i ng
a cont ext di f f wi l l do. The e- mai l addr ess t o be used i s <mai nt ai ner @vi m. or g>
I t i s not al l owed t o r emove t hi s l i cense f r omt he di st r i but i on of t he Vi msour ces, par t s
of i t or f r oma modi f i ed ver si on. You may use t hi s l i cense f or pr evi ous Vi mr el eases
i nst ead of t he l i cense t hat t hey came wi t h, at your opt i on.
=== end of l i cense ===
ZLIB License
( C) 1995- 2002 J ean- l oupGai l l y and Mar k Adl er
Thi s sof t war e i s pr ovi ded as- i s, wi t hout any expr ess or i mpl i ed war r ant y. I n no event
wi l l t he aut hor s be hel d l i abl e f or any damages ar i si ng f r omt he use of t hi s sof t war e.
Per mi ssi on i s gr ant ed t o anyone t o use t hi s sof t war e f or any pur pose, i ncl udi ng commer ci al
appl i cat i ons, and t o al t er i t and r edi st r i but e i t f r eel y, subj ect t o t he f ol l owi ng
r est r i ct i ons:
The or i gi n of t hi s sof t war e must not be mi sr epr esent ed; you must not cl ai mt hat you wr ot e
t he or i gi nal sof t war e. I f you use t hi s sof t war e i n a pr oduct , an acknowl edgment i n t he
pr oduct document at i on woul d be appr eci at ed but i s not r equi r ed.
Al t er ed sour ce ver si ons must be pl ai nl y mar ked as such, and must not be mi sr epr esent ed
as bei ng t he or i gi nal sof t war e.
Thi s not i ce may not be r emoved or al t er ed f r omany sour ce di st r i but i on.
J ean- l oup Gai l l y Mar k Adl er
j l oup@gzi p. or g madl er @al umni . cal t ech. edu
I f you use t he zl i b l i br ar y i n a pr oduct , we woul d appr eci at e *not * r ecei vi ng l engt hy
l egal document s t o si gn. The sour ces ar e pr ovi ded f or f r ee but wi t hout war r ant y of any
ki nd. The l i br ar y has been ent i r el y wr i t t en by J ean- l oup Gai l l y and Mar k Adl er ; i t does
not i ncl ude t hi r d- par t y code.
I f you r edi st r i but e modi f i ed sour ces, we woul d appr eci at e t hat you i ncl ude i n t he f i l e
ChangeLog hi st or y i nf or mat i on document i ng your changes.
Wietse Venema Copyright
/ ************************************************************************ * Copyr i ght
1995 by Wi et se Venema. Al l r i ght s r eser ved. Some i ndi vi dual * f i l es may be cover ed by
ot her copyr i ght s. * * Thi s mat er i al was or i gi nal l y wr i t t en and compi l ed by Wi et se Venema
at * Ei ndhoven Uni ver si t y of Technol ogy, The Net her l ands, i n 1990, 1991, * 1992, 1993,
1994 and 1995. * * Redi st r i but i on and use i n sour ce and bi nar y f or ms ar e per mi t t ed *
pr ovi ded t hat t hi s ent i r e copyr i ght not i ce i s dupl i cat ed i n al l such * copi es. * * Thi s
sof t war e i s pr ovi ded " as i s" and wi t hout any expr essed or i mpl i ed * war r ant i es, i ncl udi ng,
wi t hout l i mi t at i on, t he i mpl i ed war r ant i es of * mer chant i bi l i t y and f i t ness f or any
par t i cul ar pur pose.
************************************************************************/
ECLIPSE SOFTWARE
The pr oduct i ncl udes Ecl i pse sof t war e ( t he "Ecl i pse Pr ogr am") pr ovi ded by t he Ecl i pse
Foundat i on and l i censed t o I nf obl ox I nc. under t he Ecl i pse Publ i c Li cense v1. 0.
EXCEPT AS EXPRESSLY SET FORTH I N THE ECLI PSE PUBLI C LI CENSE, THE ECLI PSE PROGRAM I S
PROVI DED ON AN " AS I S" BASI S, WI THOUT WARRANTI ES OR CONDI TI ONS OF ANY KI ND, EI THER EXPRESS
OR I MPLI ED I NCLUDI NG, WI THOUT LI MI TATI ON, ANY WARRANTI ES OR CONDI TI ONS OF TI TLE,
NON- I NFRI NGEMENT, MERCHANTABI LI TY OR FI TNESS FOR A PARTI CULAR PURPOSE.
EXCEPT AS EXPRESSLY SET FORTH I N THE ECLI PSE PUBLI C LI CENSE, NEI THER THE ECLI PSE
FOUNDATI ON NOR ANY CONTRI BUTORS TO THE ECLI PSE PROGRAM SHALL HAVE ANY LI ABI LI TY FOR ANY
DI RECT, I NDI RECT, I NCI DENTAL, SPECI AL, EXEMPLARY, OR CONSEQUENTI AL DAMAGES ( I NCLUDI NG
WI THOUT LI MI TATI ON LOST PROFI TS) , HOWEVER CAUSED AND ON ANY THEORY OF LI ABI LI TY, WHETHER
I N CONTRACT, STRI CT LI ABI LI TY, OR TORT ( I NCLUDI NG NEGLI GENCE OR OTHERWI SE) ARI SI NG I N
ANY WAY OUT OF THE USE OF THE ECLI PSE PROGRAM, EVEN I F ADVI SED OF THE POSSI BI LI TY OF SUCH
DAMAGES.
Any pr ovi si ons pr ovi ded by I nf obl ox r el at i ng t o t he Ecl i pse Pr ogr amwhi ch di f f er f r om
t he above t er ms or t he Ecl i pse Publ i c Li cense ar e of f er ed by I nf obl ox al one and not by
any ot her par t y.
ECLIPSE SOFTWARE
The sour ce code f or t he Ecl i pse Pr ogr ami s avai l abl e f r omI nf obl ox as descr i bed i n t he
open sour ce i nt r oduct i on.

Appendix D Hardware Information
This appendix describes the different hardware components and lists the hardware specifications for the
Infoblox-1000 and -1200 appliances. For information about all other Infoblox platforms, refer to the user guide that
ships with the product. This chapter also provides rack mounting and cabling instructions. The topics in this chapter
include:
About the Hardware Components on page 722
Identifying the Front Panel Components on page 722
Using the LCD Panel on page 723
Using the Serial Console on page 723
Ports on page 724
About Back Panel Components on page 725
Connecting the Ethernet Cables on page 725
Independent Appliance Cabling Using the LAN or Serial Port on page 725
HA Pair Appliance Cabling Using the LAN and HA Ports on page 726
Cabling for the MGMT Port on page 727
Rack Mounting Information on page 731
Chassis Warning on page 731
Rack Mounting and Safety on page 731
Hardware Platform Specifications and Requirements on page 732
System Specifications on page 732
Environmental Specifications on page 732
AC Electrical Power Specifications on page 732
DC Electrical Power Specifications on page 732
Hardware Information
About the Hardware Components
Infoblox-1000 and -1200 appliances have many of the same ports and connectors common to standard PCs, but also
have some unique components. The USB port is the only connection on the front of the appliance that is not used for
managing the appliance. This section explains what all the components are in the following sections:
Identifying the Front Panel Components on this page
Using the LCD Panel on page 723
Using the Serial Console on page 723
Ports on page 724
Identifying the Front Panel Components
All network components for an Infoblox appliance are on the front of the appliance.
Figure D.1 Front Panel of the Infoblox-1000 and -1200 Appliances
The purpose of each of these components is as follows:
LCD: Used to view current appliance software version and configuration status
Navigation Buttons: Used to change the appliance configuration settings
MGMT Port: Used to separate the management communications from the services port
Serial Port: Used to change the basic appliance configuration and control basic system functions with a remote
terminal connection
LAN Port: Used for the IP connection that provides DNS and DHCP services for your network
HA Port: Used for the IP connection between an HA pair of nodes
LCD
Navigation
Buttons
MGMT
Port
Serial
Port
LAN
Port
HA
Port
About the Hardware Components
Using the LCD Panel
Every Infoblox appliance has an LCD (liquid crystal display) and navigation buttons that allow you to view the software
version, system status, and high availability status; and to view and configure an IP address, subnet mask, and
gateway for the LAN port.
At startup, the Infoblox logo is displayed. The System Status Mode is displayed next. This mode has three display
screens that scroll the following information for three seconds each:
Status 1:
Software version number
16 characters serial number
Keystone DVS License information
License expiration information. License expiration information displays one of the following:
Permanent: Permanent license installed.
MM/DD/YYYY: License expiration date.
None or N/A: License not installed.
Status 2:
DNS: License EXP information
DHCP: License EXP information
Status 3:
NIOS maintenance license
License expiration information
Keystone maintenance license
License expiration information
If you press a navigation button while the LCD is in the System Status mode, the LCD immediately goes into input
mode, which cycles through three input screens that allow you to perform the following tasks:
Enter IP address of the LAN port
Enter the netmask of the subnet to which the LAN port connects
Enter the gateway IP address for the subnet to which the LAN port connects
After you finish entering settings in these three screens, the screen fades in and out for 10 seconds. Each entry screen
has an OK option and a CNCL (cancel) option. Selecting CNCL at any time returns to the previous screen, or the System
Status screen in the case of the first entry screen. Clicking OK on the third screen also returns to the System Status
screen. Also, if there is no activity for two consecutive minutes, the LCD returns to the System Status screen.
Using the Serial Console
Using a serial connection to operate the Infoblox appliance requires a laptop (or computer in cable range of the
appliance), the RJ-45 rollover cable and two female RJ-45-to-female DB-9 adapters shipped with the product, and a
terminal emulation application.
To operate the Infoblox appliance using a serial console:
1. Use a null modem cable to connect a laptop or local computer to the Infoblox appliance through the serial port.
(You can use either the RJ-45 rollover cable and two female RJ-45-to-female DB-9 adapters shipped with the
product or a female DB-9-to-female DB-9 null modem cable.)
2. Start a serial terminal emulation application (such as HyperTerminal on Microsoft Windows or Minicom on
Linux) on your computer. For example, start HyperTerminal by clicking Start -> Programs -> Accessories ->
Communications -> HyperTerminal.
3. Set the communications settings in your terminal emulation application to the following values:
4. Use the terminal emulation commands application to connect to the appliance.
5. At the login prompt, enter your login name.
6. At the password prompt, enter your password.
7. To display a list of the commands you can use in the serial console, enter help at the command prompt.
8. If you change any of the network settings, enter y (for yes) at the prompt to reboot.
Ports
There are four ports on the front of the Infoblox-1000 and -1200 appliances:
LAN Provides the connection for network service traffic to the appliance. If syslog is used, the syslog reporting
binds to the LAN port unless the MGMT port is enabled. This port needs to be connected to your local network.
HA Provides the connection between two nodes in an HA pair. The cable must be routed through a local
network switch; this connection does not work if you connect the two HA ports directly.
MGMT Provides the ability to separate network service traffic from appliance management traffic. If syslog is
used, syslog uses the MGMT port only if the MGMT port is enabled. This port needs to be connected to your local
network or directly to a remote computer.
Console Provides command line functionality for the appliance. Use the serial cable and connection adapters
shipped with the appliance when connecting to this port.
Note: For more information on the services and functions that the three ethernet portsLAN, HA, and MGMT
process, see Ethernet Port Usage on page 132.
Setting Value
Bits per second 9600
Data bits 8
Parity None
Stop bits 1
Flow control Xon/Xoff
Connecting the Ethernet Cables
About Back Panel Components
The components on the back of the Infoblox-1000 and -1200 appliances are for electrical power only. The
Infoblox-1552 has dual power supplies. For information about replacing them, refer to the user guide that ships with
the product.
Figure D.2 Back Panel of an Infoblox-1000 or -1200 Appliance
There are three basic cabling configurations:
For the LAN port on an independent appliance or a single grid member
For the LAN and HA ports on an HA pair, regardless of whether the pair of appliances are used as an
independent HA pair or as a grid master or member
For the MGMT, LAN, and HA ports on independent appliances and grid members
Independent Appliance Cabling Using the LAN or Serial Port
Figure D.3 shows a single independent Infoblox appliance. To manage the Infoblox-1000 or -1200 appliance through
the GUI, connect ethernet cables between the LAN port on the Infoblox appliance and a local network switch, and
again between a management system and the same switch. In this example, the connection to the management
system would go through the same router as the DNS and DHCP service traffic provided by the Infoblox appliance.
You may use the GUI to manage an Infoblox appliance, or you can use a serial console. If you use a serial console, the
necessary cables were shipped with the product, but your computer must have a terminal application (such as
HyperTerminal on Microsoft
Windows or Minicom on Linux) program already installed. This serial connection allows
you to use CLI (command line interface) commands to monitor and configure the Infoblox appliance. Note that the
monitoring and configuration options available through the CLI are limited.
Figure D.3 Cabling for Independent Infoblox Appliance Configuration
Power Connector
Power Switch
Management
System
L2/L3
Switch
Serial Port LAN Port
Ethernet Cable
Serial Cable
Internet
HA Pair Appliance Cabling Using the LAN and HA Ports
Figure D.4 shows a pair of Infoblox-1000 or -1200 appliances configured to be an HA pair. To manage them through
the GUI, connect ethernet cables from the LAN and HA ports on both appliances to a local network switch. Also,
connect an ethernet cable from your management system to the same switch. In this example, the connection from
the management system would go through the same router as the DNS and DHCP service traffic provided by the HA
pair.
Note: Do not use a crossover cable to connect the two HA ports on the Infoblox appliances. This only works on
Infoblox appliances running the DNSone 2.X software, and completely disrupts network connectivity for an HA
pair running DNSone 3.X software or later.
In this example, the Infoblox appliances can be part of a grid, or not, and operate as a single entity like the single
appliance above. Both are capable of providing simultaneous DNS and DHCP services for your LAN. This example also
shows using the LAN port for the management, and not using the serial console or management (MGMT) port.
Figure D.4 Cabling for an HA Pair Configuration
Never disconnect the LAN and HA cables to force a failover between the HA nodes. Refer to Forcing an HA Failover on
page 263. Make sure each node uses a different static IP addresses in the same subnet.
HA Port
L2/L3
Switch
LAN Port HA Port LAN Port
Management
System
Active Node Passive Node
Internet
Cabling for the MGMT Port
The MGMT port can be used for:
Out-of-band appliance management
Grid communications
DNS services
For more information about these three options, refer to Using the MGMT Port on page 136.
Out-of-Band Management Cabling
Figure D.5 shows a single independent appliance. To manage a single independent appliance through its MGMT port,
connect an ethernet cable between the MGMT port and a private network switch. Next, connect an ethernet cable
between the LAN port and a local network switch. Connect the management system to the local network switch to log
in to the appliance and enable the MGMT port. After the MGMT port is enabled, then connect the management system
to the private switch. A crossover cable can be used to connect the management system directly to the appliance.
In this example, the appliance management traffic goes through the MGMT port, while DNS and DHCP services goes
through the LAN port.
Figure D.5 Cabling an Independent Infoblox-1000 or -1200 Appliance for Out-of-Band Management
Figure D.6 on page 728 shows an HA pair deployed as either an independent HA pair or an HA grid master. To manage
the active node through MGMT port, connect ethernet cables between the MGMT port and a private network switch.
Connect the management system to a local network switch. Connect ethernet cables between the LAN and HA ports
and a local network switch. After the MGMT port is enabled, connect the management system to the private switch.
In this example, the Infoblox appliances are not accessible on the local network and communicate across a private
network. Both independent and grid HA pairs are capable of providing simultaneous DNS and DHCP services on the
LAN and HA ports. If the HA pair is a grid master, it communicates with grid members through the LAN and HA ports.
Management
System
L2/L3
Switch
MGMT Port LAN Port
Ethernet Cable
Crossover Cable
L2/L3
Switch
Internet
Figure D.6 Cabling an Independent HA Pair for Out-of-Band Management
Grid Services Management Cabling
Figure D.7 shows a single Infoblox-1000 or -1200 appliance deployed as a grid member. To route grid services
through the MGMT port, connect ethernet cables between the MGMT port on the grid member and a private network
switch. Connect the management system to this same private switch. Connect ethernet cables between the LAN and
HA ports on the grid master to the private switch.
In this example, the single grid member is capable of providing simultaneous DNS and DHCP services on the LAN
port, but the grid services traffic goes through the MGMT port. If the HA pair grid master is using the out-of-band
function, there should be a router and another switch between the grid master and the switch connected to the grid
member.
Figure D.7 Cabling for a Single Member using the MGMT Port for Grid Services
MGMT Port
L2/L3
Switch
LAN/HA Ports
MGMT Port LAN/HA Ports
Internet
Management
System
L2/L3
Switch
Active Node
Passive Node
Management
System
L2/L3
Switch
MGMT Port LAN Port
L2/L3
Switch
Internet
LAN Port
HA Master
Single Member
HA Port
LAN Port HA Port
Figure D.8 shows an HA pair deployed as a grid member. To route grid services through the MGMT ports, connect
ethernet cables between the MGMT ports on the grid member and a private network switch. Connect the management
system to this same private switch. Connect ethernet cables between the LAN and HA ports on the grid master to the
private switch.
In this example, the HA pair grid member is capable of providing simultaneous DNS and DHCP services on the LAN
port, but the grid services traffic goes through the MGMT port. If the HA pair grid master is using the out-of-band
function, there should be a router and another switch between the grid master and the switch connected to the grid
member.
Figure D.8 Cabling for an HA Member Using Grid Communications
Management
System
L2/L3
Switch
MGMT Port LAN and HA Ports
L2/L3
Switch
Internet
LAN Port
HA Master
HA Member
HA Port
LAN Port HA Port
Active Node
Passive Node
MGMT Port LAN and HA Ports
DNS Services Cabling
Figure D.9 shows a single Infoblox-1000 or -1200 appliance deployed as an independent server. To route DNS
services through the MGMT port, connect ethernet cables between the MGMT port on the appliance and a private
network switch. Connect an ethernet cable between the LAN port and a local network switch. Initially connect the
management system to this same local network switch. After you enable the MGMT port and DNS services, connect
the management system to the private switch.
In this example, DNS services go through the MGMT port, and all other protocol services go through the LAN port. By
default, a single appliance using the MGMT port for DNS services also uses out-of-band management on the MGMT
port.
Figure D.9 Cabling for an Independent Appliance Using its LAN Port for DNS and its MGMT Port for Management
Figure D.10 shows a single Infoblox-1000 or -1200 appliance deployed as grid member. To route DNS services
through its MGMT port, connect ethernet cables between the MGMT port on the appliance and a private network
switch. Connect the management system to this same private switch. Connect ethernet cables between the LAN and
HA ports on the grid master to the private switch.
In this example, DNS services go through the MGMT port and other protocol services go through the LAN port.
Figure D.10 Cabling for a Single Member Using its LAN Port for DNS and its MGMT Port for Grid Communications
Management
System
L2/L3
Switch
MGMT Port LAN Port LAN Port
L2/L3
Switch
Internet
Single Independent
Management
System
L2/L3
Switch
MGMT Port LAN Port
L2/L3
Switch
Internet
LAN Port
Grid Master
HA Port LAN Port HA Port
Single Member
Rack Mounting Information
Rack Mounting Information
Infoblox-1000 or -1200 appliances mount into a standard 19 (48 cm) equipment rack. The mounting brackets
required to mount the appliance are shipped with the product, and the bolts for attaching the mounting brackets are
screwed into the sides of the system. This product may require safety agency evaluation, certification, or licensing.
Ask your building inspector for requirements applicable to your location.
Chassis Warning
When operating the appliance in an equipment rack, take the following precautions:
Make sure the ambient temperature around the appliance (which may be higher than the room temperature) is
within the limit specified for the appliance.
Make sure there is sufficient airflow around the appliance.
Make sure electrical circuits are not overloaded consider the backplate rating of all the connected equipment,
and make sure you have over current protection.
Make sure the appliance is properly grounded.
Make sure no objects are placed on top of the appliance
Rack Mounting and Safety
Read and factor these considerations before rack mounting your appliance.
English
WARNING: To prevent bodily injury when mounting or servicing this appliance in a rack, you must take special
precautions to ensure that the system remains stable. The following guidelines are provided to
ensure your safety.
This appliance should be mounted at the bottom of the rack if it is the only appliance in the rack.
When mounting this appliance in a partially filled rack, load the rack from the bottom to the top with the
heaviest component at the bottom of the rack.
If the rack is provided with stabilizing appliances, install the stabilizers before mounting or servicing the
appliance in the rack.
French
WARNING: Pour viter toute blessure corporelle pendant les oprations de montage ou de rparation de
cette unit en casier, il convient de prendre des prcautions spciales afin de maintenir la stabilit
du systme. Les directives ci-dessous sont destines assurer la protection du personnel.
Si cette unit constitue la seule unite monte en casier, elle doit tre place dans le bas.
Si cette unit est monte dans un casier partiellement rempli, charger le casier de bas en haut en plaant
l'lment le plus lourd dans le bas.
Si le casier est quip de dispositifs stabilisateurs, installer les stabilisateurs avant de monter ou de
rparer l'unit en casier.
German
WARNING: Zur Vermeidung von Krperverletzung beim Anbringen oder Warten dieser Einheit in einem Gestell
mssen Sie besondere Vorkehrungen treffen, um sicherzustellen, dab das System stabil bleibt. Die
folgenden Richtlinien sollen zur Gewhrleistung Ihrer Sicherheit dienen.
Wenn diese Einheit die einzige im Gestell ist, sollte sie unten im Gestell angebracht werden.
Bei Anbringung dieser Einheit in einem zum Teil gefllten Gestell ist das Gestell von unten nach oben zu
laden, wobei das schwerste Bauteil unten im Gestell anzubringen ist.
Wird das Gestell mit Stabilisierungszubehr geliefert, sind zuerst die Stabilisatoren zu installieren, bevor
Sie die Einheit im Gestell anbringen oder sie warten.
Hardware Platform Specifications and Requirements
This section lists the hardware platform specifications and requirements for the Infoblox-500, -1000, -1010 (DC), and
-1200. For hardware information for other Infoblox platforms, refer to the user guide that ships with the product.
System Specifications
Form Factor: 1U rack mountable appliance
Dimensions: 1.75 H x 17.25 W x 15 D (4.45 cm H x 43.82 cm W x 38.1 cm)
Weight: Approximately 13 pounds
Ethernet Ports:
MGMT 10/100 Base T
LAN 10/100/1000 Base T
HA 10/100/1000 Base T
Console Port: DB9 (9600/8n1, Xon/Xoff)
LCD Panel: Liquid Crystal Display (LCD) with input buttons
Caution: There is a risk of explosion if you replace the CR2032 lithium cell 3V battery on the motherboard with an
incorrect type. Dispose of used batteries according to regional requirements.
Environmental Specifications
The environmental specifications are as follows:
Operating Temperature: 41 to 95 degrees F (5 to 35 degrees C)
Storage Temperature: -40 to 122 degrees F (-40 to 50 degrees C)
Relative Humidity: 5% to 95%, relative humidity (non-condensing)
AC Electrical Power Specifications
The AC electrical power specifications are as follows:
Input Voltage: 100-240 VAC switchable, 47-63 HZ, 3 A
Output Power: 250 watts
DC Electrical Power Specifications
The DC electrical power specifications are as follows:
Input Voltage: 40-60 VDC, 9 A
Output Power: 250 watts
For installation in a restricted access location only. The protection circuit for the DC system should have a 10-15 A
circuit breaker.
Index
A
A records
adding 394
adding to shared record groups 417
AAAA records
adding 395
Active Directory
authenticating admins 110
configuring for NAC Foundation 594
configuring support for 438446
importing users from 620
user class assignments 588
admin groups 67108
ALL USERS group 69
confuguring on RADIUS server 108
defining permissions 74
limited-access 69, 70
superusers 69
admins
authenticating 101
authenticating using RADIUS 104
defining admin policy 112
notifying 113
password length 113
using Active Directory to authenticate 110
anycast 452
API
introduction 665
migrating data 264
audit log
configuring 170
IPAM device types 560
sending to syslog 166
B
backup file
creating and restoring 222
BOOTP
DHCP option filters 505
specifying parameters 492
bulk host records 389
admin permissions 87
C
cache
clearing on a Linux computer 42
DNS 447
managing settings 46
software version 44
captive portal
configuring 590
capture traffic 173
certificates
default of the appliance 39, 44
EAP certificate signing request 626
for admin authentication 111
generating a certificate signing request 49
generating self-signed 48
importing 49
LDAP server 625
manage during login 45
on grid connector and appliance 621
RADIUS authentication 626
self-signed EAP 626
uploading and downloading 627
CNAME records 400
connecting to a NIOS appliance 38
customizing columns 54
D
Data Import Wizard
migrating data 264
DDNS 537556
configuring DHCP 541548
configuring DNS 552554
TSIG 555
verification 549
delegated zones 365
detailed status 160
NTP status icons 118
viewing 160
device status 160
DHCP
configuration checklist 487
defining admin permissions 90
enabling 489
general properties 488
lease times 491
monitoring address usage 567
NAC Foundation module 583
viewing configuration file 517
viewing lease details 574
DHCP client identifiers 467
DHCP failover
assigning to DHCP range 469
configuring 514
DHCP filters 499513
DHCP lease history
enabling 498
importing and exporting 579
maximum capacity 579
viewing 574
DHCP option filters 505
DHCP options
configuring 494
option 12 542
option 15 542
option 60 495
option 61 467
option 81 545
DHCP ranges
applying MAC address filters 504
applying option filters 506
applying relay agent filters 513
Index
assigning device types 560
configuring 469
defining admin permissions 91, 94
NAC Foundation module 587
permission to assign members 82
permission to create from template 95
using templates 473
DHCP statistics 571
DHCP templates
assigning device types 561
configuring 470480
distribution
NIOS software 265
DMAPI 665
DNAME records 402
DNS
allow and deny queries 428
cache 447
configuration checklist 335
configuration file 447
enabling 433
forwarders 432
IPv6 347
logging categories 167
root name servers 430
setting TTL 424
sort lists 431
specifying DNS resolvers 147
updates for a zone 544
using MGMT port 142
zone statistics 447
DNS views 337346
read-only permission 82, 91
DNSone
software package 30
documentation
content organization 20
related technical documents 24
style conventions 22
dynamic DNS
See DDNS
E
EAP-TLS 618
EAP-TTLS 618
Ethernet ports 132
expand networks 462
exporting data 60
F
fixed addresses
assigning devce types 561
configuring 467
converting from dynamiz lease 564
converting to reserved or host 566
DNS updates 548
using templates 476
forward zones 366
forwarders 432
FTP
backup file 222
configuring 609
uploading files 610
G
gateways
defined 30
global search 55
grid
configuring 267309
defined 30
deployment scenario 33
DNS updates for DHCP 544
downgrading 220
multiple grid deployment 34, 35
NAT groups 271
promoting master candidate 309
removing a member 309
replacing a master 309
replication status 163
restart services 156
restricting access 129
upgrading software 313
VitalQIP 648
Grid Connector for Active Directory 620
Grid Manager 4345
grid master
candidate defined 31
defined 31
promoting candidate 309
grid members
admin permission to assign to DHCP range 94
assigning RADIUS policy group 631
assigning to DHCP ranges 469
assigning to networks 461
configuring syslog 166
defined 31
DHCP lease history log 498
DHCP logging 576
modifying security settings 131
permissions 85
read-only permission 91
H
hardware and software requrements 38
high availability (HA) pair
configuring grid master 282
configuring independent 231
defined 30
deploying indpendent 245
forcing failover 263
grid members 289
monitoring status 164
rebooting 151
Host Name Compliance Report
viewing 386
host names
defined 30
for DNS updates 547
restrictions 384
restrictions for shared record groups 414
host records
adding 387
bulk 389
converting from dynamic lease 566
converting to fixed addresses 566
host name restrictions 384
HTTP
configuring 608
redirecting to HTTPS 130
restricting access to appliance 129
uploading files 610
HTTPS
defined 47
I
ICMP echo requests
ping 490
icons
detailed status 160
device status 160
distribution and upgrade status 324
LCD 162
memory usage 162
replication 163
service status 160
import zone data 359
independent appliances
configuring 231
HA pair, deployment scenario 36
Infoblox-1552
power supply status 162
Infoblox-2000 153
power supply status 162
RAID status 163
IP Address Management panel
IPAM
advanced find 578
classifying devices 558
classifying host records 388
DHCP lease event log 575
importing and exporting 579
lease event details 578
logging member 575
searching data 572
searching DHCP lease event log 577
viewing DHCP lease details 574
viewing IPAM data 571
watermarks 567570
IPAM WinConnect
configuring 644
monitoring 646
IPv6
AAAA records 395
configuring DNS 347
DNS views 343
reverse-mapping zone 355
J
Java sandbox 40
Java Web Start
Java Application Cache Viewer 41
join networks 462
K
Keystone license 31
L
LAN address
defined 31
LCD
configure network settings 234
disabling 130
status 162
LDAP authentication
configuring 625
licenses
activating 149
Keystone 31
managing 148
removing 149, 152
local admins 101
logging in
creating a banner 54
login options 45
using Java Web Start 39
using the Grid Manager 44
login banner 54
logs
audit log 170
DHCP 575
DHCP and DNS data 262
DHCP logs 498
RADIUS accounting log 634
replication 172
syslog 165
traffic capture 173
loopback interface
captive portal IP address 590
configuring IP addresses 450
M
MAC address filters
admin permission to apply to DHCP range 94
configuring 503505
using in NAC Foundation module 583
memory usage status 162
MGMT port
IP address 31
RADIUS auth for admins 105
static routes 146
using 136
MIBs
SNMP 177
MTU
for VPN tunnels 308
Index
MX records
adding 397
N
name server groups 376378
NAS
configuring 632
NAT
configuration example 241
NAT groups 271
Network discovery 519
configuring 525
managing discovered data 531
viewing discovered data 529
networks
configuring and managing 461
permission to assign members 82
shared 466
using templates 471
viewing statistics 517
NIOS appliance 31
rebooting 151
resetting 151
restricting HTTP access 129
shutting down 151
NIOS GUI
cache settings 46
customizing columns 54
detailed status 160
exporting data 60
features 50
printing 56
setting page size 101
setting timeout 130
NIOS software
downgrading 220
reverting 221
upgrade a grid 313
upgrading 220
upgrading independent appliances 265
NIOS virtual appliance 31
nodes
defined 31
NTP
adding an authentication key 124
appliance as client 122
appliance as NTP server 125
authenticating 120
monitoring status 118, 161
using for appliances 119
O
online help 52
OSPF
configuring 454
P
PAP 618
passwords
default 25
length for admins 113
PEAP 618
Perl 666
permissions
defining for AAA 98
defining for admin groups 74
defining for DHCP 90
defining for DNS 83
defining for TFTP, HTTP, and FTP services 100
for grid members 82
perspectives
customizing 53
defined 51
ports
Ethernet and service ports 132135
MGMT 136
primary servers
configuring 349
name server group 376
stealth 350
printing from NIOS GUI 56
PTR records
adding 396
PXE lease time
configuring 491
R
RADIUS
adding local users 620
anthentication admins 104
authentication methods 618
configuring 633
configuring authentication server 596
configuring policy rules 630
enable accounting 634
policy groups 631
proxy services 635642
specifying attributes 630
using policies 628
view configuration file 640
RAID
Infoblox-2000 153
rebooting 151
recycle bin
DNS 382
in the grid 310
restoring data 363
restoring DHCP objects 481
regular expressions 693
relay agent filters 511
remote admins
authenticating 102
authenticating using Active Directory 110
authenticating using RADIUS 104
creating admin groups for 112
remote console access
enabling and disabling 128
replication status 163
viewing 163, 172
resource records
adding 394
bulk host records 389
defining permissions 85, 87
host records 387
shared record groups 393
specifying TTL 407
restore objects 311
RFC 2317 355
root name servers 430
root zone 358
S
search
global 55
secondary servers
configuring 350
forwarding updates 554
name server group 376
notifying external 425
self-service portal 593
service configuration
defined 31
service status 160
shared networks 466
shared record groups 393, 412
shutting down 151
SNMP 175218
configuring 217
enable threshold crossing event trap 569
Infoblox MIBs 177
VitalQIP 661
SOA records
stub zone 373
zone settings 435
software and hardware requirements 38
software distribution 315
monitoring 324
SPF records 399
split networks 462
SRV records 398
SSH
remote console access 128
restrict access to MGMT port 140
SSL
certificates 4749
for admin authentication 111
LDAP authentication 625
overview 47
tunnel 39, 44
Startup Wizard
HA grid master 282
independent appliance 236
indpendent HA pair 247
single grid master 285
static routes
configuring 144
stub zones 368
subzones 356
syslog 165169
system time
monitoring 118
setiing date and time 117
T
technical support 25
download support bundle 227
enabling and disabling access 128
restrict access to MGMT port 140
TFTP
backup file 222
configuring 607
uploading files 610
time zone
distribution schedule 316
for grid and members 117
setting for local admins 101
upgrade schedule 320
timeout, setting 130
traffic capture tool 173
TSIG
DDNS updates 555
zone transfers 427
TTL
setting for DNS 424
setting for zones 434
TTL for resource records 407
TXT records 399
U
upgrade groups
creating and managing 314
upgrade status 324
upgrade test 319
upgrading a grid 313
user class filters 510
user name 25
V
variables 22
views
See DNS views
VIP
defined 31
virtual router ID
defined 31
VitalQIP
enabling on a grid 653
monitoring 660
overview 648
uploading files 651
user exit files 652
W
WinConnect
See IPAM WinConnect
Index
Z
zones
configuring authoritative 353
configuring parameters 434
defined 31
delegated 365
enabling transfers 426
forward 366
importing data 242, 359
locking and unlocking 379
modifying 380
name server groups 378
read/write permission 82
removing 380
restoring data 363
root zone 358
shared record groups 393, 415
statistics 447
stub 368
subzones 356
transfers 362, 436

NIOS AdminGuide 4.3r1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NIOS AdminGuide 4.3r1

Uploaded by

Copyright:

Available Formats

Infoblox Administrator Guide

View DHCP ranges

(provided with Windows

Adding Zones to a View

Adding Records to a Zone

Whether or not recursive queries are allowed

servers using a key from a Kerberos

refers to this type of

IP address management software. You can easily deploy NIOS

You might also like