CentOS 6 bridging problem.
 

Hi all.

I have currently an OpenVZ server:

uname -a
Linux vader8.superhost.pl 2.6.32-042stab055.16 #1 SMP Fri Jun 8
19:22:28 MSD 2012 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/redhat-release
CentOS release 6.2 (Final)

lspci | grep -i eth
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

cd /etc/sysconfig/network-scripts

cat ifcfg-eth0
DEVICE="eth0"
BOOTPROTO=none
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Ethernet"
HWADDR=00:25:22:0D:C2:2A
DOMAIN=domain.eu
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
BRIDGE=vmbr0

cat ifcfg-eth0.20
DEVICE=eth0.20
BOOTPROTO=none
ONBOOT=yes
VLAN=yes
BRIDGE=vmbr20

cat ifcfg-vmbr20
DEVICE=vmbr20
BOOTPROTO=none
DHCPCLASS=
IPADDR=10.20.0.108
NETMASK=255.255.0.0
ONBOOT=yes
TYPE=Bridge

cat ifcfg-vmbr0
DEVICE=vmbr0
BOOTPROTO=none
DHCPCLASS=
IPADDR=195.218.152.219
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Bridge

cat ifcfg-vmbr0:1
DEVICE=vmbr0:1
BOOTPROTO=none
IPADDR=192.168.2.203
NETMASK=255.255.255.0
ONBOOT=yes

cat ifcfg-venet0
DEVICE=venet0
ONBOOT=yes
STARTMODE=onboot

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0
195.218.152.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0
10.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vmbr20
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 vmbr0
169.254.0.0 0.0.0.0 255.255.0.0 U 1006 0 0 vmbr20
0.0.0.0 193.218.152.1 0.0.0.0 UG 0 0 0 vmbr0

iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

So I have a setup in which:
- eth0 is my physical interface
- it is bridged with vmbr0 with ip 195.218.152.219 and this address
is accessible across the network
- eth0.20 is a logical interface in VLAN 20 on eth0
- it is bridged with vmbr20 with ip 10.20.0.108 and this address IS
NOT accessible across the network
- vmbr0 bridge has an alias vmbr0:1 with ip 192.168.2.203 and this
address is accessible across the network
When I set up the network for testing:
- eth0 as a physical interface 195.218.152.219
- eth0.20 as a VLAN interface 10.20.0.108
both addresses are accessible across the network (VLANs on the switch
are set up correctly, VLAN 1 untagged, VLAN 20 tagged).

Do you see an error in my configuration? Why is 10.20.0.108 not available?

Best regards,
Rafal.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

On 06/25/2012 05:22 AM, Rafał Radecki wrote:
> Do you see an error in my configuration? Why is 10.20.0.108 not available?

Not immediately, but check the output of the 'ip' tools. ifconfig and
route are deprecated:

ip route show
ip addr show

Finally, see if there's any incoming traffic on the tagged interface:

tcpdump -n -i eth0.20

... while you ping the assigned address.



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

ip route show
192.168.2.0/24 dev vmbr0 proto kernel scope link src 192.168.2.203
193.218.152.0/24 dev vmbr0 proto kernel scope link src 193.218.152.219
10.20.0.0/16 dev vmbr20 proto kernel scope link src 10.20.0.108
169.254.0.0/16 dev vmbr0 scope link metric 1003
169.254.0.0/16 dev vmbr20 scope link metric 1006
default via 193.218.152.1 dev vmbr0

ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
inet6 fe80::225:22ff:fe0d:c22a/64 scope link
valid_lft forever preferred_lft forever
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
inet 193.218.152.219/24 brd 193.218.152.255 scope global vmbr0
inet 192.168.2.203/24 brd 192.168.2.255 scope global vmbr0:1
inet6 fe80::225:22ff:fe0d:c22a/64 scope link
valid_lft forever preferred_lft forever
4: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN
link/void
inet6 fe80::1/128 scope link
valid_lft forever preferred_lft forever
5: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP
link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
inet6 fe80::225:22ff:fe0d:c22a/64 scope link
valid_lft forever preferred_lft forever
6: vmbr20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
inet 10.20.0.108/16 brd 10.20.255.255 scope global vmbr20
inet6 fe80::225:22ff:fe0d:c22a/64 scope link
valid_lft forever preferred_lft forever

Any clue?

Best regards,
Rafal Radecki.

2012/6/25 Gordon Messmer <yinyang@eburg.com>:
> On 06/25/2012 05:22 AM, Rafał Radecki wrote:
>> Do you see an error in my configuration? Why is 10.20.0.108 not available?
>
> Not immediately, but check the output of the 'ip' tools. Â*ifconfig and
> route are deprecated:
>
> ip route show
> ip addr show
>
> Finally, see if there's any incoming traffic on the tagged interface:
>
> tcpdump -n -i eth0.20
>
> ... while you ping the assigned address.
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

tcpdump -n -i eth0.20
shows that there is no traffic when I try to ping 10.20.0.108.

Best regards,
R.

