ISC DHCP Users

dhcp relay responses

Classic

List

Threaded

12 messages Options

Alan Batie

dhcp relay responses

We are setting up a private network with dhcp. The router for the
private network is setup to relay dhcp to an external isc dhcpd server.
The requests to the dhcpd server come from the public address of the
router, however dhcpd is replying to the private address. I don't see
anything in the docs for managing the replies. We are trying to avoid
routing the private network even internally. Are we out of luck?

dhcp01 router
1.1.1.1 - 2.2.2.2 10.1.1.1

request 2.2.2.2 -> 1.1.1.1
reply 1.1.1.1 -> 10.1.1.1

I do see in the request:

Relay agent IP address: 10.47.87.1 (10.47.87.1)

However this is the only information that can be used to determine which
pool of addresses the dhcp server should assign leases from, so I don't
see that changing that would be workable.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

smime.p7s (5K) Download Attachment

glenn.satchell

Re: dhcp relay responses

Hi Alan,

Yeah, you're out of luck. The initial broadcast can be relayed through a
NAT, but for ACKs and REQUESTs the dhcp server communicates directly
with the client dhcp client device.

regards,
-glenn

On 2020-01-31 10:33, Alan Batie wrote:

> We are setting up a private network with dhcp. The router for the
> private network is setup to relay dhcp to an external isc dhcpd server.
> The requests to the dhcpd server come from the public address of the
> router, however dhcpd is replying to the private address. I don't see
> anything in the docs for managing the replies. We are trying to avoid
> routing the private network even internally. Are we out of luck?
>
>
> dhcp01 router
> 1.1.1.1 - 2.2.2.2 10.1.1.1
>
> request 2.2.2.2 -> 1.1.1.1
> reply 1.1.1.1 -> 10.1.1.1
>
> I do see in the request:
>
> Relay agent IP address: 10.47.87.1 (10.47.87.1)
>
> However this is the only information that can be used to determine
> which
> pool of addresses the dhcp server should assign leases from, so I don't
> see that changing that would be workable.
>
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Simon Hobson

Re: dhcp relay responses

In reply to this post by Alan Batie

Alan Batie <[hidden email]> wrote:
>We are setting up a private network with dhcp. The router for the
>private network is setup to relay dhcp to an external isc dhcpd server.
>The requests to the dhcpd server come from the public address of the
>router, however dhcpd is replying to the private address. I don't see
>anything in the docs for managing the replies. We are trying to avoid
>routing the private network even internally. Are we out of luck?

Short answer: yes

Longer answer:
There must be end to end IP connectivity between clients and server - without "broken" things like NAT in the way. Even if you worked around the problem with the relay, you'd find clients having problems later when they unicast a renewal request to the server and it unicasts a response directly to the client.

As to why the responses are sent to to private address of the relay ... That's because the server uses the GI Addr field in the relayed packet - firstly to select an appropriate address pool, and secondly to determine whete the response needs to be returned to. Thecrelay agent would then use the destination address of the packet to determine which locally connected interface to send the response out on.

So if the server can't receive & send packets from/to both the relay agent and clients directly - DHCP won't work.
Up to you whether you relicate the server, tunnel packets to/from it, or something else ...

Simon
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Alan Batie

Re: dhcp relay responses

OK, thanks!

On 1/30/20 11:26 PM, Simon Hobson wrote:

> Alan Batie <[hidden email]> wrote:
>> We are setting up a private network with dhcp. The router for the
>> private network is setup to relay dhcp to an external isc dhcpd server.
>> The requests to the dhcpd server come from the public address of the
>> router, however dhcpd is replying to the private address. I don't see
>> anything in the docs for managing the replies. We are trying to avoid
>> routing the private network even internally. Are we out of luck?
>
> Short answer: yes
>
> Longer answer:
> There must be end to end IP connectivity between clients and server - without "broken" things like NAT in the way. Even if you worked around the problem with the relay, you'd find clients having problems later when they unicast a renewal request to the server and it unicasts a response directly to the client.
>
> As to why the responses are sent to to private address of the relay ... That's because the server uses the GI Addr field in the relayed packet - firstly to select an appropriate address pool, and secondly to determine whete the response needs to be returned to. Thecrelay agent would then use the destination address of the packet to determine which locally connected interface to send the response out on.
>
> So if the server can't receive & send packets from/to both the relay agent and clients directly - DHCP won't work.
> Up to you whether you relicate the server, tunnel packets to/from it, or something else ...
>
> Simon
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

smime.p7s (5K) Download Attachment

Alan Batie

dhcp relay

