VLAN и прием нетегированных пакетов

Доброе времени суток!
Есть задача соединить маршрутизатор с linux машиной транковым линком.
Исходные данные:
1. Маршрутизатора Nateks-RT-3806
2. Linux
Linux# uname -a
Linux myhost 3.3.4-1-ARCH #1 SMP PREEMPT Sat Apr 28 00:21:22 CEST 2012 x86_64 Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz GenuineIntel GNU/Linux
3. Транковый линк: eth0 на linux и G0/0 на маршрутизаторе. Поднято 3 vlan:
11 - 192.168.11.0/24
12 - 192.168.12.0/24
13 - 192.168.13.0/24

Настройки оборудования:
1. Маршрутизатор
Router#show runnnig-config
!
service timestamps log date
service timestamps debug date
no service password-encryption
!
isdn switch-type basic-5ess
!
interface GigaEthernet0/0
 no ip address
 no ip directed-broadcast
!
interface GigaEthernet0/0.11 
 ip address 192.168.11.1 255.255.255.0
 ip directed-broadcast
 encapsulation dot1Q 11
 bandwidth 1000000
 delay 1
!
interface GigaEthernet0/0.12 
 ip address 192.168.12.1 255.255.255.0
 no ip directed-broadcast
 encapsulation dot1Q 12
 bandwidth 1000000
 delay 1
!
interface GigaEthernet0/0.13 
 ip address 192.168.13.1 255.255.255.0
 no ip directed-broadcast
 encapsulation dot1Q 13
 bandwidth 1000000
 delay 1
!
interface GigaEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 no ip directed-broadcast
!
interface Async0/0
 no ip address
 no ip directed-broadcast
!
2. Linux
Linux# modprobe 8021q
Linux# ip link add link eth0 name vlan11 type vlan id 11
Linux# ip addr add 192.168.11.2/24 brd + dev vlan11
Linux# ip link add link eth0 name vlan12 type vlan id 12
Linux# ip addr add 192.168.12.2/24 brd + dev vlan12
Linux# ip link add link eth0 name vlan13 type vlan id 13
Linux# ip addr add 192.168.13.2/24 brd + dev vlan13
Linux# ip link set eth0 up
Linux# ip link set vlan11 up
Linux# ip link set vlan12 up
Linux# ip link set vlan13 up
Linux# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
4: vlan11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
6: vlan12@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
7: vlan13@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
Linux# 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 UP qlen 1000
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::222:64ff:fe72:e5/64 scope link 
       valid_lft forever preferred_lft forever
4: vlan11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.2/24 brd 192.168.11.255 scope global vlan11
    inet6 fe80::222:64ff:fe72:e5/64 scope link 
       valid_lft forever preferred_lft forever
6: vlan12@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.12.2/24 brd 192.168.12.255 scope global vlan12
    inet6 fe80::222:64ff:fe72:e5/64 scope link 
       valid_lft forever preferred_lft forever
7: vlan13@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:22:64:72:00:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.13.2/24 brd 192.168.13.255 scope global vlan13
    inet6 fe80::222:64ff:fe72:e5/64 scope link 
       valid_lft forever preferred_lft forever

Тестирование
1. Делаем пинг любого из трёх интерфейсов маршрутизатора и получаем следующее:
Linux# ping 192.168.13.1
PING 192.168.13.1 (192.168.13.1) 56(84) bytes of data.
From 192.168.13.2 icmp_seq=1 Destination Host Unreachable
From 192.168.13.2 icmp_seq=2 Destination Host Unreachable
From 192.168.13.2 icmp_seq=3 Destination Host Unreachable
Router# debug arp
2012-5-12 06:27:02 IP ARP: rcvd req src 192.168.13.2 00:22:64:72:00:e5, dst 192.168.13.1, GigaEthernet0/0.13
2012-5-12 06:27:02 IP ARP: creating entry for IP address: 192.168.13.2, hw: 00:22:64:72:00:e5
2012-5-12 06:27:02 IP ARP: sent reply src 192.168.13.1 00:e0:0f:85:15:71, dst 192.168.13.2 00:22:64:72:00:e5, GigaEthernet0/0.13
2012-5-12 06:27:03 IP ARP: rcvd req src 192.168.13.2 00:22:64:72:00:e5, dst 192.168.13.1, GigaEthernet0/0.13
2012-5-12 06:27:03 IP ARP: sent reply src 192.168.13.1 00:e0:0f:85:15:71, dst 192.168.13.2 00:22:64:72:00:e5, GigaEthernet0/0.13
2012-5-12 06:27:04 IP ARP: rcvd req src 192.168.13.2 00:22:64:72:00:e5, dst 192.168.13.1, GigaEthernet0/0.13
2012-5-12 06:27:04 IP ARP: sent reply src 192.168.13.1 00:e0:0f:85:15:71, dst 192.168.13.2 00:22:64:72:00:e5, GigaEthernet0/0.13
Linux# tcpdump -n -e -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:38:52.815068 00:22:64:72:00:e5 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 13, p 0, ethertype ARP, Request who-has 192.168.13.1 tell 192.168.13.2, length 28
13:38:52.815376 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype ARP (0x0806), length 56: Reply 192.168.13.1 is-at 00:e0:0f:85:15:71, length 42
13:38:53.817964 00:22:64:72:00:e5 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 13, p 0, ethertype ARP, Request who-has 192.168.13.1 tell 192.168.13.2, length 28
13:38:53.818242 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype ARP (0x0806), length 56: Reply 192.168.13.1 is-at 00:e0:0f:85:15:71, length 42
13:38:54.821288 00:22:64:72:00:e5 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 13, p 0, ethertype ARP, Request who-has 192.168.13.1 tell 192.168.13.2, length 28
13:38:54.821580 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype ARP (0x0806), length 56: Reply 192.168.13.1 is-at 00:e0:0f:85:15:71, length 42
Linux# tcpdump -n -e -i vlan13
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan13, link-type EN10MB (Ethernet), capture size 65535 bytes
13:41:26.360231 00:22:64:72:00:e5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.13.1 tell 192.168.13.2, length 28
13:41:27.361267 00:22:64:72:00:e5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.13.1 tell 192.168.13.2, length 28
13:41:28.364617 00:22:64:72:00:e5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.13.1 tell 192.168.13.2, length 28
Linux# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.13.1                     (incomplete)                              vlan13