2012/6/26 Rafał Radecki <radecki.rafal@gmail.com>:
> ip route show
> 192.168.2.0/24 dev vmbr0 Â*proto kernel Â*scope link Â*src 192.168.2.203
> 193.218.152.0/24 dev vmbr0 Â*proto kernel Â*scope link Â*src 193.218.152.219
> 10.20.0.0/16 dev vmbr20 Â*proto kernel Â*scope link Â*src 10.20.0.108
> 169.254.0.0/16 dev vmbr0 Â*scope link Â*metric 1003
> 169.254.0.0/16 dev vmbr20 Â*scope link Â*metric 1006
> default via 193.218.152.1 dev vmbr0
>
> ip addr show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> Â* Â*link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> Â* Â*inet 127.0.0.1/8 scope host lo
> Â* Â*inet6 ::1/128 scope host
> Â* Â* Â* valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> Â* Â*link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
> Â* Â*inet6 fe80::225:22ff:fe0d:c22a/64 scope link
> Â* Â* Â* valid_lft forever preferred_lft forever
> 3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
> Â* Â*link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
> Â* Â*inet 193.218.152.219/24 brd 193.218.152.255 scope global vmbr0
> Â* Â*inet 192.168.2.203/24 brd 192.168.2.255 scope global vmbr0:1
> Â* Â*inet6 fe80::225:22ff:fe0d:c22a/64 scope link
> Â* Â* Â* valid_lft forever preferred_lft forever
> 4: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UNKNOWN
> Â* Â*link/void
> Â* Â*inet6 fe80::1/128 scope link
> Â* Â* Â* valid_lft forever preferred_lft forever
> 5: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UP
> Â* Â*link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
> Â* Â*inet6 fe80::225:22ff:fe0d:c22a/64 scope link
> Â* Â* Â* valid_lft forever preferred_lft forever
> 6: vmbr20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
> Â* Â*link/ether 00:25:22:0d:c2:2a brd ff:ff:ff:ff:ff:ff
> Â* Â*inet 10.20.0.108/16 brd 10.20.255.255 scope global vmbr20
> Â* Â*inet6 fe80::225:22ff:fe0d:c22a/64 scope link
> Â* Â* Â* valid_lft forever preferred_lft forever
>
> Any clue?
>
> Best regards,
> Rafal Radecki.
>
> 2012/6/25 Gordon Messmer <yinyang@eburg.com>:
>> On 06/25/2012 05:22 AM, Rafał Radecki wrote:
>>> Do you see an error in my configuration? Why is 10.20.0.108 not available?
>>
>> Not immediately, but check the output of the 'ip' tools. Â*ifconfig and
>> route are deprecated:
>>
>> ip route show
>> ip addr show
>>
>> Finally, see if there's any incoming traffic on the tagged interface:
>>
>> tcpdump -n -i eth0.20
>>
>> ... while you ping the assigned address.
>>
>>
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

On 06/26/12 12:47 AM, Rafał Radecki wrote:
> tcpdump -n -i eth0.20
> shows that there is no traffic when I try to ping 10.20.0.108.

try just tcpdump -n -i eth0

I am not sure you can packet sniff a virtual interface, more likely you
can only sniff an actual physical interface.



--
john r pierce N 37, W 122
santa cruz ca mid-left coast


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

tcpdump -n -i eth0 icmp and src host 10.20.0.98

does not give any results when ping is invoked.

2012/6/26 John R Pierce <pierce@hogranch.com>:
> On 06/26/12 12:47 AM, Rafał Radecki wrote:
>> tcpdump -n -i eth0.20
>> shows that there is no traffic when I try to ping 10.20.0.108.
>
> try just tcpdump -n -i eth0
>
> I am not sure you can packet sniff a virtual interface, more likely you
> can only sniff an actual physical interface.
>
>
>
> --
> john r pierce Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â*N 37, W 122
> santa cruz ca Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* mid-left coast
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

On 06/26/2012 12:02 AM, Rafał Radecki wrote:
> Any clue?

Are you absolutely sure that the switch port connected to eth0 is
configured to deliver tagged packets for VLAN 20 (and that the ping
source is also on that VLAN)?


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

On 06/26/2012 08:51 AM, Gordon Messmer wrote:
> Are you absolutely sure that the switch port connected to eth0 is
> configured to deliver tagged packets for VLAN 20 (and that the ping
> source is also on that VLAN)?

...and I should follow that up with:

If you create a tagged ethernet interface on this system, with NO
BRIDGES AT ALL, does the tagged interface work as expected?

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

Yes, it works well, no problems then.

Best regards,
Rafal,

2012/6/26 Gordon Messmer <yinyang@eburg.com>:
> On 06/26/2012 08:51 AM, Gordon Messmer wrote:
>> Are you absolutely sure that the switch port connected to eth0 is
>> configured to deliver tagged packets for VLAN 20 (and that the ping
>> source is also on that VLAN)?
>
> ...and I should follow that up with:
>
> If you create a tagged ethernet interface on this system, with NO
> BRIDGES AT ALL, does the tagged interface work as expected?
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

CentOS 6 bridging problem.
 

On 06/25/2012 05:22 AM, Rafał Radecki wrote:
> Do you see an error in my configuration? Why is 10.20.0.108 not available?

I don't have a lot of managed switches around to do extensive testing.
The closest test I can do is on 5.8 with VLAN 2 and different IPs.
Based on that, everything seems like it should work. Since you're able
to set up the addresses on the interface without a bridge, the
likelihood of a driver problem seems fairly low. Did you ever send the
output of "brctl show"? You should definitely be able to run tcpdump on
eth0.20 and see any traffic on that interface. You said that you saw
none when you tried to ping the Linux host from the network. What about
the reverse? Do you see data go out eth0.20 when you try to ping an
address in the attached subnet from the Linux host?


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos