> From: Tom Eastep <[email protected]> > > As I explained earlier, that rule needs to be at priority 998.
I'm sorry if I'm such a pain by keeping this thread alive but I'd really like to understand the works behind this. As you said, you suggested to put the rule at priority 998. However, that was when my "main" table had a route entry that matched that traffic. So it made sense to give this rule a higher priority than "main". Now, as you can see in my last shorewall dump, the "main" table has changed. It is now: 172.28.17.110 dev enp5s0 scope link src 172.28.17.105 172.20.11.49 dev enp5s1 scope link src 172.20.11.62 172.16.0.2 dev enp4s1 scope link src 172.16.0.1 10.215.147.62 via 192.168.210.1 dev enp3s2 metric 2 10.215.147.61 via 172.16.0.1 dev enp4s1 metric 4 10.215.144.92 via 172.16.0.2 dev enp4s1 metric 4 10.215.144.90 via 172.16.0.2 dev enp4s1 metric 4 172.28.17.104/29 dev enp5s0 proto kernel scope link src 172.28.17.105 172.20.11.48/28 dev enp5s1 proto kernel scope link src 172.20.11.62 172.16.0.0/28 dev enp4s1 proto kernel scope link src 172.16.0.1 192.168.251.0/24 via 10.215.147.115 dev enp5s3 metric 5 192.168.250.0/24 via 10.215.147.115 dev enp5s3 metric 5 192.168.212.0/24 dev enp3s2 proto kernel scope link src 192.168.212.1 192.168.144.0/24 dev enp5s3 proto kernel scope link src 192.168.144.91 10.215.248.0/24 dev enp5s3 proto kernel scope link src 10.215.144.91 metric 1 192.168.210.0/23 dev enp3s2 proto kernel scope link src 192.168.210.1 10.215.246.0/23 dev enp5s3 proto kernel scope link src 10.215.144.91 metric 1 10.215.144.0/22 dev enp5s3 proto kernel scope link src 10.215.144.91 metric 1 127.0.0.0/8 dev lo scope host If I have this in rtrules (and leave mangle empty): 10.215.144.48 10.215.236.221 default 11001 and then I do the following on $FW: # ip route get 10.215.236.221 from 10.215.144.48 iif enp5s3 10.215.236.221 from 10.215.144.48 via 172.20.11.49 dev enp5s1 cache iif enp5s3 # ip route get 10.215.236.221 from 10.215.144.48 iif enp5s3 10.215.236.221 from 10.215.144.48 via 172.28.17.110 dev enp5s0 cache iif enp5s3 # ip route get 10.215.236.221 from 10.215.144.48 iif enp5s3 10.215.236.221 from 10.215.144.48 via 172.20.11.49 dev enp5s1 cache iif enp5s3 # ip route get 10.215.236.221 from 10.215.144.48 iif enp5s3 10.215.236.221 from 10.215.144.48 via 172.28.17.110 dev enp5s0 cache iif enp5s3 I can see that traffic "should" be load-balanced. Just to make sure, I also checked the same command with another source IP and confirmed that traffic would not be load-balanced (as expected): # ip route get 10.215.236.221 from 10.215.144.49 iif enp5s3 10.215.236.221 from 10.215.144.49 via 172.20.11.49 dev enp5s1 cache iif enp5s3 # ip route get 10.215.236.221 from 10.215.144.49 iif enp5s3 10.215.236.221 from 10.215.144.49 via 172.20.11.49 dev enp5s1 cache iif enp5s3 # ip route get 10.215.236.221 from 10.215.144.49 iif enp5s3 10.215.236.221 from 10.215.144.49 via 172.20.11.49 dev enp5s1 cache iif enp5s3 So I'm a bit confused and would like to know why the rule needs to have priority 998 and doesn't work with priority 11001. Of course, if I set priority 998 in rtrules then load-balancing DOES work, as you suggested. Thank you for your patience, Vieri ------------------------------------------------------------------------------ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
