Posts tagged DHCP

Infoblox API Perl Modules

0
November 9, 2011
by Michael McNamara in

We recently migrated from Alcatel-Lucent’s VitalQIP to Infoblox for our IPAM (IP Address Management) solution. I hope to make a more detailed post reviewing Infoblox in the future, for now I’ll stick with the issue of integrating with the API interface. One of our goals for the past few years has been to enable MAC address registration essentially turning off the dynamic nature of DHCP. This would prevent someone from connecting any device to our internal network and getting a DHCP issued IP address. It certainly not a complete solution to the security dilemmas but it would be a good first step.

I do most of my work with CentOS and RedHat Linux because those are the distributions that my organization supports internally (even if I’m one of two people that support Linux across the entire organization). In this case I was working with a CentOS 5.7 server but I was having an issue compiling and installing the Infoblox Perl modules.

LWP::UserAgent version 5.813 required–this is only version 2.033

When I attempted to compile the Infoblox Perl modules I received the following errors;

LWP::UserAgent version 5.813 required--this is only version 2.033 at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Agent.pm line 3.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Agent.pm line 3.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Session.pm line 19.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Session.pm line 19.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Infoblox.pm line 8.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Infoblox.pm line 8.
Compilation failed in require at ./ibcli.pl line 78.
BEGIN failed--compilation aborted at ./ibcli.pl line 78.

This was with Perl 5.8.8 on CentOS 5.7 x64, unfortunately it seems this is a known issue with the version of LWP::UserAgent that is currently being distributed via the CentOS repository.

I was able to spin up a new CentOS 6.0 x86 server which was running Perl 5.10.1 and didn’t experience this problem.

The installation was pretty straight forward (except for the issue above) but the API reference manual does a very thorough job of detailing all the possible installation methods on both Windows and Unix/Linux. I just opened a browser to one of the Infoblox appliances and downloaded the Perl modules.

https://10.1.1.1/api/dist/CPAN/authors/id/INFOBLOX/

Just replace the IP address of 10.1.1. with the IP address of your Infoblox appliance. I’m not sure why Infoblox hides their manuals behind their support portal, I just don’t understand why companies do that.  You can find the manual right here, Infoblox_API_Documentation_6.1.0.pdf.

Cheers!

ISC DHCP Configuration for Avaya IP Phones

1
February 17, 2011
by Michael McNamara in ,

This is an update to a fairly old post I made a few years back now providing an example dhcpd.conf configuration file for use in an Avaya (formerly Nortel) IP telephony environment. I was recently working on a few things and discovered that the Avaya IP phones ignore the next-server option within my dhcpd.conf file. A few tests and I quickly found that I needed to define the tftp-server-name option with the IP address of the TFTP server (see the global section of the dhcpd.conf file below).

If time allows I hope to post an update in the very near future covering the new Nortel-i2004-B option string. While working with the SIP 4.0 software release in the past few articles I did learn that the Avaya SIP IP phones can utilize a new DHCP vendor class, Nortel-SIP-Phone-A which can allow you a little flexibility when configuring them via DHCP and TFTP.

In the same file below I setup four DHCP scopes; one for 2111/2212/6020/6040 wireless handsets, one for i2002/i2004/1100/1200 series IP phones, one for 1100/1200 series IP phones running SIP and one for all other devices (laptops, desktops, etc). Just a quick note about the example below, you’ll notice that I have no pools in the 192.168.1.0/24 network. All the pools are in the 192.168.25.0/24 network.

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
# Sample dhcpd.conf file for Avaya (legacy Nortel) IP Phones
#
# Notes: example dhcpd.conf file to illustrate how to configure Avaya
# IP Phones with specific DHCP options for 2000/1100/1200 series IP
# Phones and the 2200/6100 series Wireless IP Phones.
#
# *** WARNING *** WARNING *** WARNING *** WARNING ** WARNING ***
#
# This is just an sample file with specific IP information. You'll
# need to customize this file to your specific IP address scheme
# before you can use it in your environment.
#
# *** WARNING *** WARNING *** WARNING *** WARNING ** WARNING ***
#

