Jira (PUP-9730) Connections with multiple addresses for a host should try ALL addresses for that host

29 views
Skip to first unread message

Jorie Tappa (JIRA)

unread,
Jun 7, 2019, 11:08:03 AM6/7/19
to puppe...@googlegroups.com
Jorie Tappa created an issue
 
Puppet / Task PUP-9730
Connections with multiple addresses for a host should try ALL addresses for that host
Issue Type: Task Task
Assignee: Unassigned
Created: 2019/06/07 8:07 AM
Labels: IPv6
Priority: Normal Normal
Reporter: Jorie Tappa
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Jorie Tappa (JIRA)

unread,
Jun 7, 2019, 11:09:04 AM6/7/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Sprint: Coremunity Hopper

Jorie Tappa (JIRA)

unread,
Jun 7, 2019, 11:15:03 AM6/7/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Sprint: Coremunity Hopper Grooming

Jorie Tappa (JIRA)

unread,
Jun 7, 2019, 11:16:03 AM6/7/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
A lot of considerations here, and this ticket may spawn more tickets, like strategies for attempting connections with multiple addresses at once, etc.

See this doc here also: [https://tools.ietf.org/html/rfc6555]

Jacob Helwig (JIRA)

unread,
Jun 7, 2019, 12:17:02 PM6/7/19
to puppe...@googlegroups.com
Jacob Helwig commented on Task PUP-9730
 
Re: Connections with multiple addresses for a host should try ALL addresses for that host

Jorie Tappa and I just did some quick investigation, and at least within IPv4 Net::HTTP is already trying all addresses for a given host, even though the timeout between addresses is very slow. The problem with the current behavior is that it will try all addresses on every HTTP connection to that host, which causes significant delays. We didn't try failing over from IPv6 to IPv4, but I suspect similar behavior if a host has mixed addresses. In general, we should probably try to use the same address that worked (if there are any) for a host for the entire length of a catalog run, instead of retrying all of the addresses from scratch on every connection to the host.

Jorie Tappa (JIRA)

unread,
Jun 12, 2019, 4:49:04 PM6/12/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
A lot of considerations here Until a successful connection is made , and it should try all addresses in the host list.

Current behavior: looks like Puppet already does this ticket may spawn more tickets , like strategies for attempting connections with multiple addresses at once but we haven't confirmed IPv6 , etc and we haven't confirmed failover from one to another .


See this doc here also: [https://tools.ietf.org/html/rfc6555]

Jorie Tappa (JIRA)

unread,
Jun 12, 2019, 4:50:03 PM6/12/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Acceptance Criteria: Until a successful connection is made, it should try all addresses that a dns entry resolves to, regardless of IPv4 or IPv6.

Jorie Tappa (JIRA)

unread,
Jul 8, 2019, 2:41:04 PM7/8/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Sprint: Coremunity Grooming Hopper

Jorie Tappa (JIRA)

unread,
Jul 31, 2019, 4:27:02 PM7/31/19
to puppe...@googlegroups.com
Jorie Tappa commented on Task PUP-9730
 
Re: Connections with multiple addresses for a host should try ALL addresses for that host

So since there's been some investigation on this and then follow up tickets were made (PUP-9732) this one might be able to just be closed, once we've tested the behavior for failover from IPv6 to IPv4.

Jorie Tappa (JIRA)

unread,
Aug 12, 2019, 12:39:03 PM8/12/19
to puppe...@googlegroups.com
Jorie Tappa assigned an issue to Kris Bosland
 
Change By: Jorie Tappa
Assignee: Kris Bosland

Kris Bosland (JIRA)

unread,
Aug 13, 2019, 3:21:04 PM8/13/19
to puppe...@googlegroups.com
Kris Bosland commented on Task PUP-9730
 
Re: Connections with multiple addresses for a host should try ALL addresses for that host

After some further testing, we were able to demonstrate this with an experiment using /etc/hosts and tcpdump.

If an /etc/hosts entry enables connection to the puppet server, then the result is quickly cached and not revisited, but when the successful connection entry is removed, tcpdump shows that the failing addresses are tried in order, multiple times each.

Example /etc/hosts section (all of these uncommented entries are dead ends):

Example tcpdump command line:

sudo tcpdump -n -i any port 8140 and 'tcp[tcpflags] & (tcp-syn) != 0'

Example tcpdump output:

11:53:53.039572 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [SEW], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374376198 ecr 0,sackOK,eol], length 0
 
11:53:54.061786 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [S], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374377198 ecr 0,sackOK,eol], length 0
 
