Wednesday, July 23, 2008

UCM 6.1 DHCP Server

One of the first problems I came across when playing with CallManager 6.1  was what to do in regards to the DHCP server.   Luckily Cisco have provided a "simple" integrated DHCP server.  Simple? yes it is somewhat lacking in flexibility and worse still would be  impossible to use in any sort of enterprise environment.  There are no tools to see assigned addresses, no way to configure static assignments and debugging errors are a bit of a nightmare.

So how does the DHCP service on CUCM 6.1 fit together?

The DHCP service is configured via the Cisco Unified CM Administration Web page.  There are two sub menu options:

The first configures the DHCP server itself



The second configures the DHCP subnet (this is the equivalent to a scope in the Microsoft world)

As can be seen a number of fields appear on both the server wide  configuration page, or they can be overwritten on a per subnet level.  Most of the fields are fairly self explanatory, the last four fields are concerned with DHCP timeouts:

ARP Cache Timeout:

IP Address Lease Timeout:

Renewal(T1) Time: 
T1 is the time at which the client enters the RENEWING state and attempts to contact the server.
 
Rebinding(T2) Time: 
T2 is the time at which the client enters the REBINDING state and attempts to contact any server.

T1 MUST be earlier than T2, which MUST be earlier than the time at which the client's lease will expire, it should also be noted that according to the dhcpd-option man page. the Renewal and Rebinding timings are not user settable, so I am unsure as to what there actual impact is - if you do set a value here it is not reflected in the generated dhcpd.conf file.

Once entered the fields are inserted into the CCM database into two tables, DhcpServer, and DhcpSubnet.  

in this example a DHCP server has been configured on a CCM with an ip address of 192.168.28.100

select * from DhcpServer;

pkid   fkprocessnode    domainnameserver1 domainnameserver2 tftpserver1    tftpserver2 nextserver domainname     arpcachetimeout ipaddrleasetime t1 t2 tftpservername 
====   =============    ================= ================= ============== =========== ========== ============== =============== =============== == == ============== 
xxxx   xxxx-xxxxxxxx                                        192.168.28.100                        ciscolab.local 0               0               0  0    

select * from DhcpSubnet;
             
pkid   fkdhcpserver  subnet       ipaddrfrom1   ipaddrfrom2 ipaddrto1     ipaddrto2 router1      router2 subnetmask    domainname     arpcachetimeout domainnameserver1 domainnameserver2 tftpserver1 tftpserver2 ipaddrleasetime nextserver t1   t2  tftpservername 
====   ============  ============ ============= =========== ============= ========= ============ ======= ============= ============== =============== ================= ================= =========== =========== ============    ========== ==== === ============== 
xxxx xxxx-xxxxxxxxxx 192.168.29.0 192.168.29.10             192.168.29.30           192.168.29.1         255.255.255.0 ciscolab.local 0                 

At this point the DHCP Monitor service will be triggered, the DHCP service itself is the standard dhcp daemon (v3.01)  that is included with  Redhat.  The DHCP Monitor service will read the tables form the database write the dhcpd.conf file located at /etc/dhcpd.conf, and reset  dhcpd.  

The dhcpd.conf file written is shown below.

#more /etc/dhcpd.conf
ddns-update-style ad-hoc;
option tftp-server-address code 150 = array of ip-address;
option domain-name "ciscolab.local";
option tftp-server-address 192.168.28.100;
next-server 0.0.0.0;

subnet 192.168.28.0 netmask 255.255.255.0 {
}
subnet 192.168.29.0 netmask 255.255.255.0 {
    range 192.168.29.10 192.168.29.30;
    option routers 192.168.29.1;
    option domain-name "ciscolab.local";
    option arp-cache-timeout 800;
    default-lease-time 36400;
}

As mentioned earlier, there are no simple ways to see leased addresses.  This does make it difficult to fault find and use.  Debugging log information is available via RTMT, however they do take some working through to see what is happening.


No comments: