Казалось бы, тривиальная схема включения. С коммутатора(R1) абоненту отдаётся транком 2 влана, он принимает их свитчом(SW1), один отдаёт в роутер(vlan 3), другой в cisco свитч(R2), который выступает в роли power-инжектора для подключения видеокамеры(изображено в виде компьютера C1). vlan 3 работает нормально (абонентский роутер, который не изображён на картинке), vlan 2 нет (видеокамера, подключенная к свитчу). При этом, если подключить камеру напрямую в SW1, то она работает нормально.

На R2 конфигурация очень простая:

vlan database
 vlan 2
exit
!
interface FastEthernet1/0
 switchport access vlan 2
end
!
interface FastEthernet1/1
 switchport access vlan 2
end
!
interface Vlan2
 ip address 192.0.2.2 255.255.255.252
end

Со стороны ISP, конфигурация R1 тоже тривиальная:

vlan database
 vlan 2
 vlan 3
exit
!
interface FastEthernet1/0
 switchport mode trunk
 switchport trunk allowed vlan 1-3,1002-1005
end
!
interface Vlan2
 ip address 192.0.2.1 255.255.255.252
end

(на вланы 1 и 1002-1005 можно не обращать внимание)

Коммутатор SW1 занимается просто тегированием/растегированием vlan 2, его конфигурация такова:

(больше он ничего и не умеет)

Для лабораторного стенда в качестве R1 и R2 использовался виртуальный(gns3/dynamips) роутер c3745 со свитчинговой платой NM-16ESW в первом слоту, с ПО C3745-A3JK9S-M 12.3(4)T2 (C3745-A3.bin) . SW1 – это стандартный свитч из gns3. C1 – любой хост.

Со стороны провайдера всё хорошо, физика в апе, interface vlan тоже, spanning-tree ничего не заблокировал:

R1#show int fa1/0 status  
Port    Name               Status       Vlan       Duplex Speed Type
Fa1/0                      connected    trunk      a-full   a-100 unknown

R1#show int vlan 2 | i line protocol
Vlan2 is up, line protocol is up 

R1#show spanning-tree int fa1/0 brief                  
Vlan                                        Designated
Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID
-------------------- ------- ---- ----- --- ----- -------------------- -------
VLAN1                128.41   128    19 FWD     0 32768 c403.181e.0000 128.41 
VLAN2                128.41   128    19 FWD     0 32768 c403.181e.0001 128.41 
VLAN3                128.41   128    19 FWD     0 32768 c403.181e.0002 128.41 

Что происходит со стороны кастомера неизвестно. Считается лишь, что с физикой всё в порядке и оборудование исправно, но при добавлении R2 между камерой и SW1 трафик в vlan 3 не ходит.

Оказывается, корень проблемы в том, что со стороны ISP отправляются тегированные pvst+ фреймы (от R1 к SW1):

Затем, они растегируются на SW1 и уходят в сторону R2 без dot1Q-тега, что с точки зрения (включенного по умолчанию) pvst+ является неправильным. Достотаточно заглянуть в логи на R2 и увидеть там такое:

*Mar  1 00:12:52.575: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet1/0 VLAN2.
*Mar  1 00:12:52.575: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet1/0 on VLAN2. Inconsistent port type.

(логи могут быть не включены, тогда их нужно включать командой logging buffered debug)

Правильное решение проблемы – прекратить отправлять stp BPDU со стороны ISP(и вообще, исключить stp из сети, где это возможно), обходное – выключить stp в vlan 2 на стороне клиента:

R2(config)#no spanning-tree vlan 2
R2#ping 192.0.2.1                            

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/23/32 ms