Esoteric question

Wed Sep 18 10:00:10 UTC 2019

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 <gregs at sloop.net> <
gregs at 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.brennan at 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 <gregs at 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 at lists.isc.org
> <dhcp-users at 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: *gregs at 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 at 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 at 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-0001.html>