Assigning a different gateway address based on gi-addr

Glenn Satchell glenn.satchell at uniq.com.au
Sun Oct 31 09:07:16 UTC 2010


You don't ned the binary to ascii, this is functionally identical :

match if packet(24, 4) = 58:58:58:21 ;

Note the colons between characters, and the values must be in *hex*.

regards,
-glenn

On 10/30/10 12:52, Nicolas De Cristofaro wrote:
> Hi Simon,
>
> Many thanks for the suggestions. I realized there may have been some questions based on our solution so I should have outlined we were prepared to deal with that with those. Both routers are technically on separate path, and they would not both forward at the same time in any case.
>
> As for your configuration example: It did work!! However I still had to use the binary-to-ascii function, else it would not match...I used the log function to look at how the packet was being evaluated and it returned a weird string, so I guess it needed a conversion to ascii first to evaluate it?
>
> Thanks again
>
> Nick
>
>
>
> -----Original Message-----
> From: dhcp-users-bounces+nicolas.de.cristofaro=ericsson.com at lists.isc.org [mailto:dhcp-users-bounces+nicolas.de.cristofaro=ericsson.com at lists.isc.org] On Behalf Of Simon Hobson
> Sent: October-29-10 3:56 PM
> To: Users of ISC DHCP
> Subject: Re: Assigning a different gateway address based on gi-addr
>
> Nicolas De Cristofaro wrote:
>
>> We are attempting a configuration with our ISC DHCP server where we
>> would like to hand out a different gateway address based on the gi-addr
>> of the dhcp-relay set by our routers.
>>
>> Our solution includes two routers and one is acting as a standy-node
>> only, so subscribers would only connect via this node if the primary
>> node fail.
>
> I was just thinking VRRP (or HSRP for Cisco kit).
>
>> Our configuration does not allow us to use VRRP due to limitations with
>> the box
>
> Pity !
>
>> and we would like to use a different gateway address based on if the
>> subscribers connected via the primary dhcp-relay or the back
>> dhcp-relay.
>
> The first problem I see is that both routers will be relays, and both will forward requests if they are working. Thus, when both routers are working, the client will get offers with both gateways and it will be (mostly ?) random which they take - typically whichever router gets the offer to the server first will get the traffic as it's reply should be the first back to the client and most clients seem to accept the first valid offer they get.
>
> The second problem is that a router going down won't result in clients getting a new lease for anything up to (almost) 4 hours with the lease times you've specified. Thus a router going down will result in around half your clients losing connectivity for potentially several hours or until the user takes action to get a new lease.
>
> But assuming that's something you're prepared to deal with ...
>
>> We would like to share the same pool definition though, and this is
>> where we've ran into problems, we can't use the same 'range' in two
>> pools. So the idea would be to use one pool, but assign a different
>> 'options router' based on the class matching, is this possible?
>>
>> Here is what we have so far based on what I found already reading
>> through the mailing lists:
>>
>> subnet 88.88.88.32 netmask 255.255.255.240 {
>>
>>      default-lease-time 14400;
>>
>>      max-lease-time 14400;
>>
>>
>>
>>      class "NODE-1" {
>>
>>        match if binary-to-ascii(10, 8, ".", packet(24, 4)) =
>> "88.88.88.33";
>>
>>      }
>
> You don't need the binary to ascii, this is functionally identical :
> match if packet(24, 4) = 88.88.88.33 ;
>
> The 88:88:88:33 bit there just specifies a set of four bytes.
>
>
> How about just using a conditional like this :
>
> subnet 88.88.88.32 netmask 255.255.255.240 {
>      pool {
>        if packet(24, 4) = 88.88.88.33 {
>          option routers 88.88.88.33 ;
>        }
>        else
>        {
>          option routers 88.88.88.34 ;
>        }
>        range 88.88.88.35 88.88.88.45;
>      }
> }
> --
> Simon Hobson
>



More information about the dhcp-users mailing list