Y'all are quite right: one of the machines inverted the order of restarting
with the new config and updating the package and was advertising the h2
ALPN with HAProxy 1.7.11.

Sorry to take up so much time with a silly question.

Cheers!

On Wed, Oct 24, 2018 at 12:21 AM Aleksandar Lazic <[email protected]>
wrote:

> Am 24.10.2018 um 09:18 schrieb Igor Cicimov:
> >
> >
> > On Wed, 24 Oct 2018 5:06 pm Aleksandar Lazic <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     Hi.
> >
> >     Am 24.10.2018 um 03:02 schrieb Igor Cicimov:
> >     > On Wed, Oct 24, 2018 at 9:16 AM James Brown <[email protected]
> >     <mailto:[email protected]>> wrote:
> >     >>
> >     >> I tested enabling HTTP/2 on the frontend for some of our sites
> today and
> >     immediately started getting a flurry of failures. Browsers (at least
> Chrome)
> >     showed a lot of SPDY protocol errors and the HAProxy logs had a lot
> of lines
> >     ending in
> >     >>
> >     >> https_domain_redacted/<NOSRV> -1/-1/-1/-1/100 400 187 - - PR--
> 49/2/0/0/0 0/0
> >     >>
> >     >
> >     > Possible reasons:
> >     >
> >     > 1. You don't have openssl v1.0.2 installed (assuming you use
> openssl)
> >     > on a server(s)
> >     > 2. You have changed your config for h2 suport but your server(s) is
> >     > still running haproxy 1.7 (i.e. hasn't been restarted after upgrade
> >     > and still using the old 1.7 binary instead 1.8)
> >
> >     That's one of the reason why we need to know the exact version.
> >
> >     James can you post the output of `haproxy -vv` and some more
> information about
> >     your setup.
> >
> >
> > This can return the correct version but it still does not mean the runnig
> > process is actually using it (has not been restarted after upgrade).
>
> Full Ack. That's the reason why we need some more information's about the
> setup ;-)
>
> >     Regards
> >     Aleks
> >
> >     >> There were no useful or interesting errors logged to syslog. No
> sign of
> >     any resources being exhausted (conntrack seems fine, etc). The times
> varied
> >     but Ta was always low (usually around 100ms). I have not been able to
> >     reproduce this issue in a staging environment, so it may be
> something "real
> >     browsers" do that doesn't show up with h2load et al.
> >     >>
> >     >> Turning off HTTP/2 (setting "alpn http/1.1") completely solves
> the problem.
> >     >>
> >     >> The following timeouts are set on all of the affected frontends:
> >     >>
> >     >>     retries 3
> >     >>     timeout client 9s
> >     >>     timeout connect 3s
> >     >>     timeout http-keep-alive 5m
> >     >>     tcp-request inspect-delay 4s
> >     >>     option http-server-close
> >     >>
> >     >> Additionally, we set maxconn to a very high value (20480).
> >     >>
> >     >> Backends generally have timeout server set to a largeish value
> (90-300
> >     seconds, depending on the backend).
> >     >>
> >     >> Anything jump out at anyone?
> >     >> --
> >     >> James Brown
> >     >> Systems & Network Engineer
> >     >> EasyPost
> >     >
> >
>
>

-- 
James Brown
Engineer

Reply via email to