Александр Чекалин

Отключите IPv6 на машине. В свойствах сетевой платы (скрин из Windows 10, но в 7-ке все выглядит сравнимо):



Ну и, для надежности, не забудьте на роутере IPv6 вообще отключить.

Да, и отключите Teredo и другие варианты IPv6 over IPv4 на машине - от греха. От администратора запустите консоль, и дайте команды:

netsh interface teredo set state disabled
netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled

(включить обратно можно при помощи тех же команд, но с указанием "type=default", примерно так: netsh interface teredo set state type=default).

Ну, за надежность бриджа не волнуйтесь, на нем построен весь микротик. Так что делайте бридж, а него добавляйте fa1 и fa6, а fa2..fa5 и fa7..fa10 делайте slave-ами с master-ами, соответственно, fa1 и fa7.

Интересно, чем ваши поиски закончились, и к чему Вы пришли. Вижу, что спрашивали давно, да ))

P.S. Mikrotik 1100AH (точнее, Mikrotik 1100AHx2, без x2 уже давно нет в продаже) не стоит, у него не "плоское поле" портов, а пара коммутаторов по 5 портов + еще два, по разному подключеных к процессору ( i.mt.lv/routerboard/files/Block-RB1100AHx2.pdf ). Это по уму самая неудачная схема, чтобы творить LAG-и. С другой стороны, трафик, требующий линков 8 Гб/сек (по 4 в каждую сторону), невольно заставляет спросить - точно ли вам такая железка подойдет, что Вы на ней будете делать, да и вообще, есть ли уверенность, что LAG так хорошо каналы пробалансирует в связках, что Вы на выходе получите приличную загрузку линков. Или вопрос только в надежности?

Посмотрите в сторону новых моделей с SFP+ модулями, где сразу будут 10 Гб/сек в каждую сторону. Правда, вопрос в свичах, не все умеют SFP+, но на таком трафике и бюджет на свичи должен найтись...

Может быть, Вы бы написали, что конкретно и в какой схеме соединения хотите получить? Иначе это напоминает "как испечь торт, имея сахар, миксер и швейцарский нож" )

Какой Вы сценарий хотите реализовать?

Вы с BGP дружите? Грамотно: завернуть всю AS ютуба в таблице маршрутов на свое железо, на нем выделить только запросы на 80 и 443 порты, остально пропускаете как есть, а запросы отправляете на свой сервер с прозрачным сквидом - пусть ловит в запросах наличие строки "GET ваш-URI", и делает редирект ему на сайт конторы, которая вам спустила писульку.

По идее, это все нужно делать для всех URL из Реестра, будь он неладен.

Но Вы не поймаете запросы на https;// , прокси внутрь не посмотрит,

Если маршрутизацией не играть, проксирйте все сайты, и в этом потоке режте. Только нагрузка...

Трафик netflow сильно зависит от характера основного потока: если там летит даже много гигабит, но летят одним потоком с одной пары адрес/порта src на одну пару адрес/порт dst, то будет совсем немного, а если там (мать-мать) десяток многомегабитных торрентолюбов-сиддеров...

Кабель кинуть смысл имеет, не по величине трафика, а потому, что, если поток на основном линке дойдет до лимита физики, то netflow туда начнет внезапно не помещаться - а скорее, все же, будет мешать основному потоку.

Но Вы смотрите, что хотите получить. Порой и выборки (сэмплинга) хватит, тем более что netflow в реальности со "своими моментами" связан: для архивных целей лучше бы полные отчеты хранить, но, если потоки большие, а характер трафика бурный (торренты те же), то хранить придется много. С другой стороны, нужно ли такое добро, как картину работы торрента, хранить очень уж подробно? Биллинг может посчитать, а вы в архив все равно аггрегированные записи пойдут, наверняка - а раз так, может, и сэмплинг на сенсоре можно будет позволить себе включить?

Хм... Уберите bridge_* строки, они выше в ipv4 конфигурации уже есть. У меня такое:

auto vmbr0
iface vmbr0 inet static
        address x.x.x.x
        netmask 255.255.255.y
        gateway x.x.x.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0

iface vmbr0 inet6 static
        address z:z:z::z
        netmask 64
        gateway z:z:z::1

прекрасно работает.

Смотреть на оборудовании, где такой мак подключен, вычислять порт, бежать туда и находить клиента на порту.

Я бы советовал подумать, что будете делать, когда найдете тролля. Если «в глаз бить» (хотя бы фигурально) дозволительно, то проблему решите, если же карать нечем — так и будут играть в кошки-мышки. В последнем случае придется Вам авторизацию того или иного рода делать (VPN для клиентов поднимать, PPPoE, на проксе авторизовывать как-то хитро), причем оно явно будет непрозрачно.

Как вариант, посмотреть ISA, точнее, авторизацию через ее клиента — там все хитрее и интереснее, но и возни больше.

P.S. Написали, что «решено» — на чем остановились, если не секрет?