ddns-update-style none;
not authoritative;

option nortel-callserver code 128 = string;
option nortel-2245 code 151 = ip-address;
option tftp-server-name "192.168.1.20";

# Vendor Class for i2002/i2004/1120e/1140e/1150e Internet Telephones
class "Nortel-i2004-A" {
  match if substring (option vendor-class-identifier, 0, 14) = "Nortel-i2004-A";
    option nortel-callserver "Nortel-i2004-A,192.168.200.2:4100,1,5;192.168.200.2:4100,1,5.";
    option vendor-class-identifier "Nortel-i2004-A";
}

# Vendor Class for 2210/2211 Wireless Phones
class "Nortel-221x-A" {
  match if substring(option vendor-class-identifier, 0, 13) = "Nortel-221x-A";
    option nortel-callserver "Nortel-i2004-A,192.168.200.2:4100,1,5:192.168.200.2:4100,1,5.";
    option nortel-2245 192.168.99.10;
    option vendor-class-identifier "Nortel-221x-A";
}

# Vendor Class for Avaya 1100/1200 IP SIP Phones (SIP firmware loaded)
class "Nortel-SIP-Phone-A" {
  match if substring(option vendor-class-identifier, 0, 18) = "Nortel-SIP-Phone-A";
    option vendor-class-identifier "Nortel-SIP-Phone-A";
}

# Network Definition
shared-network "mynetwork" {
   subnet 192.168.1.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option routers 192.168.1.1;
   option domain-name "home";
   option domain-name-servers 192.168.0.1;
   next-server 192.168.1.20;
   default-lease-time 28800;
   max-lease-time 86400;
   }
}

# Network Definition 192.168.25.0/24
shared-network "192-168-25-0" {
   subnet 192.168.25.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option routers 192.168.25.1;
   option domain-name "home";
   option domain-name-servers 192.168.1.1;
   next-server 192.168.1.20;
   default-lease-time 28800;
   max-lease-time 86400;

   # IP Address Pool for generic devices
   pool {
      range 192.168.25.50 192.168.25.100;
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
      deny members of "Nortel-SIP-Phone-A";
   }

   # IP Address Pool for i2002/i2004/1120e/1140e/1150e
   pool {
      range 192.168.25.150 192.168.25.175;
      allow members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
      deny members of "Nortel-SIP-Phone-A";
   }

   # IP Address Pool for 2210/2211
   pool {
      range 192.168.25.176 192.168.25.199;
      allow members of "Nortel-221x-A";
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-SIP-Phone-A";
      }

   # IP Address Pool for Avaya 1100/1200 IP SIP Phones
   pool {
      range 192.168.25.200 192.168.25.224;
      allow members of "Nortel-SIP-Phone-A";
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
      }

 }
}

Cheers!

DHCP/BOOTP Relay with Juniper SRX Gateways

0
September 12, 2010
by Michael McNamara in

I’ve recently started deploying the Juniper SRX series gateways, placing an SRX 210 at branch office locations with an SRX 650 at the main office locations. We utilize a central DHCP/DNS/IPAM solution so we prefer to relay all DHCP/BOOTP requests to one of our centralized DHCP/DNS servers as opposed to utilizing the DHCP server functionality built into the SRX itself.

I had to spend more than a few minutes trying to get the DHCP relay working on the SRX 210. The configuration was pretty straight forward, the trick in the end was the “vpn” statement (see below) that allows the DHCP/BOOTP packets to be relayed across a VPN tunnel. Please note that the DHCP server at 10.1.1.1 is accessible via the VPN tunnel.

forwarding-options {
 helpers {
  bootp {
   relay-agent-option;
   description "Branch DHCP Relay";
   server 10.1.1.1;
   maximum-hop-count 10;
   minimum-wait-time 1;
   vpn;
   interface {
    vlan.0;
   }
  }
 }
}

The next big step will be deploying OSPF between all the SRX gateways.

Cheers!

Go to Top