2 vlan, одна подсеть dhcp

Hint: DHCP работает на L2, маршрутизация там не при делах

в чем может быть дело?

Да Бог его знает...
Надо смотреть конфигурацию портов

vlan'ы показать?
Оказалось, что ip отдается dhcp модема, но тормозит минуту перед этим и по факту телефония не заводится.
Если же провод напрямую в сервер - заводится моментально всё.

А коммутатор у тебя маршрутизирующий? Такое возможно если сети пересекаются на вланах, но тогда не только dhcp не работало бы, но и в целом сеть.

Да, вот схема на картинке: http://sysadmins.ru/files/b2_issue_696.png
Получается что на виртуалке (V1), мостом соединенная с vlan120 все отлично.
А на виртуалке V2, мостом соединенный с vlan121 проблемы

вланы эти где терминируются? покажи настройки модема/коммутатора

На модеме
LAN Host Settings:
IP address: 192.168.7.1
Subnet mask: 255.255.255.0
DHCP Server:
DHCP server: Enabled
Start IP: 192.168.7.2
End IP: 192.168.7.254

DHCP Serving Pool
Device type: STB
DHCP serving pool: Enabled
Start IP address: 0.0.0.0
End IP address: 0.0.0.0
DHCP relay: Disabled

WAN Connection
Lan1 (интернет)
WAN5_INTERNET_B_ATM1_0_33 PPPoE_Bridged

Lan2 (телефония)
WAN4_INTERNET_R_ATM5_2_35 IP_Routed (IP)

Конфигурация вланов CISCO SG300 на скрине:
http://sysadmins.ru/files/cisco_settings_929.png

Терминируются на proxmox'е

В сетях и цисках не силён, но насколько я понял, у тебя все порты в режиме trunk.

А модем свой трафик сам не тегирует. Соответственно весь его трафик, вместе с dhcp попадает в default vlan (0).

Повесь на циске на порты модема access mode.

switchport mode access
switchport access vlan 120

Тогда циска весь трафик с порта модема будет тегировать 120/121 вланом.

Так трафик с модема идет по двум портам.
На модеме 2 wan: один для интернета, второй для телефонии. В нем же и настроено - интернет отдавать только в первый порт, телефонию во второй.

какаято мутная схема, настройки интерфейсов модема где? или подсеть 192.168.7.0/24 работает на обоих lan? И где у тебя настроено в 1 порт отдавать интернет, а в другой телефонию?

А модем тегирует 120 и 121 vlan'ом тот трафик, который он отдаёт? Если нет, то весь этот трафик попадает в default vlan. А в 120 и 121 вланах он не виден.

Попробуй проверить, прописав руками ip виртуалке и попинговать/телнетить модем (шлюз). И, если есть возможность попинговать с модема виртуалку.

Ну и ещё я не понял в ОП:

Если отключить кабель из коммутатора B1 (vlan120) – тогда виртуалка получает ip.

Поясни по подробнее.

«Поясни по подробнее.» Если напрямую в порт сервера кабель вставить - всё работает как надо.

у него модем включен 2 портами в коммутатор, и первый порт на коммутаторе имеет pvid 120, второй порт имеет pvid 121, если я все прально понял, мне больше понятно sh ru в консоли.

swelf, всё правильно.
не знаю в какую сторону капать....

Вся соль в том, что:
1. интернет бегает с pvid 120 без проблем
2. если с pvid 121 порта коммутатора вынуть кабель и вставить его в сетевую сервера всё работает на ура.

В модеме порты lan1 и lan2 я так понял представляют из себя свой внутренний коммутатор, а коммутатор запоминает mac на порту на который пришел пакет.

В итоге, если у тебя маки в вланах 120 и 121 одинаковые на твоем сервере(как кстати организованна сеть с виртуалками, бридж, нат, еще что-то?), пусть 00.11.22.33.44.55.66, то происходит следующее, виртуалка делает запрос в порт lan1, коммутатор запоминает мак 00.11.22.33.44.55.66 но порту lan1, и тут же прилетает какойто «мусорный» пакет с влана 121 в порт lan2 с тем же маком, циска то понимает, что вланы разные и нормально работает, но модем перезаписывает мак 00.11.22.33.44.55.66 на порт lan2, и ответ dhcp сервера улетает уже в lan2 и vlan121, хотя запрос пришел с влана 120 в порт lan1.

Это только предположение, проверь маки на вланах на сервере, и сделай их разными, если они одинаковые.

или уйди от схемы с вланами, модем их все равно не понимает, у тебя какаято херь в итоге получается

я думаю все станет очевидно если снять дамп на твоем сервере командой

tcpdump -i eth0 -e

если трафика не очень много.

На виртуалки сеть как бридж идет.
Маки разные на виртуалках...

36:98:8c:21:41:c5 - это мак виртуалки в момент, когда она идет в vlan121, дабы получить от модема ip, но его не получает

tcpdump был запущено на самом proxmox

22:30:48.159171 36:98:8c:21:41:c5 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 121, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 36:98:8c:21:41:c5 (oui Unknown), length 300

22:30:48.306750 00:25:90:9b:6b:2f (oui Unknown) > 01:00:5e:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 50: vlan 121, p 0, ethertype IPv4, 0.0.0.0 > all-systems.mcast.net: igmp query v2

