[Comm] проблемы после поднятия bridge

[Comm] проблемы после поднятия bridge

[Andrew Clark]

Добрый день
Для использования сети в виртуальной машине, требуется поднять
туннель и объеденить его в бридж с сетевой картой.

Сетевая карта:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
        Subsystem: Giga-byte Technology GA-EP45-DS5 Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 28
        I/O ports at d000 [size=256]
        Memory at e9000000 (64-bit, non-prefetchable) [size=4K]
        [virtual] Expansion ROM at 80000000 [disabled] [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: r8169

Настройки интерфейсов:

[andy@timelock ~]$ ls br0/
brctl  ipv4address  options
[andy@timelock ~]$ cat br0/*
stp AUTO on

10.10.1.1/8

TYPE=bri
HOST='eth0 tap0'
BOOTPROTO=static

[andy@timelock ~]$ ls tap0/
ipv4address  ipv4route  options
[andy@timelock ~]$ cat tap0/*
10.10.2.2/8

10.0.0.0/8 via 10.10.1.1

TYPE=tuntap
TUNTYPE=ipip
TUNLOCAL=10.0.2.2
TUNREMOTE=10.0.1.1
TUNTAP_USER=andy
BOOTPROTO=static

[andy@timelock ~]$ ls eth0/
iplink  ipv4address  ipv4route  options
[andy@timelock ~]$ cat eth0/*
mtu 1442
192.168.1.2/24

default via 192.168.1.1

TYPE=eth
MODULE=r8169
BOOTPROTO=static

[andy@timelock ~]$

После команды service network restart,
перестают идти icmp пакеты до шлюза 192.168.1.1 (Dlink-500T),
хотя бридж пингуется.
После удаления интерефейсов br0, tap0, выгрузки модуля r8169,
обратной его загрузки с последующим рестартом сети проблема
исчезает и шлюз вновь пингуется. Проблема с модулем или это моя
ошибка в конфигурировании интерфейсов?

Re: [Comm] проблемы после поднятия bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Thu, Oct 22, 2009 at 01:02:13PM +0400, Andrew Clark wrote:
> Для использования сети в виртуальной машине, требуется поднять
> туннель и объеденить его в бридж с сетевой картой.
[...]
> Настройки интерфейсов:
> 
> [andy@timelock ~]$ ls br0/
> brctl  ipv4address  options
> [andy@timelock ~]$ cat br0/*
> stp AUTO on

Обычно в подобных случаях STP только мешает, как и задержка после
поднятия интерфейса:

stp AUTO off
setfd AUTO 0

> 10.10.1.1/8
> 
> TYPE=bri
> HOST='eth0 tap0'
> BOOTPROTO=static
> 
> [andy@timelock ~]$ ls tap0/
> ipv4address  ipv4route  options
> [andy@timelock ~]$ cat tap0/*
> 10.10.2.2/8
> 
> 10.0.0.0/8 via 10.10.1.1

Назначать собственные IP-адреса интерфейсам, собираемым в мост, не
нужно - все IP переносятся на интерфейс моста, как и маршруты.

> TYPE=tuntap
> TUNTYPE=ipip

ipip - это совсем другой тип туннеля, который для QEMU/KVM не нужен.
Впрочем, при TYPE=tuntap этот параметр всё равно не будет
использоваться (как и TUNLOCAL, TUNREMOTE).

> TUNLOCAL=10.0.2.2
> TUNREMOTE=10.0.1.1
> TUNTAP_USER=andy
> BOOTPROTO=static
> 
> [andy@timelock ~]$ ls eth0/
> iplink  ipv4address  ipv4route  options
> [andy@timelock ~]$ cat eth0/*
> mtu 1442
> 192.168.1.2/24
> 
> default via 192.168.1.1

Настройки IP опять не на месте.

> 
> TYPE=eth
> MODULE=r8169
> BOOTPROTO=static

Пример работающей конфигурации:

$ cd /etc/net/ifaces && grep '^[^#]' eth0{,-br,-tap}/*
eth0/options:ONBOOT=yes
eth0-br/brctl:stp AUTO off
eth0-br/brctl:setfd AUTO 0
eth0-br/ipv4address:192.168.x.y/24
eth0-br/ipv4route:default via 192.168.x.z
eth0-br/options:TYPE=bri
eth0-br/options:HOST='eth0 eth0-tap'
eth0-br/options:ONBOOT=yes
eth0-tap/options:TYPE=tuntap
eth0-tap/options:TUNTAP_USER=vsu
eth0-tap/options:ONBOOT=yes

При этом для виртуальной машины необходимо выделить адрес из той же
подсети 192.168.x.y/24, что и для реальной.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] проблемы после поднятия bridge

[Arcady Ivanov]

Sergey Vlasov пишет:
> On Thu, Oct 22, 2009 at 01:02:13PM +0400, Andrew Clark wrote:
>   
>> Для использования сети в виртуальной машине, требуется поднять
>> туннель и объеденить его в бридж с сетевой картой.
>>     
> [...]
>   
>> Настройки интерфейсов:
>>
>> [andy@timelock ~]$ ls br0/
>> brctl  ipv4address  options
>> [andy@timelock ~]$ cat br0/*
>> stp AUTO on
>>     
>
> Обычно в подобных случаях STP только мешает, как и задержка после
> поднятия интерфейса:
>   
У меня почему-то без STP не очень хотело
работать с VirtualBox. С kvm полегче,
но всех нюансов не помню.
> stp AUTO off
> setfd AUTO 0
>
>   
>> 10.10.1.1/8
>>
>> TYPE=bri
>> HOST='eth0 tap0'
>> BOOTPROTO=static
>>
>> [andy@timelock ~]$ ls tap0/
>> ipv4address  ipv4route  options
>> [andy@timelock ~]$ cat tap0/*
>> 10.10.2.2/8
>>
>> 10.0.0.0/8 via 10.10.1.1
>>     
>
> Назначать собственные IP-адреса интерфейсам, собираемым в мост, не
> нужно - все IP переносятся на интерфейс моста, как и маршруты.
>
>   
>> TYPE=tuntap
>> TUNTYPE=ipip
>>     
>
> ipip - это совсем другой тип туннеля, который для QEMU/KVM не нужен.
> Впрочем, при TYPE=tuntap этот параметр всё равно не будет
> использоваться (как и TUNLOCAL, TUNREMOTE).
>
>   
>> TUNLOCAL=10.0.2.2
>> TUNREMOTE=10.0.1.1
>> TUNTAP_USER=andy
>> BOOTPROTO=static
>>
>> [andy@timelock ~]$ ls eth0/
>> iplink  ipv4address  ipv4route  options
>> [andy@timelock ~]$ cat eth0/*
>> mtu 1442
>> 192.168.1.2/24
>>
>> default via 192.168.1.1
>>     
>
> Настройки IP опять не на месте.
>
>   
>> TYPE=eth
>> MODULE=r8169
>> BOOTPROTO=static
>>     
>
> Пример работающей конфигурации:
>
> $ cd /etc/net/ifaces && grep '^[^#]' eth0{,-br,-tap}/*
> eth0/options:ONBOOT=yes
> eth0-br/brctl:stp AUTO off
> eth0-br/brctl:setfd AUTO 0
> eth0-br/ipv4address:192.168.x.y/24
> eth0-br/ipv4route:default via 192.168.x.z
> eth0-br/options:TYPE=bri
> eth0-br/options:HOST='eth0 eth0-tap'
> eth0-br/options:ONBOOT=yes
> eth0-tap/options:TYPE=tuntap
> eth0-tap/options:TUNTAP_USER=vsu
> eth0-tap/options:ONBOOT=yes
>
> При этом для виртуальной машины необходимо выделить адрес из той же
> подсети 192.168.x.y/24, что и для реальной.
>   
Это неправильное ограничение.
Если в сети есть машины с IP из другой сети,
почему бы виртуальной машине не входить в эту
другую сеть?

-- 
С уважением. Аркадий Иванов
Sincerely yours. Arcady Ivanov
My site: http://www.arccomm.ru

Re: [Comm] проблемы после поднятия bridge

[Andrew Clark]

On 22.10.2009 14:22, Sergey Vlasov wrote:
> Обычно в подобных случаях STP только мешает, как и задержка после
> поднятия интерфейса:
>
> stp AUTO off
> setfd AUTO 0
>   
Я создавал бридж для VirtualBox.
Делал согласно рекомендациям в вики:
http://www.altlinux.org/Etcnet#.D0.9A.D0.B0.D0.BA_.D0.BD.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B8.D1.82.D1.8C_Ethernet-.D0.BC.D0.BE.D1.81.D1.82
> Назначать собственные IP-адреса интерфейсам, собираемым в мост, не
> нужно - все IP переносятся на интерфейс моста, как и маршруты.
>   
Вообще адреса не назначать?

> ipip - это совсем другой тип туннеля, который для QEMU/KVM не нужен.
> Впрочем, при TYPE=tuntap этот параметр всё равно не будет
> использоваться (как и TUNLOCAL, TUNREMOTE).
>   
man tunctl не слишком подробен. Спасибо за информацию.
> Настройки IP опять не на месте.
Почему?
[andy@timelock ~]$ cat eth0/ipv4address
192.168.1.2/24

[andy@timelock ~]$ cat eth0/ipv4route
default via 192.168.1.1

[andy@timelock ~]$
> Пример работающей конфигурации:
> $ cd /etc/net/ifaces && grep '^[^#]' eth0{,-br,-tap}/*
> eth0/options:ONBOOT=yes
> eth0-br/brctl:stp AUTO off
> eth0-br/brctl:setfd AUTO 0
> eth0-br/ipv4address:192.168.x.y/24
> eth0-br/ipv4route:default via 192.168.x.z
> eth0-br/options:TYPE=bri
> eth0-br/options:HOST='eth0 eth0-tap'
> eth0-br/options:ONBOOT=yes
> eth0-tap/options:TYPE=tuntap
> eth0-tap/options:TUNTAP_USER=vsu
> eth0-tap/options:ONBOOT=yes
>
> При этом для виртуальной машины необходимо выделить адрес из той же
> подсети 192.168.x.y/24, что и для реальной.
>   
Благодарю за помощь. Сегодня обязательно попробую.

Re: [Comm] проблемы после поднятия bridge

[Roman Lesnichenko]

22.10.2009 14:11, Arcady Ivanov пишет:

> У меня почему-то без STP не очень хотело
> работать с VirtualBox. С kvm полегче,

какая версия виртуал бокса?
Он уже давно научился все делать сам, без лишних телодвижений и настроек 
мостов руками...

Роман.

Re: [Comm] проблемы после поднятия bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

On Thu, Oct 22, 2009 at 03:19:27PM +0400, Andrew Clark wrote:
> On 22.10.2009 14:22, Sergey Vlasov wrote:
> > Обычно в подобных случаях STP только мешает, как и задержка после
> > поднятия интерфейса:
> >
> > stp AUTO off
> > setfd AUTO 0
> >   
> Я создавал бридж для VirtualBox.
> Делал согласно рекомендациям в вики:
> http://www.altlinux.org/Etcnet#.D0.9A.D0.B0.D0.BA_.D0.BD.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B8.D1.82.D1.8C_Ethernet-.D0.BC.D0.BE.D1.81.D1.82

Ситуации бывают разные; иногда нежелательно, чтобы пакеты STP выходили
во внешнюю сеть.

> > Назначать собственные IP-адреса интерфейсам, собираемым в мост, не
> > нужно - все IP переносятся на интерфейс моста, как и маршруты.
> >   
> Вообще адреса не назначать?

На интерфейс tap при использовании моста - не нужно, только на br0
(или как назвали мост).

> man tunctl не слишком подробен. Спасибо за информацию.

Так у tunctl вся функция - указать пользователя, которому разрешено
использовать устройство; тип tap в tunctl прибит гвоздями, другие
флаги интерфейса tap задаются окончательным его пользователем,
остальные настройки такие же, как у всех сетевых интерфейсов.

Пример конфигурации, который приводится в man tunctl - это некая
"недомаршрутизация" через proxy ARP, в этом случае мост вообще не
нужен (на внешнем интерфейсе хост отвечает на запросы ARP для
гостевого IP из-за явно добавленной в таблицу записи с внешним MAC
хоста и IP гостевой системы; на внутреннем интерфейсе tap выставлен
флаг proxy-arp - опять-таки хост отвечает со своим MAC, назначенным
для интерфейса tap; далее пакеты маршрутизируются обычным образом с
учётом явно прописанного маршрута для гостевого IP; требуется
net.ipv4.ip_forward=1).

Кстати, при использовании моста могут быть не совсем очевидные грабли
с iptables: параметр sysctl net.bridge.bridge-nf-call-iptables по
умолчанию установлен в 1 - это означает, что трафик, проходящий через
мост, также обрабатывается правилами iptables.  Необходимо либо писать
правила с учётом использования моста, либо отключить вызовы iptables
из bridge-nf (там же рядом ещё есть arptables и ip6tables).  А вот
net.ipv4.ip_forward в этом случае можно оставить и в 0 (если 1 не
требуется для других целей) - на работу моста эта настройка не влияет.

> > Настройки IP опять не на месте.
> Почему?
> [andy@timelock ~]$ cat eth0/ipv4address
> 192.168.1.2/24
> 
> [andy@timelock ~]$ cat eth0/ipv4route
> default via 192.168.1.1

Если eth0 включается в мост, все IP переносятся на мост, что, кстати,
написано даже в тех же рекомендациях на вики.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] проблемы после поднятия bridge

[Arcady Ivanov]

Roman Lesnichenko пишет:
> 22.10.2009 14:11, Arcady Ivanov пишет:
>
>> У меня почему-то без STP не очень хотело
>> работать с VirtualBox. С kvm полегче,
>
> какая версия виртуал бокса?
> Он уже давно научился все делать сам, без лишних телодвижений и 
> настроек мостов руками...
На всех версиях VirtualBox до 3.0.4 включительно. Остальные уже не пробовал.
То, что он научился, знаю, использовал.
Старый метод с bridge никто не отменял.

Если немного съехать с темы о bridge, то сеть в VirtualBox
до сих пор содержит в себе странный глюк - не всегда
сразу поднимается в виртуальной Linux-машине.
Несколько раз "service network restart" в виртуальной машине
лечит проблему, пришлось костыль придумать на shell-е.
Из-за этой неустойчивости пришлось отправить VirtualBox в отставку.
Обнаруживалось в Alt 4.1, во многих
Сизифах до 5.0, в Fedora 11, в Debian.
Комбинации Linux-хост/Linux-виртуальная были самые разные.
Прикол в том, что для Linux-host/Windows-виртуальная
этого глюка ни разу не встречал.

Вдобавок скажу, что решал недавно задачу виртуализации
Debian и виртуализации DOS+работа с COM-портом.
Только VMware(VMPlayer) справилась. VirtualBox просто не
работал нормально с COM-портом. Ну и ничего хорошего сказать
нельзя о поддержке USB в OSE-версии.


-- 
С уважением. Аркадий Иванов
Sincerely yours. Arcady Ivanov
My site: http://www.arccomm.ru

Re: [Comm] проблемы после поднятия bridge

[Andrew Clark]

On 22.10.2009 18:53, Sergey Vlasov wrote:

Привел настройки интерфейсов к следующему виду:
[andy@timelock ifaces]$ egrep  '^[^#]' eth0/*
eth0/iplink:mtu 1442
eth0/ipv4address:192.168.1.2/24
eth0/ipv4route:default via 192.168.1.1
eth0/options:TYPE=eth
eth0/options:MODULE=r8169
eth0/options:BOOTPROTO=static
eth0/resolv.conf:search domail timelock
eth0/resolv.conf:nameserver 213.140.228.218
eth0/resolv.conf:nameserver 195.42.162.50
eth0/resolv.conf:nameserver 213.140.231.3
[andy@timelock ifaces]$ egrep  '^[^#]' br0/*
br0/brctl:stp AUTO off
br0/brctl:setfd AUTO 0
br0/ipv4address:192.168.1.3/24
br0/ipv4route:default via 192.168.1.1/24
br0/options:TYPE=bri
br0/options:HOST='eth0 tap0'
br0/options:BOOTPROTO=static
br0/options:ONBOOT=yes
[andy@timelock ifaces]$ egrep  '^[^#]' tap0/*
TYPE=tuntap
TUNTAP_USER=andy
ONBOOT=yes
[andy@timelock ifaces]$

Через некоторое время отваливается гейт:
[andy@timelock ifaces]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
>From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5031ms
, pipe 2
[andy@timelock ifaces]$
Помогает только рестарт сети, причем не надолго.

Re: [Comm] проблемы после поднятия bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

On Tue, Oct 27, 2009 at 09:44:28AM +0300, Andrew Clark wrote:
> Привел настройки интерфейсов к следующему виду:
> [andy@timelock ifaces]$ egrep  '^[^#]' eth0/*
> eth0/iplink:mtu 1442
***> eth0/ipv4address:192.168.1.2/24
***> eth0/ipv4route:default via 192.168.1.1
> eth0/options:TYPE=eth
> eth0/options:MODULE=r8169
> eth0/options:BOOTPROTO=static
***> eth0/resolv.conf:search domail timelock
***> eth0/resolv.conf:nameserver 213.140.228.218
***> eth0/resolv.conf:nameserver 195.42.162.50
***> eth0/resolv.conf:nameserver 213.140.231.3

Помеченное "***" - убрать из eth0 и перенести в br0 (хотя resolv.conf,
вероятно, может и так работать, поскольку не трогает сам интерфейс).

> [andy@timelock ifaces]$ egrep  '^[^#]' br0/*
> br0/brctl:stp AUTO off
> br0/brctl:setfd AUTO 0
> br0/ipv4address:192.168.1.3/24

Так разберитесь, какой адрес вы хотите использовать для самого хоста -
192.168.1.2, 192.168.1.3, или по какой-то причине нужны оба?  Адрес
для виртуальной машины здесь вообще не прописывается - он будет
присутствовать только в настройках внутри самой ВМ.

> br0/ipv4route:default via 192.168.1.1/24

"/24" тут совсем лишнее.

> br0/options:TYPE=bri
> br0/options:HOST='eth0 tap0'
> br0/options:BOOTPROTO=static
> br0/options:ONBOOT=yes
> [andy@timelock ifaces]$ egrep  '^[^#]' tap0/*
> TYPE=tuntap
> TUNTAP_USER=andy
> ONBOOT=yes

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] проблемы после поднятия bridge

[Andrew Clark]

On 27.10.2009 13:27, Sergey Vlasov wrote:
>
> Помеченное "***" - убрать из eth0 и перенести в br0 (хотя resolv.conf,
> вероятно, может и так работать, поскольку не трогает сам интерфейс).
>   
Получается, у меня сетевые интерфейсы выглядят так:
  
      br0
  /           \ 
.------------,
| eth0 | tap0 |
`------------'

Поэтому, надо все настройки eth0 переносить на br0?
> Так разберитесь, какой адрес вы хотите использовать для самого хоста -
> 192.168.1.2,
Для хоста мне нужен 192.168.1.2
>  192.168.1.3, или по какой-то причине нужны оба?  Адрес
> для виртуальной машины здесь вообще не прописывается - он будет
> присутствовать только в настройках внутри самой ВМ.
>   
Вот оно что, я думал адрес для виртуальной машины надо
задавать не из нее, а сразу при создании интерфейса.
>   
>> br0/ipv4route:default via 192.168.1.1/24
>>     
> "/24" тут совсем лишнее.
Без cidr маску подсети поймет?

Re: [Comm] проблемы после поднятия bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Tue, Oct 27, 2009 at 01:59:11PM +0300, Andrew Clark wrote:
> Получается, у меня сетевые интерфейсы выглядят так:
>   
>       br0
>   /           \ 
> .------------,
> | eth0 | tap0 |
> `------------'
> 
> Поэтому, надо все настройки eth0 переносить на br0?

Да, именно так.

> > Так разберитесь, какой адрес вы хотите использовать для самого хоста -
> > 192.168.1.2,
> Для хоста мне нужен 192.168.1.2
> >  192.168.1.3, или по какой-то причине нужны оба?  Адрес
> > для виртуальной машины здесь вообще не прописывается - он будет
> > присутствовать только в настройках внутри самой ВМ.
> >   
> Вот оно что, я думал адрес для виртуальной машины надо
> задавать не из нее, а сразу при создании интерфейса.

При создании - только при организации на хосте маршрутизатора для ВМ,
а не моста; но опять-таки тогда на хосте назначается его собственный
адрес в виртуальной сети, а адрес для ВМ в явном виде не присутствует.
Разве что можно вбить адрес, назначенный для ВМ, в правила iptables
для защиты от нежелательных действий со стороны ВМ.

> >> br0/ipv4route:default via 192.168.1.1/24
> >>     
> > "/24" тут совсем лишнее.
> Без cidr маску подсети поймет?

Так это же адрес шлюза, маска тут не нужна.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] проблемы после поднятия bridge

[Andrew Clark]

On 27.10.2009 15:06, Sergey Vlasov wrote:
> On Tue, Oct 27, 2009 at 01:59:11PM +0300, Andrew Clark wrote:
>   
>> Получается, у меня сетевые интерфейсы выглядят так:
>>   
>>       br0
>>   /           \ 
>> .------------,
>> | eth0 | tap0 |
>> `------------'
>>
>> Поэтому, надо все настройки eth0 переносить на br0?
>>     
> Да, именно так.
>   
Поправил согласно рекомендации,
все равно через некоторое время icmp
пакеты перестают ходить до шлюза.

[andy@timelock ifaces]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
>From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5031ms
, pipe 2
[andy@timelock ifaces]$

Re: [Comm] проблемы после поднятия bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Tue, Oct 27, 2009 at 04:54:10PM +0300, Andrew Clark wrote:
> Поправил согласно рекомендации,
> все равно через некоторое время icmp
> пакеты перестают ходить до шлюза.
> 
> [andy@timelock ifaces]$ ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> >From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
> >From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
> ^C
> --- 192.168.1.1 ping statistics ---
> 6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5031ms
> , pipe 2

А в правилах iptables что-то есть?  Сделайте на всякий случай:

  echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
  echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
  echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

Если это не поможет - придётся смотреть на вывод команд:

  ip addr
  ip route
  brctl show

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] проблемы после поднятия bridge

[Andrew Clark]

On 27.10.2009 18:38, Sergey Vlasov wrote:

К сожалению, не помогло:
[root@timelock ifaces]# grep '^[^#]' ???0/*
eth0/options:ONBOOT=yes
tap0/options:TYPE=tuntap
tap0/options:TUNTAP_USER=andy
tap0/options:ONBOOT=yes
[root@timelock ifaces]# grep '^[^#]' ??0/*
br0/brctl:stp AUTO off
br0/brctl:setfd AUTO 0
br0/iplink:mtu 1442
br0/ipv4address:192.168.1.2
br0/ipv4route:default via 192.168.1.1
br0/options:TYPE=bri
br0/options:HOST='eth0 tap0'
br0/options:MODULE=r8169
br0/options:BOOTPROTO=static
br0/options:ONBOOT=yes
br0/resolv.conf:search domail timelock
br0/resolv.conf:nameserver 213.140.228.218
br0/resolv.conf:nameserver 195.42.162.50
br0/resolv.conf:nameserver 213.140.231.3
[root@timelock ifaces]# chkconfig --list | awk '{print $1,$7}' | grep ip
iptables 5:off
ipw3945d 5:off
[root@timelock ifaces]# echo 0 >
/proc/sys/net/bridge/bridge-nf-call-arptables
[root@timelock ifaces]# echo 0 >
/proc/sys/net/bridge/bridge-nf-call-ip6tables
[root@timelock ifaces]# echo 0 >
/proc/sys/net/bridge/bridge-nf-call-iptables
[root@timelock ifaces]# ip addr
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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc pfifo_fast
state UNKNOWN qlen 1000
    link/ether 00:1d:7d:01:01:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0
3: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 500
    link/ether 9a:16:06:10:84:1a brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue state
UNKNOWN
    link/ether 00:1d:7d:01:01:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/32 scope global br0
[root@timelock ifaces]# ip route
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3
default via 192.168.1.1 dev eth0
[root@timelock ifaces]# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.001d7d010105       no              eth0
                                                        tap0
[root@timelock ifaces]#

Re: [Comm] проблемы после поднятия bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Tue, Oct 27, 2009 at 09:23:05PM +0300, Andrew Clark wrote:
> К сожалению, не помогло:
> [root@timelock ifaces]# grep '^[^#]' ???0/*
> eth0/options:ONBOOT=yes
> tap0/options:TYPE=tuntap
> tap0/options:TUNTAP_USER=andy
> tap0/options:ONBOOT=yes
> [root@timelock ifaces]# grep '^[^#]' ??0/*
> br0/brctl:stp AUTO off
> br0/brctl:setfd AUTO 0
> br0/iplink:mtu 1442
> br0/ipv4address:192.168.1.2

В ipv4address должен быть адрес с маской - 192.168.1.2/24.

> br0/ipv4route:default via 192.168.1.1
> br0/options:TYPE=bri
> br0/options:HOST='eth0 tap0'
> br0/options:MODULE=r8169

MODULE по-прежнему относится к eth0, а не к br0 - этот параметр не
надо было трогать.

> br0/options:BOOTPROTO=static
> br0/options:ONBOOT=yes
> br0/resolv.conf:search domail timelock
> br0/resolv.conf:nameserver 213.140.228.218
> br0/resolv.conf:nameserver 195.42.162.50
> br0/resolv.conf:nameserver 213.140.231.3
> [root@timelock ifaces]# chkconfig --list | awk '{print $1,$7}' | grep ip
> iptables 5:off
> ipw3945d 5:off
> [root@timelock ifaces]# echo 0 >
> /proc/sys/net/bridge/bridge-nf-call-arptables
> [root@timelock ifaces]# echo 0 >
> /proc/sys/net/bridge/bridge-nf-call-ip6tables
> [root@timelock ifaces]# echo 0 >
> /proc/sys/net/bridge/bridge-nf-call-iptables
> [root@timelock ifaces]# ip addr
> 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
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc pfifo_fast
> state UNKNOWN qlen 1000
>     link/ether 00:1d:7d:01:01:05 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0

Тут залип старый адрес, которого в конфигурации уже нет.

> 3: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
>     link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
> 4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 500
>     link/ether 9a:16:06:10:84:1a brd ff:ff:ff:ff:ff:ff
> 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue state
> UNKNOWN
>     link/ether 00:1d:7d:01:01:05 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.2/32 scope global br0

А тут из-за отсутствовавшей в br0/ipv4address маски получилось /32.

> [root@timelock ifaces]# ip route
> 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3
> default via 192.168.1.1 dev eth0

И маршрут из-за наличия старого адреса и неверной маски на br0 тоже
смотрит не на тот интерфейс.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] проблемы после поднятия bridge

[Andrew Clark]

On 27.10.2009 22:40, Sergey Vlasov wrote:
> On Tue, Oct 27, 2009 at 09:23:05PM +0300, Andrew Clark wrote:
>   
> В ipv4address должен быть адрес с маской - 192.168.1.2/24.

> MODULE по-прежнему относится к eth0, а не к br0 - этот параметр не
> надо было трогать.
>
> Тут залип старый адрес, которого в конфигурации уже нет.А тут из-за отсутствовавшей в br0/ipv4address маски получилось /32.
> И маршрут из-за наличия старого адреса и неверной маски на br0 тоже
> смотрит не на тот интерфейс.
>   
Отвечаю спустя некоторое время, потому что решил потестировать и
убедится, что все работает как надо.
Большое спасибо за помощь, бридж заработал нормально, после того, как я
удалил VirtualBox (хотя можно было
выгрузить модули и выключить его через chkconfig). Мои рабочие настройки
(может кто заглянет в архив рассылки):

[andy@timelock ~]$ grep '^[^#]' ??0/*
br0/brctl:stp AUTO off
br0/brctl:setfd AUTO 0
br0/iplink:mtu 1442
br0/ipv4address:192.168.1.2/24
br0/ipv4route:default via 192.168.1.1
br0/options:TYPE=bri
br0/options:HOST='eth0 tap0'
br0/options:BOOTPROTO=static
br0/options:ONBOOT=yes
br0/resolv.conf:search domail timelock
br0/resolv.conf:nameserver 213.140.228.218
br0/resolv.conf:nameserver 195.42.162.50
br0/resolv.conf:nameserver 213.140.231.3
[andy@timelock ~]$ grep '^[^#]' ???0/*
eth0/options:TYPE=eth
eth0/options:MODULE=r8169
eth0/options:BOOTPROTO=static
eth0/options~:TYPE=eth
eth0/options~:MODULE=r8169
eth0/options~:BOOTPROTO=static
eth0/resolv.conf:search domail timelock
eth0/resolv.conf:nameserver 213.140.228.218
eth0/resolv.conf:nameserver 195.42.162.50
eth0/resolv.conf:nameserver 213.140.231.3
tap0/options:TYPE=tuntap
tap0/options:TUNTAP_USER=andy
tap0/options:ONBOOT=yes
[andy@timelock ~]$

Сергей, подскажите пожалуйста, с какими параметрами Вы запускаете kvm?