zstas

ну там сверху написано, слева в пакетах в секунду, справа в байтах в секунду. правда я не помню за сколько примерную статистику он берёт :)

sh bindings counters username XXXX detail там есть Receive/Second, Transmit/Second

к какой именно? dpdk-pdump

мой скрипт - он нужен чтобы в принципе dpdk запуститься мог. а куда складывать трафик - это уже к вашей утилите ман читать надо.

тут просто выделяется 2048 hugehages. ну мне нужно много оперативы отдать в hugepages, для дампа можно и поменьше наверное. через sysctl можно тоже самое сделать в принципе

интересно, предлагаю сконпелять dpdk, у меня такая же версия есть в проде и там всё есть zstas@dpdk-test:~/dpdk-stable-17.11.3/build/kmod$ ls -la total 72 drwxrwxr-x 2 zstas zstas 4096 Jul 2 10:47 . drwxrwxr-x 7 zstas zstas 4096 Jul 2 10:48 .. -rw-rw-r-- 1 zstas zstas 20784 Jul 2 10:47 igb_uio.ko -rw-rw-r-- 1 zstas zstas 40928 Jul 2 10:47 rte_kni.ko

нужно биндить драйвер igb_uio ну и вообще какая версия dpdk?   $ cat /opt/url_filter/startup.sh #/bin/bash sudo modprobe uio sudo insmod /opt/dpdk-stable-17.05.1/build/kmod/igb_uio.ko echo 2048 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages sudo mount -t hugetlbfs nodev /mnt/huge/ sudo /opt/dpdk-stable-17.05.1/usertools/dpdk-devbind.py --bind=igb_uio 06:00.0 sudo /opt/dpdk-stable-17.05.1/usertools/dpdk-devbind.py --bind=igb_uio 06:00.1 вот мой скриптец который делает всё, для примера :)

в этом случае на клиенте будет 1 роут вместо 2х, но есть вероятность следующая: PE1 потеряет связь до RR2, а PE2 до RR1. тогда PE1 потеряет маршруты PE2. в случае с разными cluster-id - маршруты останутся (если между RR1 и RR2 сессия будет жива).

1) не нужно 2) лучше разный

теряются даже пинги? трассировка что показывает? если пинговать со второго бордера потери есть?

Зависит от вашего ПК. Настольный комп или ноут? На ПК hdd или ssd? (на скорость скачивания влияет). Ещё в разных браузерах разную скорость показывает. И до разных серверов попробуйте (но чтобы задержка не больше 5-10 мс была).

Да понятно, что надо смотреть по месту, что быстрей достать, что удобней сделать и тд. Я больше отвечал на тему что ММ нафиг никому не уперся :)

цоды закупают трансиверы тысячами, и любая разница будет выливаться в миллионы. вы рассуждаете с позиции телекома, где многомод не нужен совсем, и проще заложить модуль даже на 10км, потому что они в ходу (на 2км почти никто не покупает как раз чтобы позицию лишнюю не держать).

ну ёмаё, где дешевле то? https://shop.nag.ru/catalog/01891.Moduli-SFP/06901.Dvuhvolokonnye/04276.SNR-SFPLR-10 https://shop.nag.ru/catalog/01891.Moduli-SFP/06901.Dvuhvolokonnye/04275.SNR-SFPSR а если посмотреть 40G модули или 100G модули, то разница ещё ощутимей будет. Потому что qsfp+ и qsfp28 в случае одномода это CWDM внутри.

расскажите это цодам где всё на многомоде :) там синглмод просто экономически невыгоден.

на 50м даков не бывает. на 50м хватит многомода за глаза, патч и трансиверы обадва дешевле будут чем одномод.

cgnat там нет, остальное есть. возьмите на тест у нага :) расскажите. железка не так давно появилась.

брасы у хуа это me60

лучше не заморачиваться с отдельной нарезкой "локального трафика". это никому не нужно, сейчас не 2000 год.

делать редирект хттп, уже вроде 2 страницы тему обсасываем, а до сих пор никто не протестировал?

в последних виндах и по кабелю работает и в последних версиях фаерфокса он вроде сам даже умеет чекать на кэптив-портал.

суммировать тоже не очень хороший вариант. есть 2 часто встречающиеся схемы: 1) на каждый брас распилить свои пулы адресов. их анонсировать большими блоками (хотя бы по /24. прописываем сеть в null0 и в bgp network). в этом случае адреса прибиты к конкретному брасу. 2) анонсировать по /32 каждого клиента через redistribute subscriber (тут получаем очень много маршрутов в bgp, но на smartedge довольно жирный fib, так что это ему нипочем) мы из-за особенностей нашего радиуса в биллинге (не умеет по несколько пулов на один NAS) используем второй вариант. естественно эти анонсы не нужно пропускать в интернет, они нужны только внутри вашего ядра. например, метить их специальным коммунити). так же вам напрашивается отдавать в контекст дефолт через bgp, а не статикой (особо роли не играет, но если уже есть bgp сессия между контекстами например) а вообще я бы на вашем месте нарисовал бы дизайн сначала на бумажке или в visio, как что куда должно по bgp бегать, какие bgp коммунити использовать для разных сетей, плюс заранее продумать появление 3го браса (подумать стоит ли делать bgp full mesh или сделать RR). как я понял у вас один из брасов является и бордером тоже?

да, проще прописать в каждом контексте по статику на другой лупбек и поднимать ibgp сессию между контекстами на этих лупбеках. мы везде ушли с isis между контекстами на такую схему. покажите на каждом устройстве в каждом контексте sh ip route 77.77.2.106

перечитал 3 раза так и не понял ничего. обычно дизайн сети такой, что по isis раздают только лупбеки, поверх них bgp сессия. и по bgp анонсят клиентские сети (либо через redistribute subscriber, либо через network'и)

тут нужно нормально траблшутить. если траблшутить нет возможности - проще зарезать весь лишний трафик (например мультикаст и ipv6, если их в сети нет). если pppoe то вообще оставить только 2 ethertype.