public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Dominic Jäger" <d.jaeger@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v3 conntrack-tool 1/4] initial commit
Date: Tue, 6 Apr 2021 12:19:34 +0200	[thread overview]
Message-ID: <20210406101934.GA76758@mala> (raw)
In-Reply-To: <20210216165642.16600-1-m.limbeck@proxmox.com>

On Tue, Feb 16, 2021 at 05:56:39PM +0100, Mira Limbeck wrote:
> Dumping conntrack information and importing conntrack information works
> for IPv4 and IPv6. No filtering is supported for now. pve-conntrack-tool
> will always return both IPv4 and IPv6 conntracks together.
> 
> Conntracks are serialized as JSON and printed on STDOUT line by line
> with one line containing one conntrack. When inserting data is read
> from STDIN line by line and expected to be one JSON object per line
> representing the conntrack.

When comparing conntrack -L and pve-conntrack-tool dump gave equivalent
outputs.  It might be a bit confusing that the tool uses converted values, e.g.
for ports. But I think this shouldn't matter as it's internal.

With firewall enabled on both nodes and cluster

> cat /etc/pve/firewall/cluster.fw /etc/pve/nodes/pveA/host.fw /etc/pve/nodes/pveB/host.fw | grep enable
> enable: 1
> enable: 1
> enable: 1

and tcp_loose deactivated on both nodes

> sysctl net.netfilter.nf_conntrack_tcp_loose 
> net.netfilter.nf_conntrack_tcp_loose = 0

I could copy test flow entries like
> conntrack -I -p tcp -t 60 --src 127.0.0.1 --dst 1.1.1.1 --state LISTEN --sport 80 --dport 55555
> pve-conntrack-tool dump | ssh root@192.168.25.147 pve-conntrack-tool insert

from node A to B

>conntrack -L | grep 55555
>tcp      6 52 SYN_SENT2 src=127.0.0.1 dst=1.1.1.1 sport=80 dport=55555 [UNREPLIED] src=1.1.1.1 dst=127.0.0.1 sport=55555 dport=80 mark=0 use=1

and looking at the number of flow entries it seems the other flow entries have been copied, too.


What still confuses me a little is live migration. Not sure if I'm doing this right.

Without the new option
> qm migrate 150 pveB --online

the SSH connection to the migrating guest broke (OK, I guess) but after
reconnecting the old flow entries were still there? Shouldn't they vanish?

With the new option
> qm migrate 150 pveA --online --migrate-conntracks

the SSH connection to the guest sometimes remained working and sometimes not
(and the entries survived).

Tested-by: Dominic Jäger <d.jaeger@proxmox.com>




      parent reply	other threads:[~2021-04-06 10:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 16:56 Mira Limbeck
2021-02-16 16:56 ` [pve-devel] [PATCH v3 conntrack-tool 2/4] add packaging support Mira Limbeck
2021-02-16 16:56 ` [pve-devel] [PATCH v3 conntrack-tool 3/4] add expectation support Mira Limbeck
2021-02-16 16:56 ` [pve-devel] [PATCH v3 conntrack-tool 4/4] add additional bindings Mira Limbeck
2021-04-06 10:19 ` Dominic Jäger [this message]

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=20210406101934.GA76758@mala \
    --to=d.jaeger@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal