On Thu, Jan 30, 2020 at 8:11 AM Chad Gross <[email protected]> wrote: > > 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.
Benno, You were right, I was able to get it to work as you indicated. The same NIC is not required for states to transfer. I was missing persistence in the config that prevented it from working. Thanks, Chad