2. Добавляем статические mac-адресса в linux и на маршрутизаторе (для примера демонстрирую как это делал в linux)
Linux# arp -s 192.168.11.1 00:e0:0f:85:15:71
Linux# arp -s 192.168.12.1 00:e0:0f:85:15:71
Linux# arp -s 192.168.13.1 00:e0:0f:85:15:71
Linux# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.12.1             ether   00:e0:0f:85:15:71   CM                    vlan12
192.168.13.1             ether   00:e0:0f:85:15:71   CM                    vlan13
192.168.11.1             ether   00:e0:0f:85:15:71   CM                    vlan11
И повторяем все манипуляции описанные выше:
Linux# ping 192.168.13.1
PING 192.168.13.1 (192.168.13.1) 56(84) bytes of data.
64 bytes from 192.168.13.1: icmp_req=1 ttl=255 time=0.286 ms
64 bytes from 192.168.13.1: icmp_req=2 ttl=255 time=0.286 ms
64 bytes from 192.168.13.1: icmp_req=3 ttl=255 time=0.286 ms
Linux# tcpdump -n -e -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:09:11.871492 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype 802.1Q (0x8100), length 102: vlan 13, p 0, ethertype IPv4, 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 15, length 64
13:09:11.871743 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype IPv4 (0x0800), length 98: 192.168.13.1 > 192.168.13.2: ICMP echo reply, id 3278, seq 15, length 64
13:09:12.871492 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype 802.1Q (0x8100), length 102: vlan 13, p 0, ethertype IPv4, 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 16, length 64
13:09:12.871746 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype IPv4 (0x0800), length 98: 192.168.13.1 > 192.168.13.2: ICMP echo reply, id 3278, seq 16, length 64
13:09:13.871492 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype 802.1Q (0x8100), length 102: vlan 13, p 0, ethertype IPv4, 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 17, length 64
13:09:13.871745 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype IPv4 (0x0800), length 98: 192.168.13.1 > 192.168.13.2: ICMP echo reply, id 3278, seq 17, length 64
13:09:14.871481 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype 802.1Q (0x8100), length 102: vlan 13, p 0, ethertype IPv4, 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 18, length 64
13:09:14.871748 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype IPv4 (0x0800), length 98: 192.168.13.1 > 192.168.13.2: ICMP echo reply, id 3278, seq 18, length 64
13:09:15.871479 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype 802.1Q (0x8100), length 102: vlan 13, p 0, ethertype IPv4, 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 19, length 64
13:09:15.871747 00:e0:0f:85:15:71 > 00:22:64:72:00:e5, ethertype IPv4 (0x0800), length 98: 192.168.13.1 > 192.168.13.2: ICMP echo reply, id 3278, seq 19, length 64
Linux# tcpdump -n -e -i vlan13
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan13, link-type EN10MB (Ethernet), capture size 65535 bytes
13:10:00.873381 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype IPv4 (0x0800), length 98: 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 64, length 64
13:10:01.872382 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype IPv4 (0x0800), length 98: 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 65, length 64
13:10:02.871473 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype IPv4 (0x0800), length 98: 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 66, length 64
13:10:03.871491 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype IPv4 (0x0800), length 98: 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 67, length 64
13:10:04.871475 00:22:64:72:00:e5 > 00:e0:0f:85:15:71, ethertype IPv4 (0x0800), length 98: 192.168.13.2 > 192.168.13.1: ICMP echo request, id 3278, seq 68, length 64
Пинги проходят на все 3 интерфейса.

