Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
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
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. RE: relay "via" (Friesen, Don CITZ:EX)
2. Re: relay "via" (Marki)
3. Problem with Cisco phones (Marki)
4. Re: Problem with Cisco phones (Marki)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Mar 2023 13:17:54 +0000
From: "Friesen, Don CITZ:EX" <don.frie...@gov.bc.ca>
To: dhcp-users <dhcp-users@lists.isc.org>
Subject: RE: relay "via"
Message-ID:
<yt3pr01mb96103aae9f357e8511014c8dac...@yt3pr01mb9610.canprd01.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
When you see the name of the interface, that means the packet was a unicast
packet addressed by the client directly to the DHCP server, and not a broadcast
that was relayed.
Don Friesen
-----Original Message-----
From: dhcp-users <dhcp-users-boun...@lists.isc.org> On Behalf Of Marki
Sent: March 23, 2023 2:15 AM
To: dhcp-users <dhcp-users@lists.isc.org>
Subject: relay "via"
[EXTERNAL] This email came from an external source. Only open attachments or
links that you are expecting from a known sender.
Hello,
I would like to understand what the part behind "via" is exactly tryingn to
tell me in this case.
Why is it once showing "vlan50" (the interface of the DHCP server
itself) and another time "172.17.8.1" (which is the actual DHCP relay of the
device in question).
There is no way the device is sending dhcp requests directly from "vlan50",
i.e. from the network directly attached to the dhcp server.
2023-03-23T09:30:46.722240+01:00 dns01 dhcpd: DHCPREQUEST for
172.17.8.11 from xx:yy:zz:d9:11:57 (string) via vlan50
2023-03-23T09:30:46.722256+01:00 dns01 dhcpd: DHCPACK on 172.17.8.11 to
xx:yy:zz:d9:11:57 (string) via vlan50
2023-03-23T09:31:18.788021+01:00 dns01 dhcpd: DHCPREQUEST for
172.17.8.11 from xx:yy:zz:d9:11:57 (string) via 172.17.8.1
2023-03-23T09:31:18.788037+01:00 dns01 dhcpd: DHCPACK on 172.17.8.11 to
xx:yy:zz:d9:11:57 (string) via 172.17.8.1
Thanks
Marki
--
ISC funds the development of this software with paid support subscriptions.
Contact us at
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2F&data=05%7C01%7Cdon.friesen%40gov.bc.ca%7Cdaa3742b79034420d63008db2b7f2a07%7C6fdb52003d0d4a8ab036d3685e359adc%7C0%7C0%7C638151597397968199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZHbEE3djLRrimNTchpaiRC%2BY8Ed7iNF5CbXYqy3arVk%3D&reserved=0
for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fdhcp-users&data=05%7C01%7Cdon.friesen%40gov.bc.ca%7Cdaa3742b79034420d63008db2b7f2a07%7C6fdb52003d0d4a8ab036d3685e359adc%7C0%7C0%7C638151597397968199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yMhv1sUyXRWuylv7PUl6q0lI6kzqAwhoGApfUyOhiZM%3D&reserved=0
------------------------------
Message: 2
Date: Thu, 23 Mar 2023 15:34:49 +0100
From: Marki <dhcp-us...@lists.roth.lu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: relay "via"
Message-ID: <ee951358f67aa5501f0131dc2cd90...@roth.lu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Okay, it shows the interface name when giaddr is not set (normally at
REQUEST/ACK stage at 1/2 lease time when no more broadcasts are used).
Or when there is no DHCP relay at all.
Otherwise it shows the contents of giaddr.
The actual problem (for anyone who stumbles across this thread and its
symptoms) was a bad failover configuration.
A lot of devices were doing broadcasts all the time at REQUEST/ACK stage
even without a DISCOVER/OFFER happening first.
For some reason they were not sure about which DHCP server was the
authoritative one I guess...
On 2023-03-23 11:19, Darren Ankney wrote:
> Hi Marki,
>
> When it ends with via <some IP> it means the traffic was relayed by a
> relay agent. When it ends with via <some interface> then it means the
> traffic was directly unicast from the client (or there was no relay
> necessary because the client is attached directly to the local
> network).
>
> Thanks,
>
> -Darren
>
> On Thu, Mar 23, 2023 at 5:15?AM Marki <dhcp-us...@lists.roth.lu> wrote:
>>
>> Hello,
>>
>> I would like to understand what the part behind "via" is exactly
>> tryingn
>> to tell me in this case.
>>
>> Why is it once showing "vlan50" (the interface of the DHCP server
>> itself) and another time "172.17.8.1" (which is the actual DHCP relay
>> of
>> the device in question).
>> There is no way the device is sending dhcp requests directly from
>> "vlan50", i.e. from the network directly attached to the dhcp server.
>>
>> 2023-03-23T09:30:46.722240+01:00 dns01 dhcpd: DHCPREQUEST for
>> 172.17.8.11 from xx:yy:zz:d9:11:57 (string) via vlan50
>> 2023-03-23T09:30:46.722256+01:00 dns01 dhcpd: DHCPACK on 172.17.8.11
>> to
>> xx:yy:zz:d9:11:57 (string) via vlan50
>> 2023-03-23T09:31:18.788021+01:00 dns01 dhcpd: DHCPREQUEST for
>> 172.17.8.11 from xx:yy:zz:d9:11:57 (string) via 172.17.8.1
>> 2023-03-23T09:31:18.788037+01:00 dns01 dhcpd: DHCPACK on 172.17.8.11
>> to
>> xx:yy:zz:d9:11:57 (string) via 172.17.8.1
>>
>> Thanks
>> Marki
>> --
>> 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
>> dhcp-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Fri, 24 Mar 2023 09:23:57 +0100
From: Marki <dhcp-us...@lists.roth.lu>
To: dhcp-users@lists.isc.org
Subject: Problem with Cisco phones
Message-ID: <26f18b92f8698e570378acbe860f1...@lists.roth.lu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hello,
I know this is probably not an ISC DHCPD issue per se, but anyway, maybe
it rings a bell with someone.
I have a very frustrating issue here with Cisco IP Phones 8800 series.
Some of them are doing REQUEST/ACK multiple times per minute. They are
doing it as a broadcast, not unicast, hence the relay IP is shown.
2023-03-24T08:53:35.946166+01:00 d01 dhcpd: DHCPREQUEST for 172.17.8.11
from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
2023-03-24T08:53:35.946183+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
2023-03-24T08:53:43.938781+01:00 d01 dhcpd: DHCPREQUEST for 172.17.8.11
from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
2023-03-24T08:53:43.938798+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
2023-03-24T08:54:03.943809+01:00 d01 dhcpd: DHCPREQUEST for 172.17.8.11
from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
2023-03-24T08:54:03.943828+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
Some are even switching between broadcast and unicast:
2023-03-24T08:13:21.774638+01:00 d01 dhcpd: DHCPREQUEST for 172.17.8.31
from xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1
2023-03-24T08:13:21.774658+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to
xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1
-- nothing in between --
2023-03-24T09:12:03.817128+01:00 d01 dhcpd: DHCPREQUEST for 172.17.8.31
from xx:yy:zz:d1:9d:11 (SEP) via vlan50
2023-03-24T09:12:03.817151+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to
xx:yy:zz:d1:9d:11 (SEP) via vlan50
Sometimes they are totally stuck for like half an hour. First they
DISCOVER all the time, but don't issue a REQUEST after the OFFER until
some time has passed.
Power cycling does not help. I have yet to lay hand on a specimen in
order to totally reset it.
This could have started with failover not having been configured
correctly between the two dhcp servers, i.e. both servers handing out
addresses for dynamic pools.
Anyone got an idea?
Thanks
Marki
------------------------------
Message: 4
Date: Fri, 24 Mar 2023 09:51:34 +0100
From: Marki <dhcp-us...@lists.roth.lu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Problem with Cisco phones
Message-ID: <a847067111e4802c920500356b1bb...@lists.roth.lu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Oh and here is another weird transaction, not even a Cisco phone.
d01 is supposed to be the primary, and d02 the secondary.
split is 255, i.e. secondary should not do anything.
DHCP server 1 & 2 messages sorted by time
2023-03-24T03:56:46.758683+01:00 d01 dhcpd: DHCPDISCOVER from
xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:46.758753+01:00 d02 dhcpd: DHCPDISCOVER from
xx:yy:zz:f4:b6:86 via 172.17.64.1: load balance to peer failover-partner
2023-03-24T03:56:47.758851+01:00 d01 dhcpd: DHCPOFFER on 172.17.64.103
to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:52.791256+01:00 d01 dhcpd: DHCPDISCOVER from
xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:52.791344+01:00 d02 dhcpd: DHCPDISCOVER from
xx:yy:zz:f4:b6:86 via 172.17.64.1
2023-03-24T03:56:53.791508+01:00 d02 dhcpd: DHCPOFFER on 172.17.64.103
to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:53.791879+01:00 d01 dhcpd: DHCPOFFER on 172.17.64.103
to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:53.831406+01:00 d01 dhcpd: DHCPREQUEST for
172.17.64.103 (172.31.2.25) from xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:53.831423+01:00 d01 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:53.869917+01:00 d02 dhcpd: DHCPREQUEST for
172.17.64.103 (172.31.2.25) from xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T03:56:53.869938+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
2023-03-24T04:49:42.214570+01:00 d02 dhcpd: DHCPREQUEST for
172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T04:49:42.214590+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T05:49:44.534495+01:00 d02 dhcpd: DHCPREQUEST for
172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T05:49:44.534516+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T06:49:46.849370+01:00 d02 dhcpd: DHCPREQUEST for
172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T06:49:46.849390+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T07:49:49.149788+01:00 d02 dhcpd: DHCPREQUEST for
172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T07:49:49.149808+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T08:49:51.466691+01:00 d02 dhcpd: DHCPREQUEST for
172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
2023-03-24T08:49:51.466711+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to
xx:yy:zz:f4:b6:86 (x) via vlan50
On 2023-03-24 09:23, Marki wrote:
> Hello,
>
> I know this is probably not an ISC DHCPD issue per se, but anyway,
> maybe it rings a bell with someone.
>
> I have a very frustrating issue here with Cisco IP Phones 8800 series.
>
> Some of them are doing REQUEST/ACK multiple times per minute. They are
> doing it as a broadcast, not unicast, hence the relay IP is shown.
>
> 2023-03-24T08:53:35.946166+01:00 d01 dhcpd: DHCPREQUEST for
> 172.17.8.11 from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
> 2023-03-24T08:53:35.946183+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
> xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>
> 2023-03-24T08:53:43.938781+01:00 d01 dhcpd: DHCPREQUEST for
> 172.17.8.11 from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
> 2023-03-24T08:53:43.938798+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
> xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>
> 2023-03-24T08:54:03.943809+01:00 d01 dhcpd: DHCPREQUEST for
> 172.17.8.11 from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
> 2023-03-24T08:54:03.943828+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
> xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>
> Some are even switching between broadcast and unicast:
>
> 2023-03-24T08:13:21.774638+01:00 d01 dhcpd: DHCPREQUEST for
> 172.17.8.31 from xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1
> 2023-03-24T08:13:21.774658+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to
> xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1
> -- nothing in between --
> 2023-03-24T09:12:03.817128+01:00 d01 dhcpd: DHCPREQUEST for
> 172.17.8.31 from xx:yy:zz:d1:9d:11 (SEP) via vlan50
> 2023-03-24T09:12:03.817151+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to
> xx:yy:zz:d1:9d:11 (SEP) via vlan50
>
> Sometimes they are totally stuck for like half an hour. First they
> DISCOVER all the time, but don't issue a REQUEST after the OFFER until
> some time has passed.
>
> Power cycling does not help. I have yet to lay hand on a specimen in
> order to totally reset it.
>
> This could have started with failover not having been configured
> correctly between the two dhcp servers, i.e. both servers handing out
> addresses for dynamic pools.
>
> Anyone got an idea?
>
> Thanks
> Marki
------------------------------
Subject: Digest Footer
_______________________________________________
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
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 172, Issue 5
******************************************
