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 (Brennan,Andrew)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 Sep 2019 18:22:35 +0000
From: "Brennan,Andrew" <andrew.bren...@drexel.edu>
To: Greg Sloop <gr...@sloop.net>, Users of ISC DHCP
<dhcp-users@lists.isc.org>
Subject: Re: Esoteric question
Message-ID: <103446b6-73c9-4b58-8eac-d223c7184...@drexel.edu>
Content-Type: text/plain; charset="utf-8"
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<mailto: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
>> 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
>> 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]
>> 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<mailto: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<mailto: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<mailto: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/fe0aa4af/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 13
*******************************************
