On Thu, Jan 30, 2020 at 3:49 AM Stuart Henderson <[email protected]> wrote: > > On 2020/01/30 11:15, Sebastian Benoit wrote: > > Chad Gross([email protected]) on 2020.01.29 16:22:52 -0700: > > > It isn't explicitly expressed in the man page that pfsync requires > > > identical interfaces to work properly so I've created a patch > > > clarifying that it won't work otherwise. A workaround is possible with > > > the use of trunk(4), or now possibly aggr(4), but I wasn't sure this > > > additional information was warranted in the man page. > > > > I dont think this is correct. How do you come to this conclusion? > > If possible provide an example that shows what is not working. > > > > If you do not have identical rulesets, the transfered states will have the > > "rule number" reference removed, so you wont know what rule created a state > > anymore if you look at the receiving system only, but the state will work > > just fine. > > > > Possible exceptions i can think of are if-bound states.
The way I came to the conclusion is I have two systems with different wan interfaces (vr0 and em0) and when I issued pfctl -ss on the secondary, I only saw a few states from the host itself in the table. There were none from the primary. When I added vr0 and em0 to trunk0 on each machine and updated the ruleset to reference trunk0 rather than vr0 and em0 respectively, the state table on the secondary was populated with states from the primary. > It's also needed for getting states assigned to the correct queues (if used). > Maybe something else too. > > The usual workaround for this is to have rules reference interface groups > if the interface types differ. > I confirmed your suggested workaround also functions to get the primary state table on the secondary, which would seem more efficient than adding a single NIC as a port in a trunk. I noticed that pf failed to load the ruleset when trying to reference the queue though, which I think you were getting at with your first comment. Are you saying that, while the states may have transferred over to the secondary, since the queues have to reference the interface explicitly that they won't work correctly once the secondary takes control after a failover? In other words, if you have queuing you need to use the trunk0 workaround rather than the groups workaround? Either way, my original premise stands that if the interfaces aren't the same as referenced in the ruleset (I can clarify that it's the ruleset referencing part that is the requirement in the patch) they won't load on the secondary.