22:30:48.306761 00:25:90:9b:6b:2f (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 90: vlan 121, p 0, ethertype IPv6, 756e:6e69:6e67:223a:100:: > ip6-allnodes: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24

22:30:48.475188 20:4c:9e:6e:ae:65 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.20:4c:9e:6e:ae:5b.803a, length 43

22:30:50.475171 20:4c:9e:6e:ae:65 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.20:4c:9e:6e:ae:5b.803a, length 43

22:30:51.277767 00:25:90:9b:6b:2f (oui Unknown) > 01:00:5e:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 50: vlan 130, p 0, ethertype IPv4, 0.0.0.0 > all-systems.mcast.net: igmp query v2

22:30:51.277777 00:25:90:9b:6b:2f (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 90: vlan 130, p 0, ethertype IPv6, 102:417::e000:1:9404:0 > ip6-allnodes: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24

22:30:52.475143 20:4c:9e:6e:ae:65 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.20:4c:9e:6e:ae:5b.803a, length 43

У модема на lan и stb портах кадры нетегированные. Если ты соединяешь кабелем порт сервера и stb порт модема, и «все работает», значит порт сервера тоже нетегированный, и виртуалка ждет нетегированных кадров. А как настроен порт сервера, соединенный кабелем с коммутатором? Должен быть настроен так же как порт коммутатора, т.е тегированный. Кадры с тегом 121, получаемые на этом порту сервером, должны бриджеваться в виртуалку без тега.

ilyap, всё верно.
eth0 - интерфейс с физическим кабелем коммутатора DGS-1500-28p (для локальной сети)
eth1 - интерфейс с физическим кабелем коммутатора SG300-10
eth3 - физическая четвертая сетевая в сервере
порт сервера настроен:
eth0 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2e
vmbr0 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2e

eth1 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f
eth1.1 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f
eth1.110 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f
eth1.120 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f
eth1.121 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f

vmbr1 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f

eth3 Link encap:Ethernet HWaddr a0:36:9f:24:c5:06
vmbr3 Link encap:Ethernet HWaddr a0:36:9f:24:c5:06

На виртуальный сервер 1 (V1 на схеме идет - коммутатор), т.е. по сути он в виртуалке уже не тегированный:
vmbr0 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2e
vmbr1v1 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f (vlan1 - коммутатор)
vmbr1v110 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f (vlan110 - ethernet провайдер)
vmbr1v120 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f (vlan120 - adsl интернет)

На виртуальный сервер 2 (V2 на схеме идет - коммутатор)
vmbr0 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2e (локальная сеть)
vmbr1v121 Link encap:Ethernet HWaddr 00:25:90:9b:6b:2f (vlan121 - телефония)

на виртуалке V2
vmbr0 => eth0
vmbr1v121 => eth1

Ну вот, сейчас наверное всем станет понятнее :)
Если на виртуалке V2 вместо vmbr1v121 прокинунть vmbr3 к eth1, то всё работает.
Приходит мысль, что это из-за одинаковых маков, но т.к. это бриджи, то виртуалки передают свои маки - поэтому вроде вариант отпадает.

Если на виртуалке V2 вместо vmbr1v121 прокинуть vmbr3 к eth1, то всё работает.

1) vmbr0 - виртуальный интерфейс, связанный с физическим eth0 на сервере proxmox, который подключен к DGS-1500-28p
vmbr1 - виртуальный интерфейс, связанный с физическим eth1 на сервере proxmox, который подключен к циске
Похоже, что на виртуалку V2 идёт трафик с vmbr3, а должно быть, по идее, с vmbr1v121
2) Покажи вывод tcpdump изнутри V2 для обоих вариантов.

На свиче все порты кроме 10 (куда подключен сервер) должны быть access (каждый в своём vlan). Порт GE10 - trunk, с разрешением или всех vlan или только нужных.

На сервере vmbrXvYYY должно попасть в в vlan YYY. В госте будет 2 интерфейса vmbr - в этом же цель?

Для проверок - оторвать временно интернет-интерфейс от гостя и смотреть (можно оторвать все лишнии локалки тоже):

1. Как идет изучение MAC на свиче, на сервере, в виртуалке (не забыть сгенирировать трафика немного).

2. Если маки изучены - dhcp реквесты должны проходить.

3. Подключаем интернет-интерфейс и смотрим еще раз не сломалось ли где чего.

4 порта поставил в access, GE10 в trunk. Немного почитал об этом, спасибо за подсказку.
Но дело было не в этом, а в STP петле похоже
Если Spanning Tree State отключить, тогда все заводится на ура и похоже все работает. (GE3 = vlan121)
К сожалению не очень я силен в этом.
Полагаю, т.к. образовывается петля, то отключать Spanning Tree State не правильно?
Как всё сделать правильно?
STP настройки на коммутаторе
http://sysadmins.ru/files/stp_346.png

Думаю, вы уже все решили, но тем не менее.

GE3 попал Discarding т.е. отключен по сути.

Нарисуйте для себя картинку всех L2 соединений (включая bridging и виртуальные коммутаторы если есть) и поищите что вызывает петли. Нужно обратить особое внимание на native vlan на транке - по умолчанию это vlan 1 трафик. Таким образом untagged фреймы на транке попадут в vlan 1. stp bpdu передаются в транке как раз untagged фреймами. Может быть у вас на сервере есть странный бридж для такого трафика или эти bpdu проваливаются куда-то еще.

Посмотрите show interface switchport gi10.

Посмотрите в логах на sg300 - нет ли там какой пользы?

Если проблема еще есть - покажите sh run, sh interfaces, sh int switchport и схемы (можно и sh tech куда-нить прилепить).