Are we really the only ones with this issue? Has no one else seen this change in behaviour? Or otherwise have any idea where it's coming from?
Or at least confirm whether they do or don't see the same behaviour. Any pointers or suggestions will be appreciated. Kind regards, Bartosz Bartosz wrote on 10/11/2020 20:30 +0100: > And it seems our existing loadbalancer actually work as I expect. It > seems the order of the frontends is irrelevant, the more specific one > gets picked over the fallback one. > > This is really puzzling me. Why is it different on this newest VM? > > Kernel 3.16 vs 4.9 ? But then I'm surprised that googling doesn't turn > up many people with this issue. > > Kind regards, > Bartosz > > Bartosz wrote on 10/11/2020 15:50 +0100: > > Hi, > > > > for years we've been using HAProxy, currently on 2.0. And we've had a > > setup like this (simplified): > > > > ========================================= > > frontend <cust1> > > bind <cust1_IP>:80 > > > > use_backend <cust1-www> > > > > frontend <cust2> > > bind <cust2_IP>:80 > > > > use_backend <cust1-www> > > > > .... > > > > fronted fallback > > bind *:80 > > > > use_backend <fallback-www> > > ========================================= > > > > This has been working fine for us, but now while installing a new > > loadbalancer we ran into the issue that all requests end up in the > > fronted 'fallback'. The only way to get back the old behaviour is to > > place that frontend at the top. > > > > Now that raises two questions: > > - What changed? The HAProxy version is the same, so is the config as > > this is genearted by us. So could this be a library (we build from > > source) or perhaps kernel. Any idea? > > - What's the intended behaviour and can this be influenced? I'd rather > > not have a situation where the behaviour can change between vms. I > > would expect to have the more specific bind always take precedence, > > regardless of the order. > > > > Thank you in advance for any thoughts. > > > > Kind regards, > > Bartosz > > > > > > > > > > -- > Bartosz Oudekerk > > > !DSPAM:1,5faaeb0d15872102463617! > -- Bartosz Oudekerk
