throughtheether

внутри сети нельзя подключаться по RDP к серверу по доменному имени (по внешнему IP тоже),

Насколько я понимаю, нужно копать в сторону NAT,

Вам поможет Hairpin NAT.

Если я правильно понял задачу, то я бы на вашем месте добавил еще один влан в транк Ether4 (возможно, нетегированный, если в Mikrotik это возможно). И, соответственно, на устройстве, подключенном в этот порт. После этого создать L3-интерфейс для этого влана на Mikrotik и прописать на нем соответствующий адрес.

На всякий случай, не советую использовать vlan 1 для клиентского трафика в рабочей сети, особенно если у вас мультивендорное (в т.ч. cisco) окружение.

По Mikrotik не специалист.

Вам нужен Hairpin NAT.

да, особенно на тему QoS/полисинга/шейпинга.

Подскажите в каком направлении двигаться.

В направлении точного описания проблемы и выяснения и, по возможности, устранения ее причины.

Происходит частая потеря пакетов между клиентами внутри сети.

Каких именно пакетов? Как вы проводите диагностику?

Клиенты работают по Ethernet.

Обратите внимание на состояние релевантных проблеме портов (ошибки, дуплекс).

из-за чего оно

У маршрутизатора, видимо, есть более важные дела, чем генерировать ответы на ICMP запросы (если mtr шлет их, конечно). Или на нем есть специальная функция ограничения такого трафика с целью минимизации вероятности возникновения ситуации отказа в обслуживании (DoS).

как сие побороть?

Если на рабочий трафик это не оказывает влияния, то бороться с этим не нужно.

Не знаток Mikrotik, но отвечу, раз вы меня призвали.

На мой взгляд, у вас активен маршрут по умолчанию (0.0.0.0/0) через 192.168.0.250. Попробуйте задать ему худшую (т.е. большую) метрику, чем у маршрута через pptp-интерфейс.

Как найти петлю в локальной сети?

неуправляемые коммутаторы,

Вы даже не знаете, реально ли наличествует L2-петля. Вполне может быть, что за eth4 где-то есть DHCP-сервер, раздающий всем клиентам некорректные настройки (используя широковещательные пакеты). Например, комнатный роутер не тем портом воткнули.

Но всё же обнаружил, что при включениии проблемной сети Packet Snifer начинает детектировать адреса ipv6 в сети, при чём некоторые адреса какие-то неполные.

Пример (адреса, дампа трафика) приведите, пожалуйста.

Что, придётся таки идти и дёргать провода последовательно?

Да, придется.

Вероятно "сдурел" один из свичей?

Возможно, но, чтобы это подтвердить, придется "идти и дёргать провода последовательно".

Я думаю, уже понятно, что стоит задуматься о приобретении нормальных (управляемых) коммутаторов? Они стоят-то, около 3000 за 16 портов (пример). До тех пор можете попытаться свести нестабильность сети к минимуму, ограничив широковещательные/многоадресные пакеты, запретив чужие DHCP-сервера на центральном маршрутизаторе (как я понял, обе эти задачи на Mikrotik, хоть и с использованием творческого подхода, но решаемы)

скорость соединения в микротике определяется, как 100 full duplex.

Уточните, пожалуйста, скорость и дуплекс именно определяются автоматически или жестко заданы? На порту, подключенном к провайдеру, CRC-ошибок (иногда используется термин FCS) на входящих фреймах не наблюдается? Интерфейс ноутбука при подключении в каком режиме работает (100 мбит/c или 1 Гбит/c)? Если есть CRC-ошибки на порту Mikrotik и порт ноутбука работает на 1 гбит/c, то попробуйте на порту Mikrotik задать режим 1Гбит/с.

Основной шлюз имеет 100 мегабитный канал в инет. А один из офисов только 10 мегабитный канал до шлюза.

Уточните пожалуйста, в чем конкретно состоит проблема. На что расходуются 10 мегабит/c полосы пропускания? На что их не хватает?

Каким образом можно сжимать трафик штатными средствами?

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

Возможны и другие варианты. Если в основном используется веб-функциональность интернета, вы можете поднять в проблемном офисе кэширующий прокси-сервер и, в случае использования оборудования cisco, задействовать его при помощи wccp. Вот пример.

Другой вариант - воспользоваться "ускорителем интернета" (WAN acceleration). В случае cisco - семейство WAAS. Имеет реализацию сжатия трафика, дедупликации данных и оптимизации производительности TCP. Опыта промышленной эксплуатации этого продукта я не имел, но могу предположить, что для грамотного внедрения подобного решения, необходимо понимать, как именно работают приложения в вашей сети, знать нюансы реализации TCP-стека на серверах/рабочих станциях и быть готовым к труднообъяснимым багам. И все это ради негарантированного улучшения производительности в вашем случае.

Наконец, когда-то существовали модули аппаратного сжатия трафика для 2600, 7200, но, если не ошибаюсь, они достигли статуса End-of-life.

Вкратце, не вполне ясно, как (насколько) именно вам поможет сжатие трафика. О наличии встроенной (не требующей дополнительной лицензии, дополнительного модуля) подобной функциональности в оборудовании cisco мне неизвестно. Возможные варианты я вам обрисовал.

UPD: Обнаружил такое якобы бесплатное решение. Думаю, стоит обратить на него внимание. Хотя, повторюсь, WAN-оптимизация - дело нетривиальное.

Нет, нельзя.

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

Если необходимо найти именно место расположения клиента, то можно предположить применение направленной антенны (для дифференциации по азимуту) и анализатора трафика (для дифференциации по MAC-адресам).

>Тогда я был бы благодарен за мануал по настройке статических определений связок
Если вы решили попробовать настроить специфичные arp-записи, как я рекомендовал, то надо сделать следующее:
1) на одном из хостов пропинговать 192.168.1.2 (с целью обновить динамические arp-записи).
2) посмотреть соответствующий MAC-адрес (в windows arp -a 192.168.1.2)
3) на каждом из 'избранных' хостов добавить статическую arp-запись (в windows arp -s 192.168.1.1 aa-bb-cc-dd-ee-ff, где aa-bb-cc-dd-ee-ff - адрес из п.2)
4) удалить статическую запись можно arp -d 192.168.1.1
5) при перезагрузке статическая запись теряется, может потребоваться прописать команду в автозагрузку

Я так понимаю, mikrotik и linux-машина находятся в одном l2-домене (т.е. включены в один коммутатор, порты в одном влане, интерфейсы 192.168.1.1 и 192.168.1.2 могут друг друга пинговать)?

Если так, то можно поднять на linux-машине dhcp-сервер и отдавать клиентам адрес маршрутизатора (dhcp option 3) в зависимости от MAC-адреса клиента. По-моему, dnsmasq это умеет.