PDA

View Full Version : SLES 11 SP3 Tagged VLAN with KVM



Midata
15-Jul-2016, 07:43
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.

Midata
19-Jul-2016, 10:36
Does anybody know if the above is right? To me it makes no sense.

jmozdzen
21-Jul-2016, 12:35
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

Midata
22-Jul-2016, 08:57
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*.

How would you suggest it to be set?


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

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.


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?

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.


Regards,
J

jmozdzen
22-Jul-2016, 10:01
Hi Midata,

How would you suggest it to be set?
just leave it empty.




Packets are not vanishing, I seem to be getting to many.
Right, which is why I didn't think this is a cause to your problem.




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.

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

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 ;)

Regards,
Jens

jmozdzen
22-Jul-2016, 10:21
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

Midata
26-Jul-2016, 07:30
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

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

Midata
02-Aug-2016, 07:41
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 :P

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 ;)

Regards,
Jens

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.

jmozdzen
02-Aug-2016, 16:40
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

Midata
04-Aug-2016, 08:01
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

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

jmozdzen
04-Aug-2016, 12:15
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