<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
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.
<div class=""><br class="">
</div>
<div class="">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.<br class="">
<div class=""><br class="">
</div>
<div class="">andrew.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Sep 17, 2019, at 11:56 AM, Gregory Sloop <<a href="mailto:gregs@sloop.net" class="">gregs@sloop.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<title class="">Re: Esoteric question</title>
<div class="">
<table width="100%" class="">
<tbody class="">
<tr class="">
<td style="border-left: 4px solid goldenrod; background: cornsilk; padding:0 3pt" class="">
<p style="font: small-caps bold 100% sans-serif" class="">External.</p>
</td>
</tr>
</tbody>
</table>
<div class=""><span style=" font-family:'Courier New'; font-size: 9pt;" class="">Top posting<br class="">
<br class="">
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...<br class="">
<br class="">
The potential of an interface with an overlapping subnet on Eth1 was raised and that's a good idea, I think.<br class="">
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.<br class="">
<br class="">
A Question, if anyone knows the answer.<br class="">
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.]<br class="">
<br class="">
As for cloud-mgmt/call-home - no there's none of that.<br class="">
<br class="">
Thanks for the thoughts so far.<br class="">
<br class="">
-Greg<br class="">
<br class="">
<span style=" color: #800000;" class=""><b class="">gsuca> Hi Greg,<br class="">
<br class="">
gsuca> A very interesting problem... I've heard good reports about both those<br class="">
gsuca> vendor's hardware, so sounds like a reasonable choice.<br class="">
<br class="">
gsuca> What do you get if you snoop eth1 while connected to the different WAN<br class="">
gsuca> devices? I wonder if dhcpd is trying to talk to something else upstream<br class="">
gsuca> (no idea why it would do that).<br class="">
<br class="">
gsuca> Does the Ubiquiti have some form of cloud management or call home setup?<br class="">
<br class="">
gsuca> Best of luck.<br class="">
<br class="">
gsuca> regards,<br class="">
gsuca> -glenn<br class="">
<br class="">
gsuca> On 2019-09-17 09:20, Gregory Sloop wrote:<br class="">
>> So, this is kind of a wild goose-chase for some direction - but<br class="">
>> thought there might be some useful answers here.<br class="">
<br class="">
>> [But I know it's way out there and I'm not going to get direct help on<br class="">
>> solving the issue on the platform I'm having issues with - just bear<br class="">
>> with me and see if you have any helpful ideas.]<br class="">
<br class="">
>> Let me set the background.<br class="">
<br class="">
>> I'm using specific device hardware - in this case, a Mikrotik RB450G<br class="">
>> [currently in place] and moving to a Ubiquiti EdgeRouter lite.<br class="">
>> They're multi-ethernet interface routers - based on Linux.<br class="">
>> The RB450G works fine and simply needs replacement. [The two devices<br class="">
>> are configured as identically as I can. They're very different, so<br class="">
>> we're talking "functionally" identical, not literally with the same<br class="">
>> conf files.]<br class="">
<br class="">
>> I'm having issues with DHCPd on the new device. [And queries at<br class="">
>> Ubiquiti are going nowhere fast. It IS an unusual problem, so I'm not<br class="">
>> terribly surprised.]<br class="">
<br class="">
>> Lets assume Eth0/LAN is 10.0.0.1/24<br class="">
>> DHCPD is setup to hand out addresses for 10.0.0.20-100, say.<br class="">
>> 14440 second leases.<br class="">
>> Clients are connected directly to a switch that's directly connected<br class="">
>> to ETH0. [No DHCP relay etc.]<br class="">
<br class="">
>> Eth1/WAN is a static /30 - connected directly to a Comcast Modem/BSG.<br class="">
>> Lets say 1.2.3.5/30<br class="">
>> The gateway [not that it matters is 1.2.3.6]<br class="">
<br class="">
>> We're masquerading traffic [NAT] from the local RFC1918 [10.0.0.0/24]<br class="">
>> network to the static public IP on the WAN.<br class="">
<br class="">
>> ---<br class="">
>> So, here's what happens/happened.<br class="">
<br class="">
>> I went in to swap out the 'Tik box for the new hardware.<br class="">
>> Plug it in, and none of the clients on the LAN get DHCP addresses. All<br class="">
>> the DHCP clients time out.<br class="">
>> After several passes at testing here's what I find.<br class="">
<br class="">
>> I can't find any configuration problems on the replacement hardware.<br class="">
>> The *old* 'Tik hardware/software works perfectly.<br class="">
<br class="">
>> If we have the WAN connected to a simple live ethernet port on the<br class="">
>> *new hardware,* [EdgeRouter] DHCP works fine for the LAN side. Totally<br class="">
>> fine.<br class="">
>> Only when we plug in the Comcast gateway/modem into the WAN port on<br class="">
>> the new hardware does DHCP fail/timeout. [Remember just plugging it<br class="">
>> into a regular ethernet switch works fine. It won't pass traffic,<br class="">
>> because the static IP assignment isn't right - but the LAN side DHCP<br class="">
>> server works perfectly.]<br class="">
<br class="">
>> If we take a client on the LAN and plug in a static IP [rather than<br class="">
>> DHCP], traffic flows out to the internet perfectly fine.<br class="">
<br class="">
>> Packet caps from the new router show that the router/DHCP server IS<br class="">
>> seeing all the DHCP protocol handshake. [When it's having the<br class="">
>> "problem."]<br class="">
>> The client does a DISCOVER<br class="">
>> Server responds with OFFER<br class="">
>> The client responds with REQUEST<br class="">
>> Then there's a LONG pause. [like 90s+ worth.]<br class="">
>> The Server responds with ACK. [It actually appears to send several<br class="">
>> ACKS. I probably cut my captures too short, so I only have about 2m of<br class="">
>> capture in my largest one. But that's what I see in what I have.]<br class="">
>> However, the client [Windows in this case] has timed out, and never<br class="">
>> gets the ACK.<br class="">
>> And while I'm not 100% certain, the times I've looked, the device<br class="">
>> believes it's handed out a lease. [I believe it's in the leases file.]<br class="">
>> But because of the long delay, the client never actually got the<br class="">
>> lease.<br class="">
<br class="">
>> Again,<br class="">
>> -simply unplugging the Comcast modem from the router, and DHCP<br class="">
>> immediately starts working again.<br class="">
>> -Plugging Eth1 into a live ethernet port [so that interface is seen as<br class="">
>> up] also works fine.<br class="">
>> -It's only when connected to the Comcast gateway/modem that it fails.<br class="">
<br class="">
>> On the LAN side of the network, we've tinkered replacing the switches<br class="">
>> - dumb, identically configured managed switches, different manged<br class="">
>> switch, or no switch at all - simply plugged directly into a single<br class="">
>> client. No changes on the LAN side make the slightest difference<br class="">
>> either.<br class="">
<br class="">
>> Since we're doing NAT/MASQ from LAN->WAN no WAN traffic should leak<br class="">
>> into the LAN - but I've also explicitly defined rules that prevent<br class="">
>> anything from the WAN getting to the LOCAL or LAN interfaces - other<br class="">
>> than established/related traffic.<br class="">
<br class="">
>> So, I'm not asking for you to solve the issue on this particular<br class="">
>> hardware. What I'm asking for is some plausible explanation that might<br class="">
>> have these symptoms. I'm completely at wits end. I've spent a lot of<br class="">
>> hours trying a whole host of troubleshooting things - but I can't<br class="">
>> think of any possible way this could be happening. But clearly it is.<br class="">
<br class="">
>> IMO, either we have some very weird hardware physical layer problem<br class="">
>> that only impacts DHCP [and not traffic routing] or there's something<br class="">
>> I'm missing. I'd normally imagine that I'm missing something - but<br class="">
>> can't figure out what, if anything.<br class="">
<br class="">
>> I've tried to closely define the setup, but I'm sure I've forgotten<br class="">
>> something - perhaps lots of somethings - just ask and I'll try to<br class="">
>> clarify any missing pieces.<br class="">
<br class="">
>> Given how awesome people on this list are, I'm hopeful someone will<br class="">
>> have something that might jiggle loose something useful!<br class="">
<br class="">
>> TIA<br class="">
>> -Greg<br class="">
>> _______________________________________________<br class="">
>> dhcp-users mailing list<br class="">
</b></span></span><a style=" font-family:'courier new'; font-size: 9pt;" href="mailto:dhcp-users@lists.isc.org" class="">>> dhcp-users@lists.isc.org</a><br class="">
<a style=" font-family:'courier new'; font-size: 9pt;" href="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" originalsrc="https://lists.isc.org/mailman/listinfo/dhcp-users" shash="lBg74fSB7S8TaiKFvtUrtXHagUbg14xtzF8x6VyfuX3NjMx0Wy2iRJhoyiAbmWHANpMTBTCWbDdOiR4unXVUO1/etjNtS69gedY7wcnp0EQVoZpU5LJ9t0262+iOZN6cp5UlMgPiDkSW9Rp6xERXuY+coYxzYsXD7B/670UUFWI=" class="">>>
https://lists.isc.org/mailman/listinfo/dhcp-users</a><br class="">
<br class="">
<span style=" font-family:'arial'; color: #c0c0c0;" class=""><i class="">-- <br class="">
Gregory Sloop, Principal: Sloop Network & Computer Consulting<br class="">
Voice: 503.251.0452 x82<br class="">
EMail: </i></span><a style=" font-family:'arial';" href="mailto:gregs@sloop.net" class="">gregs@sloop.net</a><br class="">
<a style=" font-family:'arial';" href="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" originalsrc="http://www.sloop.net" shash="HAGCnhFkrovJo8pmfrq1fYoL7ZHt00rxFoDw5tcPPEzDEKzQVVMPxtxPjPC/HuvmvxIHXErdKznHZz7ItY9ax7L/YgC9F36iz1o6S1tJnXKPKPI69wtYmJdjt4LqRorfwlXxSk+7K65eiXXEezTJwusZUaJe0+K4eRK7FZaqD6Y=" class="">http://www.sloop.net</a><br class="">
<span style=" font-family:'arial'; color: #c0c0c0;" class=""><i class="">---</i></span></div>
</div>
_______________________________________________<br class="">
dhcp-users mailing list<br class="">
<a href="mailto:dhcp-users@lists.isc.org" class="">dhcp-users@lists.isc.org</a><br class="">
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<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>