CIFS & Management routing problem
Pages: 1 2
RafS
32 Posts
February 18, 2021, 11:43 amQuote from RafS on February 18, 2021, 11:43 amManagement & CIFS are on the same bond with different vlan
Management VLAN 10 (172.29.10.x/24)
CIFS VLAN 30 (172.29.30.x/24)
on the nodes where CIFS is activated we can't reach the management ip when comming from a client with vlan 30 ip range.
regards
Raf
Management & CIFS are on the same bond with different vlan
Management VLAN 10 (172.29.10.x/24)
CIFS VLAN 30 (172.29.30.x/24)
on the nodes where CIFS is activated we can't reach the management ip when comming from a client with vlan 30 ip range.
regards
Raf
admin
2,930 Posts
February 18, 2021, 10:14 pmQuote from admin on February 18, 2021, 10:14 pmCan you clarify more. your client is on vlan 30 on 172.29.30.x/24 and trying to reach management vlan 10 on 172.29.10.x/24 ?
Can you clarify more. your client is on vlan 30 on 172.29.30.x/24 and trying to reach management vlan 10 on 172.29.10.x/24 ?
RafS
32 Posts
February 19, 2021, 7:00 amQuote from RafS on February 19, 2021, 7:00 amThis is indeed the situation. A client in the 172.29.30.x/24 can not reach the management interface. This is only the problem on the nodes where the cifs protocol is activated. From the node itself i can reach all ip's. It seems it sends out the traffic to the wrong interface.
This is indeed the situation. A client in the 172.29.30.x/24 can not reach the management interface. This is only the problem on the nodes where the cifs protocol is activated. From the node itself i can reach all ip's. It seems it sends out the traffic to the wrong interface.
admin
2,930 Posts
February 19, 2021, 8:10 amQuote from admin on February 19, 2021, 8:10 amif the client is trying to access an ip not on its subnet, it will go through its gateway define at client. is this gateway/router able to route to the management subnet ? maybe i mis-understand.
if the client is trying to access an ip not on its subnet, it will go through its gateway define at client. is this gateway/router able to route to the management subnet ? maybe i mis-understand.
RafS
32 Posts
February 19, 2021, 11:36 amQuote from RafS on February 19, 2021, 11:36 amThe gateway is able to route to the management subnet. From the moment that we configure a node as cifs server, the ping stops replying on the management ip.
Tracing route to AALV-CEPH-CL01.aalpro.local [172.29.10.111]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.29.30.250
2 <1 ms <1 ms <1 ms AALV-CEPH-CL01.aalpro.local [172.29.10.111]
Trace complete.
When we configure the cifs role on this node, trafic arrives, but never returns to the client. I think the node sends the traffic back to the client on the wrong interface (creating a asymmetric route).
The gateway is able to route to the management subnet. From the moment that we configure a node as cifs server, the ping stops replying on the management ip.
Tracing route to AALV-CEPH-CL01.aalpro.local [172.29.10.111]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.29.30.250
2 <1 ms <1 ms <1 ms AALV-CEPH-CL01.aalpro.local [172.29.10.111]
Trace complete.
When we configure the cifs role on this node, trafic arrives, but never returns to the client. I think the node sends the traffic back to the client on the wrong interface (creating a asymmetric route).
admin
2,930 Posts
February 19, 2021, 2:21 pmQuote from admin on February 19, 2021, 2:21 pmDo you specify a custom route for CIFS service ? I understand the CIFS client is on the same subnet as the CIFS service, if so then try to use the default route. If you need to specify a custom route for the CIFS service, did you specify the same gateway for the service as the same gateway used by the client ? if they are different it could be the cause of the asymmetric route.
Do you specify a custom route for CIFS service ? I understand the CIFS client is on the same subnet as the CIFS service, if so then try to use the default route. If you need to specify a custom route for the CIFS service, did you specify the same gateway for the service as the same gateway used by the client ? if they are different it could be the cause of the asymmetric route.
RafS
32 Posts
February 20, 2021, 2:39 pmQuote from RafS on February 20, 2021, 2:39 pmI did specify the gateway for cifs (172.29.30.254). This is also the gateway used by the clients. Gateway for the management interface is 172.29.10.254.
I did specify the gateway for cifs (172.29.30.254). This is also the gateway used by the clients. Gateway for the management interface is 172.29.10.254.
RafS
32 Posts
February 23, 2021, 11:58 amQuote from RafS on February 23, 2021, 11:58 amThe problem exists on the node.
We can reach the management ip without problems from al other ip-ranges. It's just clients in the same range as the cifs that can't reach the management ip. For me it's a multihomed routing problem on the nodes.
What can we do about it !
Regards
Raf
The problem exists on the node.
We can reach the management ip without problems from al other ip-ranges. It's just clients in the same range as the cifs that can't reach the management ip. For me it's a multihomed routing problem on the nodes.
What can we do about it !
Regards
Raf
robindewolf
9 Posts
February 23, 2021, 4:29 pmQuote from robindewolf on February 23, 2021, 4:29 pmHi,
Can you try the following: change the reverse path filtering setting in /etc/sysctl.d/10-network-security.conf
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.all.rp_filter=2
By default, it is equal to 1. By putting 2 each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path.
For more information, see:
https://tom-henderson.github.io/2019/04/12/ubuntu-vlan-config.html
https://www.theurbanpenguin.com/rp_filter-and-lpic-3-linux-security/
Kr,
Robin
Hi,
Can you try the following: change the reverse path filtering setting in /etc/sysctl.d/10-network-security.conf
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.all.rp_filter=2
By default, it is equal to 1. By putting 2 each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path.
For more information, see:
https://tom-henderson.github.io/2019/04/12/ubuntu-vlan-config.html
Kr,
Robin
RafS
32 Posts
February 23, 2021, 6:32 pmQuote from RafS on February 23, 2021, 6:32 pmHi,
After changing the rp_filter it seems to work. Is there a risk in setting this on all the nodes ? What happens when upgrading the cluster to new version ?
Raf
Hi,
After changing the rp_filter it seems to work. Is there a risk in setting this on all the nodes ? What happens when upgrading the cluster to new version ?
Raf
Pages: 1 2
CIFS & Management routing problem
RafS
32 Posts
Quote from RafS on February 18, 2021, 11:43 amManagement & CIFS are on the same bond with different vlan
Management VLAN 10 (172.29.10.x/24)
CIFS VLAN 30 (172.29.30.x/24)on the nodes where CIFS is activated we can't reach the management ip when comming from a client with vlan 30 ip range.
regards
Raf
Management & CIFS are on the same bond with different vlan
Management VLAN 10 (172.29.10.x/24)
CIFS VLAN 30 (172.29.30.x/24)
on the nodes where CIFS is activated we can't reach the management ip when comming from a client with vlan 30 ip range.
regards
Raf
admin
2,930 Posts
Quote from admin on February 18, 2021, 10:14 pmCan you clarify more. your client is on vlan 30 on 172.29.30.x/24 and trying to reach management vlan 10 on 172.29.10.x/24 ?
Can you clarify more. your client is on vlan 30 on 172.29.30.x/24 and trying to reach management vlan 10 on 172.29.10.x/24 ?
RafS
32 Posts
Quote from RafS on February 19, 2021, 7:00 amThis is indeed the situation. A client in the 172.29.30.x/24 can not reach the management interface. This is only the problem on the nodes where the cifs protocol is activated. From the node itself i can reach all ip's. It seems it sends out the traffic to the wrong interface.
This is indeed the situation. A client in the 172.29.30.x/24 can not reach the management interface. This is only the problem on the nodes where the cifs protocol is activated. From the node itself i can reach all ip's. It seems it sends out the traffic to the wrong interface.
admin
2,930 Posts
Quote from admin on February 19, 2021, 8:10 amif the client is trying to access an ip not on its subnet, it will go through its gateway define at client. is this gateway/router able to route to the management subnet ? maybe i mis-understand.
if the client is trying to access an ip not on its subnet, it will go through its gateway define at client. is this gateway/router able to route to the management subnet ? maybe i mis-understand.
RafS
32 Posts
Quote from RafS on February 19, 2021, 11:36 amThe gateway is able to route to the management subnet. From the moment that we configure a node as cifs server, the ping stops replying on the management ip.
Tracing route to AALV-CEPH-CL01.aalpro.local [172.29.10.111]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms 172.29.30.250
2 <1 ms <1 ms <1 ms AALV-CEPH-CL01.aalpro.local [172.29.10.111]Trace complete.
When we configure the cifs role on this node, trafic arrives, but never returns to the client. I think the node sends the traffic back to the client on the wrong interface (creating a asymmetric route).
The gateway is able to route to the management subnet. From the moment that we configure a node as cifs server, the ping stops replying on the management ip.
Tracing route to AALV-CEPH-CL01.aalpro.local [172.29.10.111]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.29.30.250
2 <1 ms <1 ms <1 ms AALV-CEPH-CL01.aalpro.local [172.29.10.111]
Trace complete.
When we configure the cifs role on this node, trafic arrives, but never returns to the client. I think the node sends the traffic back to the client on the wrong interface (creating a asymmetric route).
admin
2,930 Posts
Quote from admin on February 19, 2021, 2:21 pmDo you specify a custom route for CIFS service ? I understand the CIFS client is on the same subnet as the CIFS service, if so then try to use the default route. If you need to specify a custom route for the CIFS service, did you specify the same gateway for the service as the same gateway used by the client ? if they are different it could be the cause of the asymmetric route.
Do you specify a custom route for CIFS service ? I understand the CIFS client is on the same subnet as the CIFS service, if so then try to use the default route. If you need to specify a custom route for the CIFS service, did you specify the same gateway for the service as the same gateway used by the client ? if they are different it could be the cause of the asymmetric route.
RafS
32 Posts
Quote from RafS on February 20, 2021, 2:39 pmI did specify the gateway for cifs (172.29.30.254). This is also the gateway used by the clients. Gateway for the management interface is 172.29.10.254.
I did specify the gateway for cifs (172.29.30.254). This is also the gateway used by the clients. Gateway for the management interface is 172.29.10.254.
RafS
32 Posts
Quote from RafS on February 23, 2021, 11:58 amThe problem exists on the node.
We can reach the management ip without problems from al other ip-ranges. It's just clients in the same range as the cifs that can't reach the management ip. For me it's a multihomed routing problem on the nodes.
What can we do about it !
Regards
Raf
The problem exists on the node.
We can reach the management ip without problems from al other ip-ranges. It's just clients in the same range as the cifs that can't reach the management ip. For me it's a multihomed routing problem on the nodes.
What can we do about it !
Regards
Raf
robindewolf
9 Posts
Quote from robindewolf on February 23, 2021, 4:29 pmHi,
Can you try the following: change the reverse path filtering setting in /etc/sysctl.d/10-network-security.conf
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.all.rp_filter=2
By default, it is equal to 1. By putting 2 each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path.
For more information, see:
https://tom-henderson.github.io/2019/04/12/ubuntu-vlan-config.html
https://www.theurbanpenguin.com/rp_filter-and-lpic-3-linux-security/
Kr,
Robin
Hi,
Can you try the following: change the reverse path filtering setting in /etc/sysctl.d/10-network-security.conf
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.all.rp_filter=2
By default, it is equal to 1. By putting 2 each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path.
For more information, see:
https://tom-henderson.github.io/2019/04/12/ubuntu-vlan-config.html
Kr,
Robin
RafS
32 Posts
Quote from RafS on February 23, 2021, 6:32 pmHi,
After changing the rp_filter it seems to work. Is there a risk in setting this on all the nodes ? What happens when upgrading the cluster to new version ?
Raf
Hi,
After changing the rp_filter it seems to work. Is there a risk in setting this on all the nodes ? What happens when upgrading the cluster to new version ?
Raf