Robert, thanks again for your thoughtful reply. I am only using the net-snmp command-line utilities as a lingua franca. In reality, my SNMP application does not use the net-snmp libraries and thus cannot use clientaddr (and it has no similar functionality to net-snmp's clientaddr).
I'm still looking in the code to find where/why rp_filter is deciding to drop the SNMP replies by default. Any insight how I might trace this?
I did make a typo in my ASCII drawing - in the line 3 comment - my profuse apologies. I incorrectly showed the prefix as 192.168.0.0/24, I should've shown as 192.168.168.0 - corrected below. I also updated the comment in line 6 to be more descriptive.
I am indeed using VLAN 2 as an internal network within the local chassis only; the idea is that one blade in the chassis (nat1) functions as a NAT translator; if any other blade in the chassis (hostA, B, or C... ) wants it's outbound traffic translated it can use nat1 for its next hop. And these two points are most important: 1) I don't want any outbound traffic from hostA, B, C translated by nat1 except their outbound SNMP requests; 2) I do not want any inbound traffic to hostA, B, C other than SNMP responses to traverse the NAT.
I'm bonding eth0 and eth1 because I require hardware redundancy on VLAN 1. It's not really germane to the conversation about netfilter, policy routing, or SNMP though, so let's not worry about that (unless you feel it necessary).
As you correctly conclude, my chassis includes not just one but two independent internal ethernet switches, switch0 and switch1; each switch has two VLAN's configured: VLAN #1 and VLAN #2. In each switch VLAN1 is connected to and routed "to the rest of the world" via RTR (which in reality is an HSRP pair); VLAN2 is not connected beyond the chassis and is not routed. Each blade in the chassis has a single ethernet link to each internal switch (eth0 to switch0, eth1 to switch1). And the switches are not really filtering anything (other than malformed frames).
>>> So if you strip out all the nonsense and just put the addresses on bond0.1 and bond0.2, then only generate traffic to 192.168.168.anything addresses when you want to use bond0.2 then everything is finished.<<<
The SNMP agents I'm polling are all in 10.0.0.0/8. I'm not seeing how I can avoid a second routing table, using ip rule, iptables, nft, while steering just the outbound SNMP polling traffic to the rest of the world to the NAT blade. It's seems as clear a case for "policy-based routing" as one can draw: "if locally-generated traffic is non-SNMP, use RTR for the outbound next-hop; if locally-generated traffic is SNMP, use nat1 for the outbound next-hop".
If I only configure the IP addresses as you suggest in hostA,B,C... with no mention of nat1's IP address, the kernel on the host will never select bond0.2 for outbound polls to 10.0.0.0/8.
----------8<-------------------
hostA-C and nat1 are all contained within a single chassis; RTR is not within the chassis.
+-------------- INTERNAL network, VLAN 2, 192.168.168.0/24, bond0.2 on all hosts. This VLAN is internal to the chassis and is not routable outside the chassis.
|
|
| +----- EXTERNAL network, VLAN 1, 10.0.0.0/8 network, bond0.1 on all hosts. This VLAN has external connectivity via RTR
| |
| |
| |
V V
~ ~
| +-------+ |
| | | |
+--| hostA |--+
| | | |
| +-------+ |
| |
| +-------+ |
| | | |
+--| hostB |--+ Notes:
| | | |
| +-------+ | hostA-C are not forwarding/routing.
| | other network interfaces omitted for clarity (SAN, DR, etc.).
| +-------+ |
| | | |
+--| hostC |--+
| | | |
| +-------+ |
| | ~
| . | +------+ | (((((((((((((())))))))))))))
| . | | | | ( )
| . +---| RTR |--+--( the rest of the network )
| | | | | ( )
| +-------+ | +------+ | (((((((((((((())))))))))))))
| | | | ~
+--| nat1 |--+
| | | |
| +-------+ |
~ ~
��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
