necrozz

А какая разница пардон ? Ну окно у делителя не 1310,1550..., а 850... ну бюджеты другие. У меня пашет вагон делителей и на MM и на SM, причем на MM сейчас даже больше. Цена практически одинакова. Про модули уже писал выше.

Цены не малой кто ? Делитель ? Стоит не копейки, но и не дорого. Модулю на делитель насрать настолько, насколько это вообще возможно, лишь бы бюджета оптического хватало.

Сколько стоят трансподеры/muxponder'ы с 40G портами не подскажу ). Железки с лицухами на 4x10G стоят ~1.2 ляма за пару.

В ваших условиях оно будет просто тупо работать. Ебург город маленький ) Расстояние небольшие. А так packetlight у нас расставлено с десяток коробок - вопросов нет. Из энТЫРпрайза насколько я помню в УБРИРе packetlight стоит. Если есть их контакты - можете с ними пообщаться. Но имхо для такой задачи это overkill, я бы для начала циркулятор потестил.

netdata

Резюмирую. В общем случае в 9 debian'е достаточно: modprobe nf_nat_pptp sysctl -w net.netfilter.nf_conntrack_helper=1 В моём кейсе это не помогло, потому что я напоролся вот на такое дерьмо https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2061834 В итоге проблема решилась заменой E1000 на VMXNET3.

Оно уже есть. GRE все так же падает в UNREPLIED

pptp_client<--->(локалка)<--->linux_server<--->(inet)<--->pptp_server т.е. клиент сидит на NAT, сервер в public. модули: nf_nat_pptp со всей обвзякой и ip_gre загружены в sysctl: net.netfilter.nf_conntrack_helper=1 в iptables: -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp сам nat обычный snat: -A POSTROUTING -s 10.xxx.xxx.0/24 -o eth0 -j SNAT --to-source yy.yy.yy.yy

pptp over nat не работает. без nf_nat_pptp он он ругается на conntrack: generic helper won't handle protocol 47. Please consider loading the specific helper module. с nf_nat_pptp просто тишина и ничего не работает

Проверяли, регулярно. Все ок. Про SFP смешно, там как раз таки наоборот допилили нормальную поддержку левых SFP, в старых версиях (даже ещё в 15 ветке) были проблемы конечно.

порядка 30G x670 без проблем сливал в съемник )

такой же. суть в чем - линки, которые надо сормить - делите сплиттерами. в некий свич подключаете эти отводы. а съемник уже может хоть медным портом в свич смотреть, хоть оптическим. Это и есть классический метод отправки трафика без зеркала, а через сплитерра? Т.е. трафик будет сыпаться во все порты свича? Тут просто тоже анализируем как и что, я вообще пока даже представления не имею :) it depends. Если у вас у съемника хватает оптических дырок - фигачьте со сплиттера сразу в съемник. Удобно, просто, надежно... Если дырок не хватает, или вы хотите использовать их более оптимально, или например часть трафика как-то "предфильтровать" заворачивайте на коммутатор, там делаете no mac learning в это влане и с коммутатора уже на съемник. Сыпаться куда не нужно при этом не будет при port isolation.

такой же. суть в чем - линки, которые надо сормить - делите сплиттерами. в некий свич подключаете эти отводы. а съемник уже может хоть медным портом в свич смотреть, хоть оптическим. Какой "такой же"? У меня долгое время на одном из сайтов через обычные конвертеры SFP-SFP-T работало ) Т.е. со сплиттеров все улетает в конвертер, а оттуда уже в съемник

Первый старт после установки второго SCM у меня занял пол часа или чуть ли не дольше. Правда я думал что она как раз SCOS синкает между SCM'ами )

2.6.32-696.el6.x86_64 dmesg |grep dna0 ixgbe 0000:04:00.0: dna0: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF ixgbe 0000:04:00.0: dna0: Enabled Features: RxQ: 4 TxQ: 4 FdirHash LRO ixgbe 0000:04:00.0: dna0: Intel(R) 10 Gigabit Network Connection Пока никаких проблем