Tagged VLAN with KVM

Hello, I got it working, but I’m not sure if it is right. I’m starting to have Problems again.
Configured on the Host Server with Yast2:
eth1 is connected to Switch and has IP: 192.168.111.189/24 Gateway 192.168.111.100 “HOSTNAME”
eth0 is connected to Switch and has IP: 0.0.0.0/24 (here I also found should be set to 0.0.0.0/32, that I did on another 2 Host Servers. Both ways seem to work.)
vlan1 set eth0, IP:0.0.0.0/32 “NO HOSTNAME” (acoording to my Network Section for Netz 192.168.1.0)
vlan23 set eth0, IP:0.0.0.0/32 “NO HOSTNAME” (acoording to my Network Section for Netz 192.168.23.0)
br1 set to vlan1, IP:0.0.0.0/32 “NO HOSTNAME” (acoording to my Network Section for Netz 192.168.1.0)
br23 set to vlan1, IP:0.0.0.0/32 “NO HOSTNAME” (acoording to my Network Section for Netz 192.168.23.0)

Are these settings OK?

I have 3 Host Servers, each with 3 to 6 VM Servers installed. They seemed to work fine, untill I wanted to install another Host Server. As soon as it booted, I got on all Host Servers,
br23: received packet on vlan23 woth own address as source address
br23: received packet on vlan23 woth own address as source address
br1: received packet on vlan1 woth own address as source address
br1: received packet on vlan1 woth own address as source address
The above message the Servers got ever 2 minutes untill I shut the Server down. So I completly reinstalled it and got the same Thing. I have googled now for 2 days and have not found any solution.
Do you have Ideas?

The guest Servers are connected with br1 or br23 using vnet? and virtio Network from KVM.

Does anybody know if the above is right? To me it makes no sense.

Hi Midata,

when I see “IP: 0.0.0.0/32” for any interface, I smell trouble - especially if it’s about layered interfaces (i.e. vlan on top of bridge). From my experience, an easy way to confuse such a network stack is to explicitly configure IP 0 on a lower layer, instead of configuring no IP at all.

But typically that’ll lead to vanishing IP packets, which doesn’t look at all like what you’re describing.

Have you checked for network loops, caused by adding the forth server with redundant uplinks? Something like adding both uplinks (eth0/1) to a common bridge, instead of trunking and then adding the trunk to the bridge?

Regards,
J

[QUOTE=jmozdzen;33580]Hi Midata,

when I see “IP: 0.0.0.0/32” for any interface, I smell trouble - especially if it’s about layered interfaces (i.e. vlan on top of bridge). From my experience, an easy way to confuse such a network stack is to explicitly configure IP 0 on a lower layer, instead of configuring no IP at all.[/QUOTE]

How would you suggest it to be set?

Packets are not vanishing, I seem to be getting to many.
br23: received packet on vlan23 with own address as source address.
Here I disabled IPv6 and that seem to help. At least I don’t get this message any more.

eth0 is one Switch and eth1 is on another. How they are configured I don’t know. That is our Network Section Job.
This is why I am asking, because they have no Idea about SLES11. They just tell me it is easier with Debian.

[QUOTE=jmozdzen;33580]Regards,
J[/QUOTE]

Hi Midata,

just leave it empty.

Right, which is why I didn’t think this is a cause to your problem.

[QUOTE=Midata;33616]eth0 is one Switch and eth1 is on another. How they are configured I don’t know. That is our Network Section Job.
This is why I am asking, because they have no Idea about SLES11. They just tell me it is easier with Debian.[/QUOTE]

It is much easier with MVS/390 and pure SNA - no duplicate IP address problem there :stuck_out_tongue:

I was aiming at the configuration on the new server. As the problem only surfaces once the new server is started, the “loop” (if that is the cause at all) is likely to be caused by the configuration of your new server.

Additionally, you may want to trace the offending packets on the reporting server(s) and check the source MAC address of the packets. If they come from the same MAC address as the server that’s reporting the duplicate IP, then it’s a network loop caused by activating the fourth server. If it’s a different source MAC address, then track down the “owner” of that MAC address and fix its configuration :wink:

Regards,
Jens

Hi Midata,

Here I disabled IPv6 and that seem to help. At least I don’t get this message any more.

that statement slipped by during first read - do you mean that disabling IPv6 causes all duplicate IP warnings to disappear on the affected servers?

Regards,
Jens

[QUOTE=jmozdzen;33620]Hi Midata,

Here I disabled IPv6 and that seem to help. At least I don’t get this message any more.

that statement slipped by during first read - do you mean that disabling IPv6 causes all duplicate IP warnings to disappear on the affected servers?

Regards,
Jens[/QUOTE]

yes, since I disabled IPv6, I do not get any more warnings.

[QUOTE=jmozdzen;33618]Hi Midata,

just leave it empty.

Right, which is why I didn’t think this is a cause to your problem.

It is much easier with MVS/390 and pure SNA - no duplicate IP address problem there :stuck_out_tongue:

I was aiming at the configuration on the new server. As the problem only surfaces once the new server is started, the “loop” (if that is the cause at all) is likely to be caused by the configuration of your new server.

Additionally, you may want to trace the offending packets on the reporting server(s) and check the source MAC address of the packets. If they come from the same MAC address as the server that’s reporting the duplicate IP, then it’s a network loop caused by activating the fourth server. If it’s a different source MAC address, then track down the “owner” of that MAC address and fix its configuration :wink:

Regards,
Jens[/QUOTE]

In the beginning yast would not let me leave IP empty. Since I disabled IP6V, I could Change it and leave it empty. It seems to work on some the 5 Metal Servers and others not. That is on the one I was having Problems with it worked. But I would like to have all Servers the same, so I set the older ones to. Then they started to get this message again. When I put the 0.0.0.0 back in, it stopped. Very strange.

Hi Midata,

In the beginning yast would not let me leave IP empty.

had you set the option “No Link and IP Setup (Bonding Slaves)” for this interface in YaST? The description seems to imply “chose this if it’s a bonding slave”, but actually means “you’d chose this if it’s a bonding slave, or any other interface that doesn’t need IP configuration”.

Could you please show the actual ifcfg-* files from a server that’s showing the symptoms, the resulting setup per “ifstatus” of the interfaces and the output of “ip addr list”?

Regards,
J

[QUOTE=jmozdzen;33738]Hi Midata,

In the beginning yast would not let me leave IP empty.

had you set the option “No Link and IP Setup (Bonding Slaves)” for this interface in YaST? The description seems to imply “chose this if it’s a bonding slave”, but actually means “you’d chose this if it’s a bonding slave, or any other interface that doesn’t need IP configuration”.

Could you please show the actual ifcfg-* files from a server that’s showing the symptoms, the resulting setup per “ifstatus” of the interfaces and the output of “ip addr list”?

Regards,
J[/QUOTE]

I do not get this anymore and I am not going to Change it back.

Hi Midata,

I do not get this anymore and I am not going to Change it back.

that’s perfectly fine with me (and I would probably handle it the same way). If you ever get back into this situation, we can simply pick up here.

Regards,
J