pavelsh

1. Проверьте ваши настройки tcp/ip
2. Проверьте какие драйвера для диска встали
3. vmware tools встали на новую vm-ку? Они поддерживают 7.1?

Если я правильно понял весь этот тред, то происходит следующее:
1. У вас ходил трафик на некий mac-адрес xxxx.yyyy.zzzz Все было ок.
2. В какой-то момент времени клиент выключает машину с этим мак-адресом
3. Трафик прилетает на свитч, видит запись "ищи mac-адрес xxxx.yyyy.zzzz на таком-то порту". Отправляет этот трафик на сервер. Все легитимно. (и будет отправлять этот трафик, пока этот mac не заэкспайрится)
4. Трафик прилетая на сервер, приходит на бридж. Видимо ваш бридж настроен таким образом, что unknown unicast трафик начинает совать во все подинтерфейсы/интерфейсы чтобы найти - а вдруг тут есть приемник на этот адрес. То есть этот трафик начинает размножаться.
5. Если у вас двойное подключение к коммутатору, то трафик может улететь и обратно в vlan, и изрядно умноженный.

Как решать проблему. Точно могу сказать - это проблеме не L2 и L3 оборудования. Это проблема бриджа linux-а. Разбирайтесь с бриджом и не трогайте инженеров ДЦ.

Покажите sh run с обоих роутеров.

Каким образом проверяете что туннели подняты?

Покажите вывод sh int tu0

Какая версия клиента?
Скриншот ошибки?

Я за Микротик.

1. зависит от того, как организованны потоки данных в вашем случае. Если между стойками планируется большой трафик — ставьте два коммутатора в центр
2. Какой у вас трафик? Сколько пакетов в секунду, что за трафик, tcp/udp — нужно больше подробностей. Если у вас провайдер вам дает интернет по ethernet, то зачем вам маршрутизатор? Что и куда маршрутизировать будете?
3. в теории. Надо проверять.
4. Как минимум делать отдельный приоритетный vlan. Я бы поставил отдельную физическую сеть
5. Надо сначала понять какие задачи на серверах, какие потоки данных, а потом можно и vlan-ы делать.
6. Хм. Традиционно. Посмотрите как обычно строят сети для датацентров.

Если что непонятно — спрашивайте еще.

Мне вот статья понравилась
habrahabr.ru/company/JetBrains/blog/193830/

А вообще, я бы обращался к профессионалам. Построить сеть на 1000 пользователей не так очевидно, как кажется.

Дебаги уже смотрели?

А меня в этой ситуации умиляет следующее — частая смена паролей заставляет пользователей писать бумажку и клеить ее на монитор, потому как не могут запомнить «длинный и сложный пароль, в котором есть обязательно буквы в обоих регистрах, цифры и знаки препинания»

А что говорит Cisco на тему миграции базы? Не хотите tac попросить вам помочь или подстраховать?

wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=FAX-Call-t38-CA-TDM-SIP-FB-1.pcap
Вот это отсюда
wiki.wireshark.org/SampleCaptures
wiki.wireshark.org/T.38

Вот тут есть вложенный pcap
www.wireshark.org/lists/wireshark-users/200810/msg00155.html

issues.asterisk.org/jira/browse/ASTERISK-13879

Вообщем запрос в google t38 pcap даст вам много вариантов примеров
И вот тут есть еще примеры
google: filetype:pcap t.38

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

Лично бы я читал RFC. В свое время я занимался этим вопросом — ничего лучше не обнаружил.

Не понятно зачем клиент получает инфу от другого клиента.

А вообще — считаю что это неправильно. Агент должен быть маленьким и не мешать серверу работать. Его дело — собрать в себя текущие данные и выплюнуть серверу. А сервер должен считать — потому как именно в нем есть все данные о клиенте.

Повесьте логику на базу — считайте все в ней. Или сделайте сервер приложений, который будет для вас считать, если erlang не справляется.