Резюме
Непонятен факт работы vlan в linux. Как ping, так и arp поступают на подинтерфейс в нетегированом виде, на выходе с него добавляется <VLANID> и поступает на родительский интерфейс eth0 и далее на маршратизатор. Вот только ответы возвращаются в нетегированном виде и оседают на eth0. Причем arp отклик считается что не доставлен, так как он вернулся на инетерфейс eth0, а не на соответствующий подинтерфейс. Ping считается вернувшимся ответом, хотя на подинтерфейс он так же как и arp не проходит. Это подтверждается вышеизложенным и нижеизложенными счетчиками.
Linux# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet6 fe80::222:64ff:fe72:e5  prefixlen 64  scopeid 0x20<link>
        ether 00:22:64:72:00:e5  txqueuelen 1000  (Ethernet)
        RX packets 567  bytes 41338 (40.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 603  bytes 38830 (37.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436  metric 1
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 321  bytes 34712 (33.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 321  bytes 34712 (33.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
vlan11: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 192.168.11.2  netmask 255.255.255.0  broadcast 192.168.11.255
        inet6 fe80::222:64ff:fe72:e5  prefixlen 64  scopeid 0x20<link>
        ether 00:22:64:72:00:e5  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 321  bytes 19018 (18.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
vlan12: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 192.168.12.2  netmask 255.255.255.0  broadcast 192.168.12.255
        inet6 fe80::222:64ff:fe72:e5  prefixlen 64  scopeid 0x20<link>
        ether 00:22:64:72:00:e5  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 2960 (2.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
vlan13: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 192.168.13.2  netmask 255.255.255.0  broadcast 192.168.13.255
        inet6 fe80::222:64ff:fe72:e5  prefixlen 64  scopeid 0x20<link>
        ether 00:22:64:72:00:e5  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 125  bytes 11290 (11.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Работоспособность маршрутизатора проверялось ответным коммутатором, так что в нем сомнений нет. Тем более я сомневаюсь что маршрутизатор среднего предприятия не будет упаковывыть в vlan пакеты поступающие на подинтерфейс с назначенной инкапсуляцией.
Google и лазанье по форумам как нативного, так и аналогичных дистрибутивов ничего не дал. Буду рад любой помощи. Заранее спасибо всем откликнувшимся.
У меня VLAN'ы определены вот так:
ip link add link eth0 name eth0.21 type vlan id 21
ip addr add 192.168.21.106/24 brd 192.168.21.255 dev eth0.21
ip link set dev eth0.21 up
Все пинги успешно бегают. На втором конце - киска 3725.
Да, забыл отметить - не тэгированные пакеты идут на основной интерфейс (eth0), vlan'ы соответственно на сабинтерфейсы.

Тьфу, блин… только сообразил. vlan'ы - это L2, на L3 они терминируются, т.е. на интерфейсе L3 тэги уже сбрасываются (если мне склероз не врёт). На киске 3725 порты L2, часть относящаяся к тэгам на свитче выглядит так:
....
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 15
 switchport trunk allowed vlan 14,128-130
 switchport mode trunk
....
соответственно на моих интерфейсах vlan'ы терминируются.
Ну собственно я свои vlan'ы определяю так же как и Вы. Насколько я знаю, нет разницы как назвать подинтерфейсы: eth0.11 или vlan11. И если быть полностью откровенным, я пробовал называть и так и эдак. Это не повлияло на успех дела. А вместо широковещательного адреса я ставлю “+” и он вычисляется автоматически.
Сегодня для чистоты эксперимента, я загрузился с BackTrack 5 на этой машинке, проделал все вышеизложенные операции и получил такой же результат как и в арче. Один в один.

Для полноты информации добавлю пару вырезок из dmesg
Linux# cat dmesg | grep sky2
[    7.241320] sky2: driver version 1.30
[    7.241416] sky2 0000:85:00.0: Yukon-2 Extreme chip revision 2
[    7.241556] sky2 0000:85:00.0: irq 47 for MSI/MSI-X
[    7.242131] sky2 0000:85:00.0: eth0: addr 00:22:64:72:00:e5
[   11.768550] sky2 0000:85:00.0: eth0: enabling interface
[ 6656.982877] sky2 0000:85:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both
Linux# cat dmesg | grep eth0
[    7.242131] sky2 0000:85:00.0: eth0: addr 00:22:64:72:00:e5
[   11.768550] sky2 0000:85:00.0: eth0: enabling interface
[ 6656.982877] sky2 0000:85:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both
[ 7358.427230] device eth0 entered promiscuous mode
[ 7361.492113] device eth0 left promiscuous mode
[ 7363.936604] device eth0 entered promiscuous mode
[ 7455.740463] device eth0 left promiscuous mode
[ 7457.169315] device eth0 entered promiscuous mode
[ 7472.488871] device eth0 left promiscuous mode
[ 7478.412421] device eth0 entered promiscuous mode
[ 7495.552233] device eth0 left promiscuous mode
[ 7498.339329] device eth0 entered promiscuous mode
[ 7528.731663] device eth0 left promiscuous mode
[12435.745366] device eth0 entered promiscuous mode
[12439.461203] device eth0 left promiscuous mode
[12599.218510] device eth0 entered promiscuous mode
[12602.372463] device eth0 left promiscuous mode
[12796.494230] device eth0 entered promiscuous mode
Linux# cat dmesg | grep vlan13
[13460.908696] vlan13: no IPv6 routers present
[14254.161209] device vlan13 entered promiscuous mode
[14260.085490] device vlan13 left promiscuous mode
[16137.574533] device vlan13 entered promiscuous mode
[16642.029484] device vlan13 left promiscuous mode
При необходимости могу выложить и весь вывод dmesg
Третье добавление, после некоторых размышлений: не совсем понятно зачем этот стенд… Т.е. на ВЫХОДЕ интерфейса пакет тэгируется, на ВХОДЕ - тэг исчезает. Т.е. тэгированные пакеты существуют только в проводе.

Таблица ARP прописывается автоматически при прохождении пакетов через (под)интерфейс. Например:
$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.130.100          ether   00:15:63:e9:22:e0   C                     eth0
192.168.21.66            ether   00:17:31:8d:81:4d   C                     eth0.21
192.168.21.214           ether   00:15:17:ec:9b:51   C                     eth0.21
192.168.21.222           ether   00:15:17:ec:9b:51   C                     eth0.21
192.168.21.46            ether   00:22:15:23:59:ca   C                     eth0.21
192.168.130.200          ether   00:22:15:23:5c:9a   C                     eth0
192.168.21.224           ether   00:15:17:ec:9b:51   C                     eth0.21
.....
$ ping 192.168.128.201
PING 192.168.128.201 (192.168.128.201) 56(84) bytes of data.
64 bytes from 192.168.128.201: icmp_req=1 ttl=128 time=1.15 ms
64 bytes from 192.168.128.201: icmp_req=2 ttl=128 time=0.167 ms
64 bytes from 192.168.128.201: icmp_req=3 ttl=128 time=0.162 ms
^C
--- 192.168.128.201 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.162/0.496/1.159/0.468 ms
[netmaster@pirr ~]$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.130.100          ether   00:15:63:e9:22:e0   C                     eth0
192.168.21.66            ether   00:17:31:8d:81:4d   C                     eth0.21
192.168.21.214           ether   00:15:17:ec:9b:51   C                     eth0.21
192.168.21.222           ether   00:15:17:ec:9b:51   C                     eth0.21
192.168.21.46            ether   00:22:15:23:59:ca   C                     eth0.21
192.168.128.201          ether   00:25:90:2b:04:84   C                     eth0.128
192.168.130.200          ether   00:22:15:23:5c:9a   C                     eth0
192.168.21.224           ether   00:15:17:ec:9b:51   C                     eth0.21
Дело в том что мне самому особо не понятно почему на возвращающихся пакетах на интерфейсе eth0 отсутствуют теги. Они по логике должны там присутствовать, а далее проходить на соответствующий подинтерфейс, на выходе которых пакеты уже должны быть нетегированые. Но этого не происходит, и на eth0 я имею исходящие тегированные пакеты, а приходящие нетегированые.
На данном стенде необходимо добиться классической реализации транкового порта в linux, и именно на этой машинке. Существование тегированных пакетов только в проводе НЕ НУЖНО.
“А по колёсам попинал?” :)

Для чистоты эксперимента попробовать заменить сетевуху (?), хотя у меня даже на самых хреновых VLANы честно поднимались. И как-то выяснить - а рутер-то умеет тэгировать пакеты?
Полностью с Вами согласен. Но как я все изложил в первом посте. До заполнения таблицы arp у меня не доходит. Пакеты оседают на eth0 интерфейсе не доходя до подинтерфейсов. Если arp таблицу заполнить ручками то пинги начинают ходить. Вот только опять не понятно каким образом, так как на подинтерфейсы они так же не доходят, а останавливаются на eth0
“стучал, стучал. и фары протирал” :)
Сетевую карту поменять не вариант, так как машинка - это ноутбук. Роутер однозначно рабочий. Он 3 года у нас в связке с коммутатором по транковому линку с 10 vlan'ами работал.
Сейчас забрался по VPN (и соответственно на vlan'ный адрес) на свою рабочую машину, tcpdump показывает пакеты и туда и обратно как ethertype 802.1Q. Больше пока ничего в голову не приходит.
Ещё одна мысль забрела в отравленную алкоголем голову: а что если подключиться к рутеру через свитчик? Либо какой-нибудь “полудурок”-управляемый, либо через приличный неуправляемый (у меня стоит на столе, тэгированные пакеты пропускает).
 
Зарегистрироваться или войдите чтобы оставить сообщение.