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 *******************************************