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: Esoteric question (Greg Sloop <gr...@sloop.net>)
2. Re: Esoteric question (Attila Szalay)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 Sep 2019 12:02:04 -0700
From: "Greg Sloop <gr...@sloop.net>" <gr...@sloop.net>
To: "Brennan,Andrew" <andrew.bren...@drexel.edu>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Esoteric question
Message-ID:
<CAAjorqVzARMdvmXaSEADXf_d2CuSqkmF0A3zrBq=baus-qu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It's not possible to instruct the dhcp server [on edgerouter] which
interfaces to listen on - it appears to based on the subnet declaration
which interfaces it will respond on.
That said - I *can* have eth1 "active" and have no problem - say just
plugging it into a switch or something. The problem ONLY occurs [at least
in any situation I've been able to test] when it's connected to the CC
modem. It doesn't occur when Eth1 is live but not connected to that
equipment. [But still configured the same.]
On Sep 17, 2019 11:23 AM, "Brennan,Andrew" <andrew.bren...@drexel.edu>
wrote:
Maybe explicitly configure the Eth0 interface in the DHCP server
configuration (or startup CLI) so that Eth1 is never looked at by the DHCP
daemon? I think I have an EdgeRouter somewhere, but haven?t tried much
with it yet.
It does sound like the difference in behavior is somehow linked to both
interfaces being active - and the DHCP configuration shouldn?t even
acknowledge the Eth1 interface is active.
andrew.
On Sep 17, 2019, at 11:56 AM, Gregory Sloop <gr...@sloop.net> wrote:
External.
Top posting
I don't have captures on Eth1 - though that's probably a good idea. Hard
though, because it's a site that is in production like 7x12+ - so a PITA to
go onsite (for the fourth time now) to grab some more data...
The potential of an interface with an overlapping subnet on Eth1 was raised
and that's a good idea, I think.
But I certainly can't see anything in my config that would do that. I've
stripped the config down the the very basics; just, essentially, defining
the two Eth interfaces, the NAT/MASQ, DNS & NTP - in an effort to make sure
there wasn't something somewhere in the config that was inadvertently
causing the issue.
A Question, if anyone knows the answer.
If it's doing a full handshake on Eth0 currently, doesn't that indicate
that it believes that Eth0 is the proper interface for that subnet
declaration - and so, why would it also be doing it on another interface
too? [I get why it would be good to verify by doing some packet-caps - but
asking for my own knowledge/education.]
As for cloud-mgmt/call-home - no there's none of that.
Thanks for the thoughts so far.
-Greg
*gsuca> Hi Greg, gsuca> A very interesting problem... I've heard good
reports about both those gsuca> vendor's hardware, so sounds like a
reasonable choice. gsuca> What do you get if you snoop eth1 while connected
to the different WAN gsuca> devices? I wonder if dhcpd is trying to talk to
something else upstream gsuca> (no idea why it would do that). gsuca> Does
the Ubiquiti have some form of cloud management or call home setup? gsuca>
Best of luck. gsuca> regards, gsuca> -glenn gsuca> On 2019-09-17 09:20,
Gregory Sloop wrote: >> So, this is kind of a wild goose-chase for some
direction - but >> thought there might be some useful answers here. >> [But
I know it's way out there and I'm not going to get direct help on >>
solving the issue on the platform I'm having issues with - just bear >>
with me and see if you have any helpful ideas.] >> Let me set the
background. >> I'm using specific device hardware - in this case, a
Mikrotik RB450G >> [currently in place] and moving to a Ubiquiti EdgeRouter
lite. >> They're multi-ethernet interface routers - based on Linux. >> The
RB450G works fine and simply needs replacement. [The two devices >> are
configured as identically as I can. They're very different, so >> we're
talking "functionally" identical, not literally with the same >> conf
files.] >> I'm having issues with DHCPd on the new device. [And queries at
>> Ubiquiti are going nowhere fast. It IS an unusual problem, so I'm not >>
terribly surprised.] >> Lets assume Eth0/LAN is 10.0.0.1/24
<http://10.0.0.1/24> >> DHCPD is setup to hand out addresses for
10.0.0.20-100, say. >> 14440 second leases. >> Clients are connected
directly to a switch that's directly connected >> to ETH0. [No DHCP relay
etc.] >> Eth1/WAN is a static /30 - connected directly to a Comcast
Modem/BSG. >> Lets say 1.2.3.5/30 <http://1.2.3.5/30> >> The gateway [not
that it matters is 1.2.3.6] >> We're masquerading traffic [NAT] from the
local RFC1918 [10.0.0.0/24 <http://10.0.0.0/24>] >> network to the static
public IP on the WAN. >> --- >> So, here's what happens/happened. >> I went
in to swap out the 'Tik box for the new hardware. >> Plug it in, and none
of the clients on the LAN get DHCP addresses. All >> the DHCP clients time
out. >> After several passes at testing here's what I find. >> I can't find
any configuration problems on the replacement hardware. >> The *old* 'Tik
hardware/software works perfectly. >> If we have the WAN connected to a
simple live ethernet port on the >> *new hardware,* [EdgeRouter] DHCP works
fine for the LAN side. Totally >> fine. >> Only when we plug in the Comcast
gateway/modem into the WAN port on >> the new hardware does DHCP
fail/timeout. [Remember just plugging it >> into a regular ethernet switch
works fine. It won't pass traffic, >> because the static IP assignment
isn't right - but the LAN side DHCP >> server works perfectly.] >> If we
take a client on the LAN and plug in a static IP [rather than >> DHCP],
traffic flows out to the internet perfectly fine. >> Packet caps from the
new router show that the router/DHCP server IS >> seeing all the DHCP
protocol handshake. [When it's having the >> "problem."] >> The client does
a DISCOVER >> Server responds with OFFER >> The client responds with
REQUEST >> Then there's a LONG pause. [like 90s+ worth.] >> The Server
responds with ACK. [It actually appears to send several >> ACKS. I probably
cut my captures too short, so I only have about 2m of >> capture in my
largest one. But that's what I see in what I have.] >> However, the client
[Windows in this case] has timed out, and never >> gets the ACK. >> And
while I'm not 100% certain, the times I've looked, the device >> believes
it's handed out a lease. [I believe it's in the leases file.] >> But
because of the long delay, the client never actually got the >> lease. >>
Again, >> -simply unplugging the Comcast modem from the router, and DHCP >>
immediately starts working again. >> -Plugging Eth1 into a live ethernet
port [so that interface is seen as >> up] also works fine. >> -It's only
when connected to the Comcast gateway/modem that it fails. >> On the LAN
side of the network, we've tinkered replacing the switches >> - dumb,
identically configured managed switches, different manged >> switch, or no
switch at all - simply plugged directly into a single >> client. No changes
on the LAN side make the slightest difference >> either. >> Since we're
doing NAT/MASQ from LAN->WAN no WAN traffic should leak >> into the LAN -
but I've also explicitly defined rules that prevent >> anything from the
WAN getting to the LOCAL or LAN interfaces - other >> than
established/related traffic. >> So, I'm not asking for you to solve the
issue on this particular >> hardware. What I'm asking for is some plausible
explanation that might >> have these symptoms. I'm completely at wits end.
I've spent a lot of >> hours trying a whole host of troubleshooting things
- but I can't >> think of any possible way this could be happening. But
clearly it is. >> IMO, either we have some very weird hardware physical
layer problem >> that only impacts DHCP [and not traffic routing] or
there's something >> I'm missing. I'd normally imagine that I'm missing
something - but >> can't figure out what, if anything. >> I've tried to
closely define the setup, but I'm sure I've forgotten >> something -
perhaps lots of somethings - just ask and I'll try to >> clarify any
missing pieces. >> Given how awesome people on this list are, I'm hopeful
someone will >> have something that might jiggle loose something useful! >>
TIA >> -Greg >> _______________________________________________ >>
dhcp-users mailing list *>> dhcp-users@lists.isc.org
<dhcp-users@lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/dhcp-users
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fdhcp-users&data=02%7C01%7Candrew.brennan%40drexel.edu%7C3faaf27c6cc04500f9ce08d73b87ac49%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C0%7C637043326257120851&sdata=zoQc7C6zWDGsvdUTdr4wVtWw8QlewE4A5l%2FN%2BB2p6po%3D&reserved=0>
*-- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice:
503.251.0452 x82 EMail: *gr...@sloop.net
http://www.sloop.net
<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sloop.net&data=02%7C01%7Candrew.brennan%40drexel.edu%7C3faaf27c6cc04500f9ce08d73b87ac49%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C0%7C637043326257130843&sdata=4Znxfo8KfpIzAPokd%2FsImV82tRBm1qE9QW%2FIabG0czE%3D&reserved=0>
*---*
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fdhcp-users&data=02%7C01%7Candrew.brennan%40drexel.edu%7C3faaf27c6cc04500f9ce08d73b87ac49%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C0%7C637043326257150822&sdata=WdFqlEa8uKMN%2B4MSHrQsdpa00m2ivE7kRSZQTmC8ucc%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190917/c069ac54/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 18 Sep 2019 12:00:10 +0200
From: Attila Szalay <moch...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Esoteric question
Message-ID:
<CAN0VciZeF8D3q7bGxYTVErujTy5ok-+zqyTOG8TT=9f-wv7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have a similar setup with different MicroTic routers but haven't
experienced things like this.
I think, what should be helpful to solve this issue is a config dump, a
(the more the merrier) packet capture (all interfaces, all port, all
protocol) and you can also raise the log level related to the dhcp process
too.
On Tue, Sep 17, 2019 at 9:02 PM Greg Sloop <gr...@sloop.net> <
gr...@sloop.net> wrote:
> It's not possible to instruct the dhcp server [on edgerouter] which
> interfaces to listen on - it appears to based on the subnet declaration
> which interfaces it will respond on.
>
> That said - I *can* have eth1 "active" and have no problem - say just
> plugging it into a switch or something. The problem ONLY occurs [at least
> in any situation I've been able to test] when it's connected to the CC
> modem. It doesn't occur when Eth1 is live but not connected to that
> equipment. [But still configured the same.]
>
>
> On Sep 17, 2019 11:23 AM, "Brennan,Andrew" <andrew.bren...@drexel.edu>
> wrote:
>
> Maybe explicitly configure the Eth0 interface in the DHCP server
> configuration (or startup CLI) so that Eth1 is never looked at by the DHCP
> daemon? I think I have an EdgeRouter somewhere, but haven?t tried much
> with it yet.
>
> It does sound like the difference in behavior is somehow linked to both
> interfaces being active - and the DHCP configuration shouldn?t even
> acknowledge the Eth1 interface is active.
>
> andrew.
>
> On Sep 17, 2019, at 11:56 AM, Gregory Sloop <gr...@sloop.net> wrote:
>
> External.
> Top posting
>
> I don't have captures on Eth1 - though that's probably a good idea. Hard
> though, because it's a site that is in production like 7x12+ - so a PITA to
> go onsite (for the fourth time now) to grab some more data...
>
> The potential of an interface with an overlapping subnet on Eth1 was
> raised and that's a good idea, I think.
> But I certainly can't see anything in my config that would do that. I've
> stripped the config down the the very basics; just, essentially, defining
> the two Eth interfaces, the NAT/MASQ, DNS & NTP - in an effort to make sure
> there wasn't something somewhere in the config that was inadvertently
> causing the issue.
>
> A Question, if anyone knows the answer.
> If it's doing a full handshake on Eth0 currently, doesn't that indicate
> that it believes that Eth0 is the proper interface for that subnet
> declaration - and so, why would it also be doing it on another interface
> too? [I get why it would be good to verify by doing some packet-caps - but
> asking for my own knowledge/education.]
>
> As for cloud-mgmt/call-home - no there's none of that.
>
> Thanks for the thoughts so far.
>
> -Greg
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *gsuca> Hi Greg, gsuca> A very interesting problem... I've heard good
> reports about both those gsuca> vendor's hardware, so sounds like a
> reasonable choice. gsuca> What do you get if you snoop eth1 while connected
> to the different WAN gsuca> devices? I wonder if dhcpd is trying to talk to
> something else upstream gsuca> (no idea why it would do that). gsuca> Does
> the Ubiquiti have some form of cloud management or call home setup? gsuca>
> Best of luck. gsuca> regards, gsuca> -glenn gsuca> On 2019-09-17 09:20,
> Gregory Sloop wrote: >> So, this is kind of a wild goose-chase for some
> direction - but >> thought there might be some useful answers here. >> [But
> I know it's way out there and I'm not going to get direct help on >>
> solving the issue on the platform I'm having issues with - just bear >>
> with me and see if you have any helpful ideas.] >> Let me set the
> background. >> I'm using specific device hardware - in this case, a
> Mikrotik RB450G >> [currently in place] and moving to a Ubiquiti EdgeRouter
> lite. >> They're multi-ethernet interface routers - based on Linux. >> The
> RB450G works fine and simply needs replacement. [The two devices >> are
> configured as identically as I can. They're very different, so >> we're
> talking "functionally" identical, not literally with the same >> conf
> files.] >> I'm having issues with DHCPd on the new device. [And queries at
> >> Ubiquiti are going nowhere fast. It IS an unusual problem, so I'm not >>
> terribly surprised.] >> Lets assume Eth0/LAN is 10.0.0.1/24
> <http://10.0.0.1/24> >> DHCPD is setup to hand out addresses for
> 10.0.0.20-100, say. >> 14440 second leases. >> Clients are connected
> directly to a switch that's directly connected >> to ETH0. [No DHCP relay
> etc.] >> Eth1/WAN is a static /30 - connected directly to a Comcast
> Modem/BSG. >> Lets say 1.2.3.5/30 <http://1.2.3.5/30> >> The gateway [not
> that it matters is 1.2.3.6] >> We're masquerading traffic [NAT] from the
> local RFC1918 [10.0.0.0/24 <http://10.0.0.0/24>] >> network to the static
> public IP on the WAN. >> --- >> So, here's what happens/happened. >> I went
> in to swap out the 'Tik box for the new hardware. >> Plug it in, and none
> of the clients on the LAN get DHCP addresses. All >> the DHCP clients time
> out. >> After several passes at testing here's what I find. >> I can't find
> any configuration problems on the replacement hardware. >> The *old* 'Tik
> hardware/software works perfectly. >> If we have the WAN connected to a
> simple live ethernet port on the >> *new hardware,* [EdgeRouter] DHCP works
> fine for the LAN side. Totally >> fine. >> Only when we plug in the Comcast
> gateway/modem into the WAN port on >> the new hardware does DHCP
> fail/timeout. [Remember just plugging it >> into a regular ethernet switch
> works fine. It won't pass traffic, >> because the static IP assignment
> isn't right - but the LAN side DHCP >> server works perfectly.] >> If we
> take a client on the LAN and plug in a static IP [rather than >> DHCP],
> traffic flows out to the internet perfectly fine. >> Packet caps from the
> new router show that the router/DHCP server IS >> seeing all the DHCP
> protocol handshake. [When it's having the >> "problem."] >> The client does
> a DISCOVER >> Server responds with OFFER >> The client responds with
> REQUEST >> Then there's a LONG pause. [like 90s+ worth.] >> The Server
> responds with ACK. [It actually appears to send several >> ACKS. I probably
> cut my captures too short, so I only have about 2m of >> capture in my
> largest one. But that's what I see in what I have.] >> However, the client
> [Windows in this case] has timed out, and never >> gets the ACK. >> And
> while I'm not 100% certain, the times I've looked, the device >> believes
> it's handed out a lease. [I believe it's in the leases file.] >> But
> because of the long delay, the client never actually got the >> lease. >>
> Again, >> -simply unplugging the Comcast modem from the router, and DHCP >>
> immediately starts working again. >> -Plugging Eth1 into a live ethernet
> port [so that interface is seen as >> up] also works fine. >> -It's only
> when connected to the Comcast gateway/modem that it fails. >> On the LAN
> side of the network, we've tinkered replacing the switches >> - dumb,
> identically configured managed switches, different manged >> switch, or no
> switch at all - simply plugged directly into a single >> client. No changes
> on the LAN side make the slightest difference >> either. >> Since we're
> doing NAT/MASQ from LAN->WAN no WAN traffic should leak >> into the LAN -
> but I've also explicitly defined rules that prevent >> anything from the
> WAN getting to the LOCAL or LAN interfaces - other >> than
> established/related traffic. >> So, I'm not asking for you to solve the
> issue on this particular >> hardware. What I'm asking for is some plausible
> explanation that might >> have these symptoms. I'm completely at wits end.
> I've spent a lot of >> hours trying a whole host of troubleshooting things
> - but I can't >> think of any possible way this could be happening. But
> clearly it is. >> IMO, either we have some very weird hardware physical
> layer problem >> that only impacts DHCP [and not traffic routing] or
> there's something >> I'm missing. I'd normally imagine that I'm missing
> something - but >> can't figure out what, if anything. >> I've tried to
> closely define the setup, but I'm sure I've forgotten >> something -
> perhaps lots of somethings - just ask and I'll try to >> clarify any
> missing pieces. >> Given how awesome people on this list are, I'm hopeful
> someone will >> have something that might jiggle loose something useful! >>
> TIA >> -Greg >> _______________________________________________ >>
> dhcp-users mailing list *>> dhcp-users@lists.isc.org
> <dhcp-users@lists.isc.org>
> >> https://lists.isc.org/mailman/listinfo/dhcp-users
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fdhcp-users&data=02%7C01%7Candrew.brennan%40drexel.edu%7C3faaf27c6cc04500f9ce08d73b87ac49%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C0%7C637043326257120851&sdata=zoQc7C6zWDGsvdUTdr4wVtWw8QlewE4A5l%2FN%2BB2p6po%3D&reserved=0>
>
>
>
>
> *-- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice:
> 503.251.0452 x82 EMail: *gr...@sloop.net
> http://www.sloop.net
> <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sloop.net&data=02%7C01%7Candrew.brennan%40drexel.edu%7C3faaf27c6cc04500f9ce08d73b87ac49%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C0%7C637043326257130843&sdata=4Znxfo8KfpIzAPokd%2FsImV82tRBm1qE9QW%2FIabG0czE%3D&reserved=0>
> *---*
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fdhcp-users&data=02%7C01%7Candrew.brennan%40drexel.edu%7C3faaf27c6cc04500f9ce08d73b87ac49%7C3664e6fa47bd45a696708c4f080f8ca6%7C0%7C0%7C637043326257150822&sdata=WdFqlEa8uKMN%2B4MSHrQsdpa00m2ivE7kRSZQTmC8ucc%3D&reserved=0
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190918/274ed1df/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 131, Issue 14
*******************************************
