From: Tim Fletcher (groupstudy@fletchmail.net)
Date: Mon Jun 14 2004 - 00:10:33 GMT-3
John,
You might want to take a look at the ISC DHCP server (http://www.isc.org/).
-Tim Fletcher
At 04:44 PM 6/12/2004, John Underhill wrote:
>The address ranges are stacked one on the other 1918/192.168.x.0.. I tried
>using the database command, but it only logs successful leases, nothing
>more, and upon failure of one node, the secondary only overwrites the file,
>(what is the point of that? ..are you going to manually rebind all those
>addresses?) ..and because of the way dhcp works, -(first reply -then- lowest
>server address), requests from the secondary server are always rejected.. So
>I guess either forego redundancy, or create the /23.. I'll keep thinking on
>it for now..
>Thanks
>
>----- Original Message -----
>From: "Kenneth Wygand" <KWygand@customonline.com>
>To: <stepnwlf@magma.ca>; <ccielab@groupstudy.com>
>Sent: Saturday, June 12, 2004 4:07 PM
>Subject: Re: DHCP Failover
>
>
>> Hey John,
>>
>> Yes, I agree with not readdressing the network - when I said "lend itself
>nicely to a /23 conversion", I meant, for example, do you have the next
>highest class-C range available for each class-C range you have assigned (if
>the IP scheme was designed with this level of expansion in mind). If so, a
>/24 --> /23 conversion would be as simple as updating a few subnet masks in
>a few places.
>>
>> Ken
>> --------------------------
>> Sent from my BlackBerry Wireless Handheld
>>
>>
>> -----Original Message-----
>> From: John Underhill <stepnwlf@magma.ca>
>> To: Kenneth Wygand <KWygand@customonline.com>; ccielab@groupstudy.com
><ccielab@groupstudy.com>
>> Sent: Sat Jun 12 14:33:58 2004
>> Subject: Re: DHCP Failover
>>
>> I don't even want to think about re-addressing the network, (I don't
>> particularly enjoy long talks with my manager..), with NAT operations,
>> routing, VPNs, and all the static addressing, it would be a lot of work,
>and
>> down time..
>> I think I will mock this up with a couple hosts and put a sniffer on the
>> wire to see how it works..
>> I'm sure I am not the only person who would like to see redundancy in a
>> design of this kind, and with wireless gaining ground on the LAN, secure
>> address assignments are becoming a real issue.. I'll let you know if it
>> works.
>>
>>
>>
>> ----- Original Message -----
>> From: "Kenneth Wygand" <KWygand@customonline.com>
>> To: <stepnwlf@magma.ca>; <ccielab@groupstudy.com>
>> Sent: Saturday, June 12, 2004 2:15 PM
>> Subject: Re: DHCP Failover
>>
>>
>> > John,
>> >
>> > Not sure about the solution you are recommending, but does your current
>IP
>> addressing scheme lends itself nicely to a /23 conversion?
>> >
>> > Ken
>> > --------------------------
>> > Sent from my BlackBerry Wireless Handheld
>> >
>> >
>> > -----Original Message-----
>> > From: John Underhill <stepnwlf@magma.ca>
>> > To: Kenneth Wygand <KWygand@customonline.com>; ccielab@groupstudy.com
>> <ccielab@groupstudy.com>
>> > Sent: Sat Jun 12 14:10:55 2004
>> > Subject: Re: DHCP Failover
>> >
>> > Unfortunately this doesn't scale very will on a /24 subnet.. What I mean
>> to
>> > do, is move away from centralized address management, and have access
>> > routers handle dhcp for the local fabric. Right now I am using an active
>> > cluster dhcp/dns solution, but for security reasons, (lease spoofing,
>> > particularly for wireless, and more restrictive traffic policies at
>access
>> > points..), I would like to go with a distributed solution. The only
>> problem
>> > is redundancy.. I was thinking of using HSRP to load share on redundant
>> > gateways, and splitting the scope between the two dhcp servers, each
>> > assigning different gateways.. the only problem is, there are 200+ nodes
>> on
>> > this segment, so if one of the DHCP servers goes down, a divided scope
>> will
>> > not have enough address space to service the network. So what I was
>> thinking
>> > was: could I log both dhcp servers to a central database on a server,
>let
>> > them both use the same scope, and maintain redundancy and the full
>address
>> > space, while avoiding address assignment conflicts. So the question
>> becomes,
>> > what does the 'ip dhcp database tftp://x.x.x.x/filename' do exactly? I
>am
>> > under the impression, that it stores mappings for recovery purposes, but
>> how
>> > dynamic is it? Do the servers simply write to the file, or do they do a
>> > lookup in the database before assigning an address? If it was the
>latter,
>> I
>> > could have both servers connected to the same database to avoid address
>> > conflicts, and load share the gateways.
>> >
>> >
>> > ----- Original Message -----
>> > From: "Kenneth Wygand" <KWygand@customonline.com>
>> > To: <stepnwlf@magma.ca>; <ccielab@groupstudy.com>
>> > Sent: Saturday, June 12, 2004 1:38 PM
>> > Subject: Re: DHCP Failover
>> >
>> >
>> > > John,
>> > >
>> > > Just set up two DHCP servers on the same segment but have each one
>lease
>> > out a non-overlapping subset of the dynamic IP addresses in that range.
>> This
>> > works perfectly. If you'd like, I can explain how this actually works
>> behind
>> > the scenes once I get to a real computer (on a blackberry right now).
>Let
>> me
>> > know and hope this helps.
>> > >
>> > > Ken
>> > > --------------------------
>> > > Sent from my BlackBerry Wireless Handheld
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: nobody@groupstudy.com <nobody@groupstudy.com>
>> > > To: ccielab@groupstudy.com <ccielab@groupstudy.com>
>> > > Sent: Sat Jun 12 12:52:42 2004
>> > > Subject: DHCP Failover
>> > >
>> > > I was wondering if by using the (ip dhcp database
>> tftp://x.x.x.x/filename,
>> > > maybe in conjunction with the update arp - secure dhcp..), could I
>> create
>> > > overlapping scopes, and use this for redundancy? This file will store
>> the
>> > > binding information, but I'm wondering if the dhcp servers consult
>this
>> > file
>> > > before leasing an address, or is it simply warehousing the binding
>> > > information.. Can someone think of some other way to create a
>> > > redundant/failover dhcp solution using ios dhcp?
>> > >
>> > >
>_______________________________________________________________________
>> > > Please help support GroupStudy by purchasing your study materials
>from:
>> > > http://shop.groupstudy.com
>> > >
>> > > Subscription information may be found at:
>> > > http://www.groupstudy.com/list/CCIELab.html
>> > >
>> > >
>_______________________________________________________________________
>> > > Please help support GroupStudy by purchasing your study materials
>from:
>> > > http://shop.groupstudy.com
>> > >
>> > > Subscription information may be found at:
>> > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:40 GMT-3