11:53:55.126871 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [S], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374378198 ecr 0,sackOK,eol], length 0
 
11:53:56.197239 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [S], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374379198 ecr 0,sackOK,eol], length 0
 
11:53:57.221763 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [S], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374380198 ecr 0,sackOK,eol], length 0
 
11:53:58.239689 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [S], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374381198 ecr 0,sackOK,eol], length 0
 
11:54:00.285677 IP 192.168.86.31.53746 > 192.168.5.5.8140: Flags [S], seq 2816518652, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374383198 ecr 0,sackOK,eol], length 0
 
11:54:00.294136 IP 192.168.86.31.53747 > 192.168.5.4.8140: Flags [SEW], seq 2069260728, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374383206 ecr 0,sackOK,eol], length 0
 
11:54:01.313546 IP 192.168.86.31.53747 > 192.168.5.4.8140: Flags [S], seq 2069260728, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374384206 ecr 0,sackOK,eol], length 0
 
11:54:02.336510 IP 192.168.86.31.53747 > 192.168.5.4.8140: Flags [S], seq 2069260728, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374385206 ecr 0,sackOK,eol], length 0
 
11:54:02.892301 IP 192.168.86.31.53748 > 192.69.65.8.8140: Flags [SEW], seq 750420691, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374385751 ecr 0,sackOK,eol], length 0
 
11:54:02.907608 IP 192.69.65.8.8140 > 192.168.86.31.53748: Flags [S.E], seq 201576444, ack 750420692, win 28960, options [mss 1460,sackOK,TS val 3903822055 ecr 374385751,nop,wscale 7], length 0
 
11:54:03.371566 IP 192.168.86.31.53747 > 192.168.5.4.8140: Flags [S], seq 2069260728, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374386206 ecr 0,sackOK,eol], length 0
 
11:54:04.458017 IP 192.168.86.31.53747 > 192.168.5.4.8140: Flags [S], seq 2069260728, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374387206 ecr 0,sackOK,eol], length 0
 
11:54:04.465274 IP 192.168.86.31.53749 > 192.168.5.3.8140: Flags [SEW], seq 166916616, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374387213 ecr 0,sackOK,eol], length 0
 
11:54:05.505135 IP 192.168.86.31.53749 > 192.168.5.3.8140: Flags [S], seq 166916616, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374388213 ecr 0,sackOK,eol], length 0
 
11:54:06.670413 IP 192.168.86.31.53749 > 192.168.5.3.8140: Flags [S], seq 166916616, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374389213 ecr 0,sackOK,eol], length 0
 
11:54:07.771410 IP 192.168.86.31.53749 > 192.168.5.3.8140: Flags [S], seq 166916616, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374390213 ecr 0,sackOK,eol], length 0
 
11:54:08.882183 IP 192.168.86.31.53749 > 192.168.5.3.8140: Flags [S], seq 166916616, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374391213 ecr 0,sackOK,eol], length 0
 
11:54:08.892949 IP 192.168.86.31.53750 > 192.168.5.2.8140: Flags [SEW], seq 1867558455, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374391223 ecr 0,sackOK,eol], length 0
 
11:54:09.968620 IP 192.168.86.31.53750 > 192.168.5.2.8140: Flags [S], seq 1867558455, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374392223 ecr 0,sackOK,eol], length 0
 
11:54:11.055318 IP 192.168.86.31.53750 > 192.168.5.2.8140: Flags [S], seq 1867558455, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374393223 ecr 0,sackOK,eol], length 0
 
11:54:12.120118 IP 192.168.86.31.53750 > 192.168.5.2.8140: Flags [S], seq 1867558455, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374394223 ecr 0,sackOK,eol], length 0
 
11:54:13.214470 IP 192.168.86.31.53750 > 192.168.5.2.8140: Flags [S], seq 1867558455, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 374395223 ecr 0,sackOK,eol], length 0

Reply all
Reply to author
Forward
0 new messages