v7100

Спасибо, вроде бы все так. Но неужели JunOS нигде не ругается при этом хотя бы ?

То есть отличий при использовании с софтом 14.2 или 15.1 между MPC-3D-16XGE-SFPP-R-B и MPC-3D-16XGE-SFPP - нет, верно ? И у вас именно простые т.н. платы "L2.5" MPC-3D-16XGE-SFPP и при использовании BGP , L3VPN - нигде нет даже ворнингов ?

Господа, кто подскажет, какой крайний стабильный софт для MPC-3D-16XGE-SFPP ? То есть на котором стабильно все работает. И при этом не ограничивается функционал до L2.5 ( 32к роутов в FIB ) ?

Логика простая: протокол 802.1Q вставляет в кадр после dst MAC свои 4 байта, поэтому и происходит смещение. Эта логика мне известа, я думал "protocol 802.1q" как раз эту логику и реализует. И ведь таки да - реализует и работает, но в 26 ядре, обратите внимаение.А вот для 31 ядра пришлось мало того, что указать "protocol 802.1q" так еще указывать "at 16" и "at 20" вместо "at 12" и "at 16" соответственно. Ну куда это годится? :-)

Конечно меняет - пакеты не классифицируются. Ведь ip - это для IPv4, а у меня 802.1q, IPv4 там нет

bridge:~# tcpdump -i eth2 tcpdump: WARNING: eth2: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes 15:28:15.058476 vlan 444, p 0, IP 10.44.0.4 > 10.44.0.3: ICMP echo request, id 63292, seq 1, length 64 15:28:15.060651 vlan 444, p 0, IP 10.44.0.3 > 10.44.0.4: ICMP echo reply, id 63292, seq 1, length 64 ^C А про 16 и 20 - действительно заработало! Спасибо! Логику этого дела оставим в стороне :-Р bridge:~# tc -s filter show dev eth1 | grep -A 1 1:10 filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 3 success 1) match 0a2c0004/ffffffff at 20 (success 1 ) bridge:~# tc -s filter show dev eth2 | grep -A 1 1:10 filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 3 success 1) match 0a2c0004/ffffffff at 16 (success 1 )

Доброго всем времени суток! Собираю схему с шейпящим бриджем - Linux, HTB, u32. Особенность такова - через него проходит тегированный трафик. Соответственно фильтр выглядит так: для даунстрима tc filter add dev $DEV protocol 802.1q parent 1:0 prio 1 u32 match ip dst 10.44.0.4/32 flowid 1:10 для апстрима tc filter add dev $VED protocol 802.1q parent 1:0 prio 1 u32 match ip src 10.44.0.4/32 flowid 1:10 bridge:~# tc -V tc utility, iproute2-ss090324 проверяю c клиента # ping -c1 10.44.0.3 PING 10.44.0.3 (10.44.0.3) 56(84) bytes of data. 64 bytes from 10.44.0.3: icmp_seq=1 ttl=64 time=68.4 ms --- 10.44.0.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 68.456/68.456/68.456/0.000 ms в итоге получаю bridge:~# tc -s filter show dev eth1 | grep -A 1 1:10 filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 1) match 0a2c0004/ffffffff at 16 (success 1 ) bridge:~# tc -s filter show dev eth2 | grep -A 1 1:10 filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 1) match 0a2c0004/ffffffff at 12 (success 1 ) То есть и ушедший ping и вернувшийся pong отфильтровались верно. Это при bridge:~# uname -r 2.6.26-2-686 Если же загружаюсь с bridge:~# uname -r 2.6.31-1-686 то при тех же фильтрах bridge:~# tc -s filter show dev eth1 | grep -A 1 1:10 filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 0) match 0a2c0004/ffffffff at 16 (success 0 ) bridge:~# tc -s filter show dev eth2 | grep -A 1 1:10 filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 0) match 0a2c0004/ffffffff at 12 (success 0 ) Соотвественно и вопрос - почему в 26 фильтруется, а в 31 нет.