I'm trying to setup dhcp relay and not sure how the server determines
the network to assign an address from? The agent device (a Calix E7)
requires that the uplink vlan be different from the client vlan, so the
agent address is the uplink address of the device (which doesn't have an
address on the client vlan anyhow as it's mostly a switch):

Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xa217414b
Seconds elapsed: 21935
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 172.20.44.15 (172.20.44.15)
Client MAC address: 48:77:46:f9:5b:b0 (48:77:46:f9:5b:b0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type
Length: 1
DHCP: Discover (1)
Option: (57) Maximum DHCP Message Size
Length: 2
Maximum DHCP Message Size: 576
Option: (55) Parameter Request List
Length: 11
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (12) Host Name
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (42) Network Time Protocol Servers
Parameter Request List Item: (43) Vendor-Specific Information
Parameter Request List Item: (120) SIP Servers
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (125) V-I Vendor-specific Information
Option: (60) Vendor class identifier
Length: 24
Vendor class identifier: GS4220E.ONT.dslforum.org
Option: (82) Agent Information Option
Length: 96
Option 82 Suboption: (1) Agent Circuit ID
Length: 58
Agent Circuit ID:
73706172652d65372d312e696e7472616e65742e7065616b...
Option 82 Suboption: (2) Agent Remote ID
Length: 34
Agent Remote ID:
73706172652d65372d312e696e7472616e65742e7065616b...
Option: (255) End
Option End: 255
Padding

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Patrick Trapp

Re: dhcp relay

Hello, Alan. I am using a similar configuration here, including E7 devices. We use shared networks to identify the subnet that network devices that the end devices are attached to occupy.

Our network devices get their addresses via another system, but it would also work if we assigned them via this same DHCP server or if they were set statically.

For example, our pools are set up similar to this - note the empty braces {} because we don't define the network in this system:

shared-network new-network {

# 192.168.1.0/24 Network device management range

subnet 192.168.1.0 netmask 255.255.255.0 {}

# 10.10.10.0/23 End device network

subnet 10.10.10.0 netmask 255.255.254.0 {

option routers 10.10.10.1;

option broadcast-address 10.10.11.255;

pool {

failover peer "failover";

deny dynamic bootp clients;

range 10.10.10.11 10.10.10.254;

} # close pool

} # close shared-network

Hope that helps.

From: dhcp-users <[hidden email]> on behalf of Alan Batie <[hidden email]>
Sent: Wednesday, November 25, 2020 8:54 PM
To: [hidden email] <[hidden email]>
Subject: dhcp relay

CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I'm trying to setup dhcp relay and not sure how the server determines
the network to assign an address from? The agent device (a Calix E7)
requires that the uplink vlan be different from the client vlan, so the
agent address is the uplink address of the device (which doesn't have an
address on the client vlan anyhow as it's mostly a switch):

Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xa217414b
    Seconds elapsed: 21935
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 172.20.44.15 (172.20.44.15)
    Client MAC address: 48:77:46:f9:5b:b0 (48:77:46:f9:5b:b0)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type
        Length: 1
        DHCP: Discover (1)
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 576
    Option: (55) Parameter Request List
        Length: 11
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (12) Host Name
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (28) Broadcast Address
        Parameter Request List Item: (42) Network Time Protocol Servers
        Parameter Request List Item: (43) Vendor-Specific Information
        Parameter Request List Item: (120) SIP Servers
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (125) V-I Vendor-specific Information
    Option: (60) Vendor class identifier
        Length: 24
        Vendor class identifier: GS4220E.ONT.dslforum.org
    Option: (82) Agent Information Option
        Length: 96
        Option 82 Suboption: (1) Agent Circuit ID
            Length: 58
            Agent Circuit ID:
73706172652d65372d312e696e7472616e65742e7065616b...
        Option 82 Suboption: (2) Agent Remote ID
            Length: 34
            Agent Remote ID:
73706172652d65372d312e696e7472616e65742e7065616b...
    Option: (255) End
        Option End: 255
    Padding

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Alan Batie

Re: dhcp relay

On 11/27/20 6:59 AM, Patrick Trapp wrote:
> Hello, Alan. I am using a similar configuration here, including E7
> devices. We use shared networks to identify the subnet that network
> devices that the end devices are attached to occupy.

We're setup for a vlan/slot so I need to be able to distinguish between
the two vlans; it looks like I'm going to have to use the option82 info
somehow to do this...

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Patrick Trapp

Re: dhcp relay

We do, also. I was trying to avoid dropping a lot of unnecessary info on you. We use class definitions based on the parameters our network guys give me. For example,

WARNING: This has not been tested, it's a production config obfuscated, so I may have dropped some punctuation accidently - but hopefully you will see something in the structure that will aid you.

-----------------------------------------------------------------

class "Endpoint-devices"

{ match if

(substring (option agent.circult_id, 0, 4) = "TOWN")

and not

(suffix (option agent.circuit-id,5) = "vlan7")

}

class "Gateway-devices"

{ match if

(substring (option agent.circult_id, 0, 4) = "TOWN")

and

(suffix (option agent.circuit-id,5) = "vlan7")

}

-----------------------------------------------------------------

shared-network TOWN_A_Endpoints {

# 192.168.1.0/24 Town Network Infrastructure

subnet 192.168.1.0 netmask 255.255.255.0 {}

# 10.10.100.0/22 Town Endpoints Network

subnet 10.10.100.0 netmask 255.255.252.0 {

option routers 10.10.100.1;

option broadcast-address 10.10.103.255;

pool { # Production endpoints

failover peer "failover";

deny dynamic bootp clients;

allow members of "Endpoint-devices";

range 10.10.100.30 10.10.103.254;

} # Close production endpoints pool

pool { # Test endpoints hanging directly off E7

failover peer "failover";

deny dynamic bootp clients;

deny members of "Endpoint-devices";

deny members of "Gateway-devices";

range 10.10.100.10 10.10.100.29;

default-lease-time 21600;

min-lease-time 21600;

max-lease-time 43200;

} #Close test endpoints pool

} # Close endpoints subnet

# 172.16.1.1/23 Town Residential Gateways

subnet 172.16.1.0 netmask 255.255.254.0 {

option broadcast-address 172.16.1.255;

pool { # Gateway-devices pool

failover peer "failover";

deny dynamic bootp clients;

allow members of "Gateway-devices";

range 172.16.1.10 172.16.1.254;

} # Close Gateway-devices pool

} # Close gateways subnet

} # Close shared-network

-----------------------------------------------------------------

Cheers!

From: dhcp-users <[hidden email]> on behalf of Alan Batie <[hidden email]>
Sent: Monday, November 30, 2020 1:56 PM
To: [hidden email] <[hidden email]>
Subject: Re: dhcp relay

CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On 11/27/20 6:59 AM, Patrick Trapp wrote:
> Hello, Alan. I am using a similar configuration here, including E7
> devices. We use shared networks to identify the subnet that network
> devices that the end devices are attached to occupy.

We're setup for a vlan/slot so I need to be able to distinguish between
the two vlans; it looks like I'm going to have to use the option82 info
somehow to do this...

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Alan Batie

Re: dhcp relay

On 11/30/20 12:55 PM, Patrick Trapp wrote:
> We do, also. I was trying to avoid dropping a lot of unnecessary info on
> you. We use class definitions based on the parameters our network guys
> give me. For example,

That gives me a direction, thanks!

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Patrick Trapp

Re: dhcp relay

Glad to hear it - what you are doing sounds a lot like what we have here. I rarely have anything meaningful to contribute here, so it's cool to see someone with a question I can answer!

From: dhcp-users <[hidden email]> on behalf of Alan Batie <[hidden email]>
Sent: Monday, November 30, 2020 3:49 PM
To: [hidden email] <[hidden email]>
Subject: Re: dhcp relay

CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On 11/30/20 12:55 PM, Patrick Trapp wrote:
> We do, also. I was trying to avoid dropping a lot of unnecessary info on
> you. We use class definitions based on the parameters our network guys
> give me. For example,

That gives me a direction, thanks!

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Alan Batie

Re: dhcp relay

In reply to this post by Patrick Trapp

On 11/30/20 12:55 PM, Patrick Trapp wrote:
> We do, also. I was trying to avoid dropping a lot of unnecessary info on
> you. We use class definitions based on the parameters our network guys
> give me. For example,

Are you doing IPv6? Apparently dhcpd6 doesn't support class definitions
(or something else I tried to do either, but I've forgotten what that
was ;-) ). It seems to be unloved...

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Patrick Trapp

Re: dhcp relay

Ah, we are not. Strictly IPv4 here. I have no insight to share on that topic, I'm afraid.

From: dhcp-users <[hidden email]> on behalf of Alan Batie <[hidden email]>
Sent: Monday, November 30, 2020 8:32 PM
To: [hidden email] <[hidden email]>
Subject: Re: dhcp relay

CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On 11/30/20 12:55 PM, Patrick Trapp wrote:
> We do, also. I was trying to avoid dropping a lot of unnecessary info on
> you. We use class definitions based on the parameters our network guys
> give me. For example,

Are you doing IPv6? Apparently dhcpd6 doesn't support class definitions
(or something else I tried to do either, but I've forgotten what that
was ;-) ). It seems to be unloved...

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users