Send dhcp-users mailing list submissions to
[email protected]
Advertising
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. forwarding DHCP packets via a router. (Rajeev Bansal)
2. Re: forwarding DHCP packets via a router. (Gero Palacio)
3. No Option 43 in DHCP ACK (Jason Bailey)
4. Re: No Option 43 in DHCP ACK (Steven Carr)
5. Re: forwarding DHCP packets via a router. (Simon Hobson)
6. Re: No Option 43 in DHCP ACK (Maarten Carels)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Jul 2015 22:45:51 +0530
From: Rajeev Bansal <[email protected]>
To: [email protected]
Subject: forwarding DHCP packets via a router.
Message-ID:
<CALpSCk-dB3Cnpxh94d_jq2=_hj6vn8yjf7-c5ddo2mmy30o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi ,
I have a specific requirement, where I would like to forward a dhcp
discover/request/renew/release packets from a client via a router to
another subnet. I can't use a dhcrelay for this purpose, because in my
scenario both interface of my router (client side and dhcp server side)
will not have IPv4 address assigned. Yes that means, I am trying to forward
the dhcp packets to different link without my client knowing that it is
communicating over different Ethernet link.
For example, lets say my router has eth0 and eth1 two interface and there
is a laptop connected to eth0 and there is server running on the LAN on
which eth1 is connected. Now I want to forward my client's dhcp requests
from eth0 to eth1 and response from eth1 to eth0 seamlessly. Please note
eth0 and eth1 both doesn't have any IP address assigned.
I don't think dhcrelay will fit in my requirement, can someone suggest some
way to do that.
Thanks,
-Rajeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20150713/c67ad858/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 13 Jul 2015 14:36:04 -0300
From: Gero Palacio <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: forwarding DHCP packets via a router.
Message-ID:
<cafpzj9nq0oomm5c3eotruxkd5pk3iudeqakirmzso9quvy6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi there,
I think you can use a bridge to accomplish what you're looking for. If I
understand correctly, you have 2 different LAN segments (one on each
router's interface) and you need the client's interface connected to the
DHCP server interface as it was in the same LAN. You can do that using a
bridge.
You should keep in mind your network topology though and if it's what you
want for your network.. I'm just think in the simplest scenario were you
have CLIENT <-> ROUTER <-> SERVER.
Hope this helps!
On Mon, Jul 13, 2015 at 2:15 PM, Rajeev Bansal <[email protected]>
wrote:
> Hi ,
>
> I have a specific requirement, where I would like to forward a dhcp
> discover/request/renew/release packets from a client via a router to
> another subnet. I can't use a dhcrelay for this purpose, because in my
> scenario both interface of my router (client side and dhcp server side)
> will not have IPv4 address assigned. Yes that means, I am trying to forward
> the dhcp packets to different link without my client knowing that it is
> communicating over different Ethernet link.
>
> For example, lets say my router has eth0 and eth1 two interface and there
> is a laptop connected to eth0 and there is server running on the LAN on
> which eth1 is connected. Now I want to forward my client's dhcp requests
> from eth0 to eth1 and response from eth1 to eth0 seamlessly. Please note
> eth0 and eth1 both doesn't have any IP address assigned.
>
> I don't think dhcrelay will fit in my requirement, can someone suggest
> some way to do that.
>
> Thanks,
> -Rajeev
>
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20150713/e9eda17c/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 13 Jul 2015 12:42:29 -0600
From: Jason Bailey <[email protected]>
To: <[email protected]>
Subject: No Option 43 in DHCP ACK
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; format=flowed
Hi all,
I'm trying to troubleshoot a problem with DHCP option 43. I've defined
the vendor option space and declared the vendor specific options per the
vendor's documentation, but I'm not getting any results.
The device (DHCP client) is sending options 53 (request), 60 (vendor
class ident), 61 (client identifier), 43 (vendor specific info) , 55
(parameter request list), among a few others. Option 55 includes 43
(vendor specific info) in addition to the usual items (like subnet mask,
router, etc). The server is sending an ACK, but it doesn't include any
of the option 43 items I've defined.
In my DHCP server config, I've defined "option space XYZ" and "option
XYZ.item code 1 = ip address". I've also configured defined
"vendor-option-space XYZ" and "option XYZ.item 1.2.3.4" inside the
subnet declaration (the entire subnet has been created entirely for the
same type of devices, so there's no need to match only a certain type of
devices (i.e. device class))
dhcpd -t doesn't complain about any issues in my config file, and there
are no issues in the log (I'm using 'log-facility local7').
I'm at a loss at the moment, so any help is greatly appreciated. I'm
running ISC DHCP 4.1.1 on CentOS 6.6.
Jason
------------------------------
Message: 4
Date: Mon, 13 Jul 2015 19:59:23 +0100
From: Steven Carr <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: No Option 43 in DHCP ACK
Message-ID:
<CALMep07v50Oxo4Cvc13vgRVhG0Mt_x=x+7x2OjUxB=zeq6d...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 13 July 2015 at 19:42, Jason Bailey <[email protected]> wrote:
> In my DHCP server config, I've defined "option space XYZ" and "option
> XYZ.item code 1 = ip address". I've also configured defined
> "vendor-option-space XYZ" and "option XYZ.item 1.2.3.4" inside the subnet
> declaration (the entire subnet has been created entirely for the same type
> of devices, so there's no need to match only a certain type of devices (i.e.
> device class))
AFAIK you still need a class, otherwise it's not going to match and
send the custom option space back to the client.
------------------------------
Message: 5
Date: Mon, 13 Jul 2015 20:37:21 +0100
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: forwarding DHCP packets via a router.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Rajeev Bansal <[email protected]> wrote:
> I have a specific requirement, where I would like to forward a dhcp
> discover/request/renew/release packets from a client via a router to another
> subnet. I can't use a dhcrelay for this purpose, because in my scenario both
> interface of my router (client side and dhcp server side) will not have IPv4
> address assigned. Yes that means, I am trying to forward the dhcp packets to
> different link without my client knowing that it is communicating over
> different Ethernet link.
Can you clarify things a bit more ? Is there IPv4 connectivity between client
and server ? If not then it won't work.
A few details that come to mind ...
Firstly, the relay agent does *not* have to be in a router, it can be any
device on the same network segment (broadcast domain) as the client. So you can
put a relay agent on any convenient system.
Both client and relay agent must have IPv4 connectivity to the server. It
doesn't matter how (could be VPN, 4 in 6 tunnel, ...), but they need to be able
to exchange unicast packets.
For the ISC relay agent, there is a restriction (due to historical design
decisions) that all interfaces used by the relay agent must be broadcast
capable (in practical terms, look like an ethernet interface). This also
applies to the server unless you compile without raw sockets support - which
would mean it couldn't handle clients on the directly attached network.
I don't know if a 4 in 6 tunnel (with an endpoint on the relay agent/server
machine) will work for this.
------------------------------
Message: 6
Date: Tue, 14 Jul 2015 09:56:36 +0200
From: Maarten Carels <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: No Option 43 in DHCP ACK
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> On 13 Jul 2015, at 20:42 , Jason Bailey <[email protected]> wrote:
>
> Hi all,
>
> I'm trying to troubleshoot a problem with DHCP option 43. I've defined the
> vendor option space and declared the vendor specific options per the vendor's
> documentation, but I'm not getting any results.
>
> The device (DHCP client) is sending options 53 (request), 60 (vendor class
> ident), 61 (client identifier), 43 (vendor specific info) , 55 (parameter
> request list), among a few others. Option 55 includes 43 (vendor specific
> info) in addition to the usual items (like subnet mask, router, etc). The
> server is sending an ACK, but it doesn't include any of the option 43 items
> I've defined.
>
> In my DHCP server config, I've defined "option space XYZ" and "option
> XYZ.item code 1 = ip address". I've also configured defined
> "vendor-option-space XYZ" and "option XYZ.item 1.2.3.4" inside the subnet
> declaration (the entire subnet has been created entirely for the same type of
> devices, so there's no need to match only a certain type of devices (i.e.
> device class))
>
> dhcpd -t doesn't complain about any issues in my config file, and there are
> no issues in the log (I'm using 'log-facility local7').
>
> I'm at a loss at the moment, so any help is greatly appreciated. I'm running
> ISC DHCP 4.1.1 on CentOS 6.6.
I guess this is for the cisco wireless stuff.
I use this:
option space Cisco_LWAPP_AP;
option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
subnet 192.168.31.96 netmask 255.255.255.224 {
option routers 192.168.31.97;
vendor-option-space Cisco_LWAPP_AP;
option Cisco_LWAPP_AP.server-address 192.168.31.250;
pool {
failover peer "kantoor-draadloos";
# most fixed
range 192.168.31.118 192.168.31.119;
}
}
Works for me (Internet Systems Consortium DHCP Server 4.3.1 on Debian 7.8)
?maarten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 526 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20150714/fc0f4110/attachment-0001.bin>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 81, Issue 13
******************************************
