Re: [Keepalived-devel] About use_vmac :setting fwmark cause VRRP sent from base interface

[Quentin A. <qu...@ar...>]

On Thu, 2018-09-20 at 17:50 +0800, 翁淑嫚 wrote:
> Hi all:
> I encounter a problem about fwmark and "use_vmac".
> I'm using keepalived 2.0.7 on OpenWrt 15.05 for some VRRPv3 tests,
> and I'd like the VRRP messages be sent via VMAC interface.
> Thus I set "use_vmac" and do not set "vmac_xmit_base".
> At the begining, with following config, VRRP via VMAC is OK.
> But after I set fwmark for other application by command: 
> 
> # iptables -t mangle -A OUTPUT -j MARK --set-xmark 0xff00/0xff00
> 
> 
> Just after the command, the VRRP become being sent from the base
> interface.
> 
> Does anyone else encounter the same situation?
> 
> 
> 
> Is it a normal behavoir of keepalived?
> And, is it possible to set fwmark for my other application and still
> keep VRRP via VMAC?
> 
> Appreciate for any help. 
> Thank you.
> 
> Here is my config:
> 
> global_defs {
>    router_id TEST1
>    vrrp_version 3
> }
> 
> vrrp_instance VI_1 {
>    state MASTER
>    interface br-lan
>    virtual_router_id 1
>    priority 200
>    advert_int 1
>    use_vmac
>    virtual_ipaddress {
>       192.168.1.1
>    }
> }
> 
> 
> 
I have tried your configuration with keepalived v2.0.7 and I don't
experience the same problem.

Do you have some configuration elsewhere (e.g. routing) that causes
packets matching the mark to be routed via br-lan? The man page for
iptables-extensions(8) does state though that if you want to use the
fwmark for routing, the fwmark needs to be set in the PREROUTING chain,
so setting it in the OUTPUT chain shouldn't be affecting routing.

Would it work for you not to set the fwmark for VRRP packets? I think
it is worth trying the following instead of the iptables command you
gave, to confirm that it is the fwmark causing the problem:.
# iptables -t mangle -A OUTPUT ! -p 112 -j MARK --set-xmark
0xff00/0xff00
which will mean that the fwmark is not set on vrrp adverts and check if
the vrrp packets are then sent on the VMAC interface.

If that doesn't fix it then an understanding of what the other
application is doing with the marked packets, and working through the
full iptables/nftables, ip rules and ip routes configurations would be
necessary.

I hope that helps,

Quentin Armitage