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