No response to ping when alias IP (assigned to a bridge) pinged

[Aichor]

I have a server that is being hosted at OVH (SYS). Yes, I know their network setup is unique, so not all guides on the internet can be applied in my case. However, I believe this does fall back to CentOS.

I have several additional IPs ordered for my server. They work completely fine if I configure them in style of ifcfg-eth0:x. Server accepts connections from those IPs and responds.

However, when I try to create a bridge, it no longer works. From the server control panel (on SYS side) I can set virtual MAC addresses for the additional IPs, so they could be assigned to VMs. In order for that to work, the bridge on the host needs to accept connections from the assigned IP.

The quick way of testing if everything works is with these commands (instructed by OVH):

Code: Select all

ip link add name test-bridge link eth0 type macvlan
ip link set dev test-bridge address 02:00:00:6a:68:8e
ip link set test-bridge up
ip addr add <IP-address>/32 dev test-bridge

This is where things stop working. Tcpdump reveals that the server does receive ping request, but simply refuses to reply to it. Here's the thing though: with a fresh Debian install and using exactly the same commands things work perfectly as expected and the server replies to the ping. So I'm guessing that something somewhere is either preventing the bridge to reply to the ping or it doesn't receive it in the first place.
I've checked and there seems to be no firewall running, iptables shows ACCEPT in every directions with no rules, selinux is disabled.

[aks]

At a guess the Strict Reverse Path Forwarding sysctl see https://access.redhat.com/documentation ... forwarding

But that's a guess.

[TrevorH]

ip addr add <IP-address>/32 dev test-bridge

These instructions don't look like they are for a CentOS system and in any case, even if they were, they would not persist over a reboot. Since you're adding a /32 ip to the bridge, don't forget that you will also need to do the weird OVHness stuff and add an explicit route via the device to the gateway they have given you.

The correct way to do this permanently is to set up an /etc/sysconfig/network-scripts/ifcfg-br0 file containing TYPE=Bridge (case sensitive) along with all the other info like IPADDR=. Then you need to set up a /etc/sysconfig/network-scripts/route-br0 file to add the OVH specific route to their gateway via the device itself and only then can you add a default route via it. You'll need to remove the IP addresses from the ifcfg file for the underlying interface and move those over to the bridge.

[Aichor]

At a guess the Strict Reverse Path Forwarding sysctl see https://access.redhat.com/documentation ... forwarding

But that's a guess.

Thank you so much! After I turned it off the ping replies started going out immediately.

ip addr add <IP-address>/32 dev test-bridge

These instructions don't look like they are for a CentOS system and in any case, even if they were, they would not persist over a reboot. Since you're adding a /32 ip to the bridge, don't forget that you will also need to do the weird OVHness stuff and add an explicit route via the device to the gateway they have given you.

Actually I did none of the OVHness stuff in that case and it worked.

The correct way to do this permanently is to set up an /etc/sysconfig/network-scripts/ifcfg-br0 file containing TYPE=Bridge (case sensitive) along with all the other info like IPADDR=. Then you need to set up a /etc/sysconfig/network-scripts/route-br0 file to add the OVH specific route to their gateway via the device itself and only then can you add a default route via it. You'll need to remove the IP addresses from the ifcfg file for the underlying interface and move those over to the bridge.

True, those instructions were mainly for quick testing, so the interface disappearing after reboot was OK.
However, I'm trying to set up the permanent solution now, but I can't seem to be able to get it right.

ifcfg-eth0:0

Code: Select all

DEVICE=eth0:0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet
IPV6INIT=no
BRIDGE=test1

ifcfg-test1

Code: Select all

DEVICE=test1
BOOTPROTO=static
ONBOOT=yes
IPADDR=87.98.245.126
GATEWAY=188.165.225.254  <=== this is being ignored
NETMASK=255.255.255.0
DNS=213.186.33.99
TYPE=Bridge
MACADDR=02:00:00:d6:98:4d

Symptoms are the same - server receives the ping, but it doesn't reply. This time rp_filter is turned off - checked that twice.
route -n reveals that the gateway for 87.98.245.0 is 0.0.0.0. I don't understand how important that is exactly, because when I use the quick ip link commands from my previous post, route -n shows no additional routes actually and things still work.
I did add the route-test1 file

Code: Select all

188.165.225.254 - 255.255.255.255 test1
188.165.225.0 - 255.255.255.0 test1
default 188.165.225.254

but it changed nothing.

[TrevorH]

You can only have one ifcfg file containing GATEWAY= or you get a race condition where they fight about which one gets used.

Your route file doesn't look like the correct syntax to me, for example, what you have as "188.165.225.254 - 255.255.255.255 test1" should probably be

188.165.225.254/32 via test1

[aks]

First of all, apologies I've been off-line for quite a while.
Secondly is this thread still alive?

[Aichor]

It's alright, I was off too and this thing got put on the backburner. However, I'm back at it now, because it really needs a solution and I still have none. Need to remind myself a bit what I tried and what I didn't yet, but any ideas and suggestions are still welcome.

[aks]

IPADDR=87.98.245.126
GATEWAY=188.165.225.254 <=== this is being ignored
NETMASK=255.255.255.0

Yes a "default route" should be on the same network (at layer 3), otherwise how do I get there from here?

[Aichor]

True, I have no idea if I'm even on to something with that configuration file. I'm at a point where I'll just try anything.

Currently I can get the host OS respond to ping after executing the following lines

Code: Select all

ip link add name test-bridge link eth0 type macvlan
ip link set dev test-bridge address 02:00:00:6a:68:8e
ip link set test-bridge up
ip addr add <IP-address>/32 dev test-bridge

with the rp_filter turned off for test-bridge, eth0 and all interfaces.

Code: Select all

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.test-bridge.rp_filter = 0

However, this temporary test-bridge cannot be added as an interface to any VM - it says operation not supported. Yet this is the interface that works. Whenever I try to configure a permanent interface to respond to ping, I fail to get it working in the first place. It's possible I've already tried a solution that would have actually worked, but I just had one line wrong or a typo somewhere.