From: Grant Taylor <gtaylor@tnetconsulting.net>
To: lartc@vger.kernel.org
Subject: Re: skipping not 'usefull' ip addresses of a dns lookup
Date: Sat, 26 Aug 2023 02:27:22 +0000 [thread overview]
Message-ID: <e752aa6f-7654-12f3-e89e-2e169a23adb3@tnetconsulting.net> (raw)
In-Reply-To: <fbd04b5dc8834959b02186f233aab942@f1-outsourcing.eu>
On 8/25/23 2:24 AM, Marc wrote:
> Hi Grant!
Hi Marc,
Real quickly, not having re-read my previous response and had way too
much water under the bridge between then and now.
> I was just 'cleaning up' a bit an ubuntu server from unnecessary
> running processes. Now I have some external auth that is sometimes
> slow due to the fact that the external auth host has two ip addresses
> configured. One of those ip addresses is not reachable from my
> ubuntu server.
The first thing that comes to mind is the "auth" a.k.a. "ident" service
that runs on TCP port 113. Though I'd be surprised if you actually had
an ident daemon running.
Is there a chance that you inadvertently changed incoming and / or
outgoing firewall config to filtered ident requests / replies and / or
TCP resets / ICMP unreachable messages therefor?
Lack of response to ident requets can cause a delay in services. This
could happen by blocking any of the following:
- outgoing locally generated requests
- incoming remotely generated replies
- incoming TCP reset
- incoming ICMP unreachable message
- incoming remotely generated requests
- outgoing locally generated replies
- outgoing TCP reset
- outgoing ICMP unreachable message
> Do you know if there is currently something client side that actively
> addresses this issue of having applications assigned ip addresses on
> different networks?
I'm going to need more context. -- Maybe it's in the part of the
thread that I've not read recently enough.
I'm trying to get a reply out to you quickly.
> I don't think I noticed this behaviour before my changes, could there
> be something smart in neworkmanager/systemd?
Any time that you question a network related change impacting services,
my go to solution is a network sniffer, tcpdump on CLI or Wireshark in
GUI. (Sometimes both, capture on remote CLI and analyze locally in GUI.)
--
Grant. . . .
next prev parent reply other threads:[~2023-08-26 2:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 9:31 skipping not 'usefull' ip addresses of a dns lookup Marc
2022-02-07 17:13 ` Grant Taylor
2022-02-07 19:03 ` Marc
2022-02-07 21:51 ` Grant Taylor
2023-08-25 7:24 ` Marc
2023-08-26 2:27 ` Grant Taylor [this message]
2023-08-26 10:32 ` Erik Auerswald
2023-08-26 18:38 ` Grant Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e752aa6f-7654-12f3-e89e-2e169a23adb3@tnetconsulting.net \
--to=gtaylor@tnetconsulting.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).