Ah,
Your diagram makes perfect sense now :) Thank you - So it does not have to
undergo a full rehashing of all links (which breaks _lots_ of sessions when
NAT is involved), but also does not have to explicitly track anything in
memory like you say So better than full re-hashing and cheaper
On Wed, Sep 29, 2021 at 08:07:43PM +1000, Andrew Lemin wrote:
> Hi Claudio,
>
> So you probably guessed I am using 'route-to { GW1, GW2, GW3, GW4 } random'
> (and was wanting to add 'sticky-address' to this) based on your reply :)
>
> "it will make sure that selected default routes are sticky to
Hi Claudio,
So you probably guessed I am using 'route-to { GW1, GW2, GW3, GW4 } random'
(and was wanting to add 'sticky-address' to this) based on your reply :)
"it will make sure that selected default routes are sticky to source/dest
pairs" - Are you saying that even though multipath routing
On Wed, Sep 29, 2021 at 02:17:59PM +1000, Andrew Lemin wrote:
> I see this question died on its arse! :)
>
> This is still an issue for outbound load-balancing over multiple internet
> links.
>
> PF's 'sticky-address' parameter only works on source IPs (because it was
> originally designed for
I see this question died on its arse! :)
This is still an issue for outbound load-balancing over multiple internet
links.
PF's 'sticky-address' parameter only works on source IPs (because it was
originally designed for use when hosting your own server pools - inbound
load balancing).
I.e. There
Hi smart people :)
The current implementation of ‘sticky-address‘ relates only to a sticky source
IP.
https://www.openbsd.org/faq/pf/pools.html
This is used for inbound server load balancing, by ensuring that all socket
connections from the same client/user/IP on the internet goes to the same
6 matches
Mail list logo
