Здравствуйте! Есть такая проблема: канал в Интернет 15 Мбит, но у клиентов то все быстро и качественно работает, то страница открывается после 50 обновлений и как-то весело, то одна половина графики не загружается, то вторая, то форматирования нет, то вообще не откроется, хотя пинг с ними всегда есть. Если в моменты таких глюков протестировать скорость интернета (http://speed.yoip.ru/), то с ней все в порядке - высокая. С DNS проблем тоже нет, в любой момент исправно определяет ипы. На сервере стоит Debian без графики, по этому состояние Интернета проверяю только пингом - всегда есть.
--- - --- - ---
Есть вот только одна особенность моей сети: В здании раскинута сеть моего провайдера через обычные неуправляемые свитчи, работает DHCP, Интернет раздается просто по LAN. К моим клиентам идут провода от этих же свитчей. Чтобы не тягать лишних проводов я просто вбил у них статические настройки, разумеется отличные от провайдерских, и получилась подсеть 192.168.102.0/24. Так вообще можно делать??? Из сервера получается обе сетевухи смотрят физически в один и тот же свитч, но настройки разных сетей:auto lo
iface lo inet loopback# Internet
auto eth1
iface eth1 inet dhcp# Home3
auto eth0
iface eth0 inet static
address 192.168.102.102
netmask 255.255.255.0Раньше провайдер раздавал интернет через vpn - все было отлично, как только перешел на LAN, стали происходить вышеупомянутые чудеса. Правда и сервер у меня был раньше на Windows XP и Kerio стоял, но теперь хоть на винде, хоть на линуксе глюки есть... Даже и не знаю что делать...
Настройки iptables:
echo 1 > /proc/sys/net/ipv4/ip_forward
#Чистим таблицу
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X#Правила поумолчанию
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT#DNS-форватинг
iptables -t nat -A PREROUTING -s 192.168.102.0/24 -p udp --dport 53 -j DNAT --to-destination 172.31.240.4
iptables -t nat -A POSTROUTING -p udp --destination 172.31.240.4 --dport 53 -j SNAT --to-source 172.30.186.22#Менять ip при выходе в интернет
iptables -t nat -A POSTROUTING -d ! 192.168.102.0/24 -j SNAT --to-source 172.30.186.22Помогите, чем можете!!!
>[оверквотинг удален]
> iptables -P FORWARD ACCEPT
> iptables -P OUTPUT ACCEPT
> #DNS-форватинг
> iptables -t nat -A PREROUTING -s 192.168.102.0/24 -p udp --dport 53 -j
> DNAT --to-destination 172.31.240.4
> iptables -t nat -A POSTROUTING -p udp --destination 172.31.240.4 --dport 53 -j
> SNAT --to-source 172.30.186.22
> #Менять ip при выходе в интернет
> iptables -t nat -A POSTROUTING -d ! 192.168.102.0/24 -j SNAT --to-source 172.30.186.22
> Помогите, чем можете!!!Повесить на внешку (вместо сервака)
один комп и потестить веб на нем?
> Повесить на внешку (вместо сервака)
> один комп и потестить веб на нем?Если убрать сервер и поставить инет на 1 комп, то на нем все аж летает, начанаешь с него раздавать и полезут сразу косяки. Опять же повторюсь, косяки время от времени, при чем равновероятно хоть я 1 клиента повешу, хоть 70.
Маскарадинг я бы сделал по-другому.
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.30.186.22А вообще надо анализировать трафик, чтобы понять в чём дело.
Провайдерский DNS-сервер лоялен к большому количеству запросов с одного IP?
Пинги от клиентов до твоего сервера и до провайдерского шлюза с какими потерями идут?
А провода и неуправляемые свичи кому принадлежат?
> А провода и неуправляемые свичи кому принадлежат?90% мне, ну как мне, общественности, это здание общежитие и сетка тут общая, доступ к ящикам есть.
> Маскарадинг я бы сделал по-другому.
>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.30.186.22
> А вообще надо анализировать трафик, чтобы понять в чём дело.Как это делается??
> Провайдерский DNS-сервер лоялен к большому количеству запросов с одного IP?Думаю, что да, если даже это не так, то я пробовал всякие разные сервера из Интернета писать - один результат.
> Пинги от клиентов до твоего сервера и до провайдерского шлюза с какимиПинг даже до любого из сайтов в любой момент времени с 0-2% потерь идет (тестировал по несколько часов)
> потерями идут?Аськи, скайпы, всяческие игры, фтп сервера, все сразу коннектится, а вот http косячит частенько.
>> А вообще надо анализировать трафик, чтобы понять в чём дело.
> Как это делается??Ну на клиентской машине запускаешь анализатор пакетов в момент проблемы (например tcpdump или что там есть у винадминов) и смотришь, что отсылает машина при выполнении проблемного действия, что приходит ей в ответ, что не приходит, а должно бы, или идёт долго, или не то что нужно, ну вот как-то так, в общем.
> Аськи, скайпы, всяческие игры, фтп сервера, все сразу коннектится, а вот http
> косячит частенько.В сочетании с тем, что пинги вроде как нормально ходят, у меня это вызывает подозрение на то, что проблема именно в DNS, т.к. эти приложения, скорее всего, обращаются к серверам в интернете по IP, а в браузерах все вводят имена сайтов.
Чтобы проверить предположение можешь вот в момент проблемы у клиента, на его машине пингануть проблемный сайт, чтобы узнать его IP и ломиться в браузере прямо на IP. Если проканает, значит проблема в DNS, если нет -значит, что проблема не (или не только) в DNS.
>Думаю, что да, если даже это не так, то я пробовал всякие разные сервера из Интернета писать - один результат.В смысле пробовал разные DNS-серверы указывать?
Если так, то хреново, чё... ))
> Чтобы проверить предположение можешь вот в момент проблемы у клиента, на его
> машине пингануть проблемный сайт, чтобы узнать его IP и ломиться в
> браузере прямо на IP. Если проканает, значит проблема в DNS, если
> нет -значит, что проблема не (или не только) в DNS.В момент глюков, командой ping ип определился сразу, пинг пошел без потерь, при попытке в браузер вставить этот ип ничего не изменилось... говорю же нормально все с ДНСом. Есть еще мысли?
>
У провайдера стоит ограничение на количество одновременных сессий.
> У провайдера стоит ограничение на количество одновременных сессий.Если это действительно так, то как узнать какое именно ограничение?
И еще, знакомый от этого же провайдера нормально инет раздает (в моей же сети), только он vpn сервер поднял.
каких таких сессий? Сессия одна - с его сервером. Все его клиенты просто NATятся через него и провайдер вообще об их количестве ничего не знает.
> каких таких сессий? Сессия одна - с его сервером. Все его клиенты
> просто NATятся через него и провайдер вообще об их количестве ничего
> не знает.В терминах FreeBSD см. src/dst limit.
И провайдеру по барабану количество его клиентов, сделал dst limit 100, например и всё.Напрямую выявить этого нельзя, только косвенными методами, по возникновению ситуаций аналогичных TC.
Ну, понятно.
Для меня термины BSD - мунспик :-)
> Помогите, чем можете!!!iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
>> Помогите, чем можете!!!
> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
> --clamp-mss-to-pmtuПочти у всех MTU отличное от стандартного 1500, сам долго мучался, когда ADSL на 512Кбит, а такое впечатление, что интернет работает избирательно.
> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
> --clamp-mss-to-pmtuДобавил эту строку - улучшений в работе Интернета нет...
>> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
>> --clamp-mss-to-pmtu
> Добавил эту строку - улучшений в работе Интернета нет...У меня проблема решилась после изменения MTU внутреннего интерфейса на 1400 и добавления парвила iptables которое описано выше
man iptablesTCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus
40 for IPv4 or 60 for IPv6, respectively). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table.
This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets. The symptoms of this
problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu--set-mss value
Explicitly set MSS option to specified value.--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).These options are mutually exclusive.
описалово номер 1 как в твоем случае
> описалово номер 1 как в твоем случаеСогласен, но пробовал добавить
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
и пробовал
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400
Никаких результатов...
> У меня проблема решилась после изменения MTU внутреннего интерфейса на 1400Как изменять MTU? Его нужно уменьшить именно для внутреннего интерфейса или для внешнего тоже?
отдели сеть провайдера от своей, думаю в этом дело.
А такие баги наблюдал на двух или более машинах, когда у них совпадал MAC адрес, почему он совпадал, дело десятое :)
> отдели сеть провайдера от своей, думаю в этом дело.
> А такие баги наблюдал на двух или более машинах, когда у них
> совпадал MAC адрес, почему он совпадал, дело десятое :)Не вариант сети разделять - у нас в ящиках черт ногу сломит, да и люди все (мои и не мои клиенты) должны быть в одной сети, нужно лишь в эту сеть грамотно добавить шлюз в Интернет.
такое построение сети уже не грамотное.
Если кто в сеть пускает ARP флуд, то можно попробовать прописать MAC шлюза у клиентов в статическую ARP таблицу.
> Если кто в сеть пускает ARP флуд, то можно попробовать прописать MAC
> шлюза у клиентов в статическую ARP таблицу.Про флуд - это вряд ли...
Т.е. прописать у клиентов в ARP мак сетевухи моего сервера смотрящей в локалку?
Еще момент интересный! Пишу у клиента arp -a и он определят мак сервера той сетевухи, которая в инет смотрит, а не в локалку. Во как! Т.е. IP от eth0 а mac от eth2 (см. начало темы).
> Еще момент интересный! Пишу у клиента arp -a и он определят мак
> сервера той сетевухи, которая в инет смотрит, а не в локалку.
> Во как! Т.е. IP от eth0 а mac от eth2 (см.
> начало темы).Вспомнил, это древний баг ARP протокола в Linux системах.
Поясню на примере, имеем
Net1-----[{MAC1,IP1}PC{MAC2,IP2}]-----Net2
так вот, если дать ARP запрос из Net1 для IP2, то получим ответ MAC1,IP2.
Этот баг некоторые провайдеры использовали для поиска роутеров у клиентов.Как от этого избавится?
как уже говорил, писать клиентам статическую ARP таблицу,
второй вариант, фильтровать на сетевухах не свои ARP запросы, например с помощью ebtables http://ru.wikipedia.org/wiki/EbtablesPS: всё таки это ARP флуд был, но генерит его твой же сервер :)
PSS: есть ещё вариант решения, оставить одну сетевуху и на неё повесить две сети, два IP.
Что-то я не наблюдаю таких багов на Debian 5.
> Что-то я не наблюдаю таких багов на Debian 5.м.б. там полечили, а наблюдать надо с помощью команды http://ru.wikipedia.org/wiki/Arping
естественно с другой машины.
>> Что-то я не наблюдаю таких багов на Debian 5.
> м.б. там полечили, а наблюдать надо с помощью команды http://ru.wikipedia.org/wiki/Arping
> естественно с другой машины.Я только сейчас понял о чём речь. Никакой это не баг, а вполне адекватное поведение ядра, т.к. по-умолчанию обращение к любому интерфейсу разрешается с любого интерфейса.
Заноситься такие "соответствия" (как вот ниже я привёл) не будут в кэш arp клиента т.к. отсылающая запрос станция видит, что запрос к IP-адресу не из её подсети. В этом случае она шлёт пакеты на дефолтный маршрут, поэтому и arp-запрос будет выполнен только ко внутреннему интерфейсу шлюза для определения его мака, либо не будет выполнен вообще, если кэш итак свежий.
Баг т.е. соответствия mac/ip в таблице у клиента:внешIP/внутр mac
внутрIP/внутр macможет быть только в том случае, если IP-адреса у сервера на обоих интерфейсах из той же подсети, что и у клиента. В этом случае нужно в ручную в таблице маршрутизации указывать - на каком конкретно интерфейсе тот или иной хост. Это тупо. Так никто не делает. Ну а если делают, то оооочень крайних случаях в виде исключения, когда компов от силы 2-3.
И, кстати, даже в этом случае несоответствия по сути нет. Если оба адреса висят через один интерфейс, то да. Это именно так и должно выглядеть в arp-таблице клиента. И причём должно работать нормально, если маршруты на шлюзе прописаны верно.
Можно почитать в каком RFC это "нормальное поведение" описано и узаконено ?
И ведут ли себя так же форточные компьютеры?Кстати из разных подсетей интерфейсы так же отвечают, сам видел.
Сижу в сети провайдера 10.xxx.0.0/8 даю ARPING 192.168.1.1 и вижу несколько ответов с разными MAC, ага думаю, роутеры в локалке.
Вот так-то.Мне вообще кажется что в Linux сеть сделали тяп ляп, оно и понятно.
Нет RFC по Linux.о поведении форточных компьютеров я могу тоже кое-что сказать. Например ты пробовал на XPшке расшарить подключение? Тебя не удивило появление, в той сети, в которую шарить, неуправляемого DHCP-сервера принудительно всем раздающего адреса из сети 192.168.1.0? :-))
В каком RFC такое поведение узаконено? ) Вот и я про то же.
>Кстати из разных подсетей интерфейсы так же отвечают, сам видел. Сижу в сети провайдера 10.xxx.0.0/8 даю ARPING 192.168.1.1 и вижу несколько ответов с разными MAC, ага думаю, роутеры в локалке.
Быдлороутеры , d-link и пр вата )) Если бы на них был настроен секьюрный фаервол хрен бы такая штука сработала.
Нормальная сеть у пингвинов. По-мне дак она, как автомат Калашникова работает, надо только знать как собрать и разобрать :-)
А вот в окошках есть кнопочка "исправить" которая регулярно обламывается получить новый адрес по DHCP и приходится класть весь интерфейс. А в самом плохом случае перезагружать винду, так как интерфейсы там тоже бывает тупят.
>Кстати из разных подсетей интерфейсы так же отвечают, сам видел.Отвечать то они ответят. Я говорю про то, что записи в arp-таблицах не делаются в таком случае. Поэтому говорить о том, что arp или linux работает некорректно нельзя.
> Нет RFC по Linux.При чём тут линух, по сетям, в каких документах регламентировано такое поведение? Или то что сделали в линухе теперь стандарт для всех как закон? тогда это фанатизм.
> о поведении форточных компьютеров я могу тоже кое-что сказать. Например ты пробовал
> на XPшке расшарить подключение? Тебя не удивило появление, в той сети,
> в которую шарить, неуправляемого DHCP-сервера принудительно всем раздающего адреса из
> сети 192.168.1.0? :-))Именно в XP расшаривал, почему-то DHCP у меня не появлялся ни разу, хотя нужен был. Вот то что он принудительно сеть выбирал только 192.168.1.0/24 и с другой не работал, это от убогости ума мелкософта.
> В каком RFC такое поведение узаконено? ) Вот и я про то
> же.см. в начале.
>>Кстати из разных подсетей интерфейсы так же отвечают, сам видел. Сижу в сети провайдера 10.xxx.0.0/8 даю ARPING 192.168.1.1 и вижу несколько ответов с разными MAC, ага думаю, роутеры в локалке.
> Быдлороутеры , d-link и пр вата )) Если бы на них былтак же на линух машинах это видел, и не я один, версию ядра не подскажу
> настроен секьюрный фаервол хрен бы такая штука сработала.
с каких пор iptables умеет фильтровать ARP ? я им даже DHCP клиента не мог отфильтровать, потому что этот гад открывал сырой сокет, и клал на фильтры. Кстати ARP не должно в ядро попадать, оно должно крутится около своего адаптера, по большому счёту ядру вообще не нужно знать об этих пакетах.
> Нормальная сеть у пингвинов. По-мне дак она, как автомат Калашникова работает, надо
> только знать как собрать и разобрать :-)А ещё надо тысячу её собственных нюансов учитывать, про которые постоянно забываешь. Один большой +, всё бесплатно, и делай шо хошь.
> А вот в окошках есть кнопочка "исправить" которая регулярно обламывается получить новый
> адрес по DHCP и приходится класть весь интерфейс. А в самом
> плохом случае перезагружать винду, так как интерфейсы там тоже бывает тупят.Эта кнопочка у меня нормально работает, если например клиент подымется раньше чем DHCP сервер после вкл. питания, то эта кнопочка хорошо помогает. А вот чтоб новый попросить, она не поможет, у тебя ведь аренда не истекла, не имеет права, для этого сначала адрес освободи ipconfig /release а потом новый проси. Лучше просто скрипт написать, если часто надо.
> При чём тут линух, по сетям, в каких документах регламентировано такое поведение?
> Или то что сделали в линухе теперь стандарт для всех как
> закон? тогда это фанатизм.Я уже утерял нить беседы. ))))) Короче в Linux с помощю sysctl можно выбирать маршрутизируемые интерфейсы. Закончим на том, что реализация arp в Linux не нарушает RFC826(ARP) при любом раскладе, так как по любой из записей в arp-таблице можно достучаться до IP. :-)
> с каких пор iptables умеет фильтровать ARP ? я им даже DHCP
> клиента не мог отфильтровать, потому что этот гад открывал сырой сокет,
> и клал на фильтры.Кроме iptables существуют ещё и arptables и ebtables. Вообще пытаться запретить клиенту получить адрес по DHCP странная затея в принципе. Не могу себе представить ситуацию когда бы такое требовалось. Если дело касается провайдерской раздачи интернетов, то там как правило используются туннельные решения, что в принципе исключает подобные проблемы. DHCP сам по себе, в принципе, не предназначен для таких задач, какую ты пытался решить.
> Кстати ARP не должно в ядро попадать,
> оно должно крутится около своего адаптера, по большому счёту ядру вообще
> не нужно знать об этих пакетахНе знаю, я не программист, но Линус, похоже считает иначе. :-)
> А ещё надо тысячу её собственных нюансов учитывать, про которые постоянно забываешь.
У любой системы есть свои нюансы.
> Я уже утерял нить беседы. ))))) Короче в Linux с помощю sysctl
> можно выбирать маршрутизируемые интерфейсы. Закончим на том, что реализация arp в
> Linux не нарушает RFC826(ARP) при любом раскладе, так как по любой
> из записей в arp-таблице можно достучаться до IP. :-)И как показала практика, автора топика, до чужого также и далеко не без отрицательных последствий. А раз в систему заложен разрушительный механизм, который делает лишние и ненужные действия, значит логически можно предположить что это не правильно. Я опираюсь в своих суждениях на логику, а не на фанатизм.
> Кроме iptables существуют ещё и arptables и ebtables. Вообще пытаться запретить клиенту
> получить адрес по DHCP странная затея в принципе. Не могу себе
> представить ситуацию когда бы такое требовалось. Если дело касается провайдерской раздачи
> интернетов, то там как правило используются туннельные решения, что в принципе
> исключает подобные проблемы. DHCP сам по себе, в принципе, не предназначен
> для таких задач, какую ты пытался решить.Вы не поняли ситуацию, есть провайдер, он выдаёт по DHCP адреса, но попадались у него умники втыкавшие не тем концом роутеры в его сеть, и так же раздавали адреса.
> Не знаю, я не программист, но Линус, похоже считает иначе. :-)
Похоже линукс писали не боги и там попадаются неграмотные программисты, а неграмотные, потому что "багу" уже много лет, а он до сих пор не исправлен. И мне не понятно, зачем нужно предпринимать лишние действия, напрягая при этом процессор, дабы отфильтровать ненужное поведение ОС.
> И как показала практика, автора топика, до чужого также и далеко не
> без отрицательных последствий. А раз в систему заложен разрушительный механизм, который
> делает лишние и ненужные действия, значит логически можно предположить что это
> не правильно. Я опираюсь в своих суждениях на логику, а не
> на фанатизм.У меня и своя практика под рукой. Не могу сэмулиовать ситуацию в которой возникал бы такой баг:
> Пишу у клиента arp -a и он определят мак сервера той сетевухи, которая в инет смотрит, а не в локалку. Во как! Т.е. IP от eth0 а mac от eth2 (см. начало темы).
> У меня и своя практика под рукой. Не могу сэмулиовать ситуацию в
> которой возникал бы такой баг:
>> Пишу у клиента arp -a и он определят мак сервера той сетевухи, которая в инет смотрит, а не в локалку. Во как! Т.е. IP от eth0 а mac от eth2 (см. начало темы).к сожалению ни чем помочь не могу, гадалку в отпуск отправил :)
другими словами, ситуация плохо описана. Да и проверять надо RPING-ом, ибо работа в среде описанной автором это лотерея.
К тому же, вы не потрудились выяснить у автора какая у него версия ядра и ОС, а это имеет значение. Эксперимент должен быть чистым.
Ну будь здоров. :-)
вот ответ на твой вопрос, случайно наткнулсяhttp://www.opennet.me/base/sys/sysctl_linux.txt.html
net.ipv4.conf.all.arp_filter = 0
Включает/выключает связывание IP-адреса с ARP-адресом. Если эта опция
включена, то ответ будет передаваться через тот интерфейс, через который
поступил запрос. В принципе, было бы не плохо, если бы ответы исходили
через тот же интерфейс, через который был получен запрос, однако, в
отдельных случаях, это может стать причиной ошибок. Обычно включение
этой опции необходимо только в том случае, если на вашем хосте
производится управление распределением нагрузки между сетевыми
интерфейсами. Значение по-умолчанию 0 (выключено), поскольку эта опция
идет немного вразрез с современным пониманием принципов IP-адресации.
Ранее IP-адреса рассматривались как путь к некоторому устройству, в
смысле аппаратуры, теперь же их следует рассматривать как отдельную
службу доставки, которая должна выдавать ответы на запросы вне
зависимости от того на какой интерфейс эти запросы были получены.
Дополнительную информацию по данной тематике вы найдете в Guide to IP
Layer Network Administration with Linux.
> Вспомнил, это древний баг ARP протокола в Linux системах.
> Поясню на примере, имеем
> Net1-----[{MAC1,IP1}PC{MAC2,IP2}]-----Net2
> так вот, если дать ARP запрос из Net1 для IP2, то получим
> ответ MAC1,IP2.
> Этот баг некоторые провайдеры использовали для поиска роутеров у клиентов.Так я дал запрос из Net1 для IP1 и получил MAC2, это случаем не немного другое?;)
> Как от этого избавится?
> как уже говорил, писать клиентам статическую ARP таблицу,Необходимо у каэдого прописать arp -s 192.168.102.102 "соответствующий этой сетевухе мак"???
И добавить батник в автозагрузку
> второй вариант, фильтровать на сетевухах не свои ARP запросы, например с помощью
> ebtables http://ru.wikipedia.org/wiki/EbtablesЧто-то не понял я логику этого инструмента, не пояснишь?
> PS: всё таки это ARP флуд был, но генерит его твой же
> сервер :)Что-то мне подсказывает, что это окажется не единственной проблемой)))
> PSS: есть ещё вариант решения, оставить одну сетевуху и на неё повесить
> две сети, два IP.Это не скажется на производительности сервера, скорости интернета???
Клиентов будет где-то 30, ширина канала 20 Мбит, сетевуха 100 Мбит, пользователи юзают P2P сети, то есть выжимают из канала всё.
> Так я дал запрос из Net1 для IP1 и получил MAC2, это
> случаем не немного другое?;)То же самое, только у тебя обе сетевухи в одну сторону смотрят и отвечают почти одновременно, от какой ответ раньше придёт, тот MAC и пользуется :)
> Необходимо у каэдого прописать arp -s 192.168.102.102 "соответствующий этой сетевухе мак"???
думаю этого будет достаточно, но это через ж...у,
> Что-то не понял я логику этого инструмента, не пояснишь?
Нет, не пользовался этим пакетом, ищи информацию самостоятельно.
> Что-то мне подсказывает, что это окажется не единственной проблемой)))
с такой организацией сети, вполне может быть.
> Это не скажется на производительности сервера, скорости интернета???
> Клиентов будет где-то 30, ширина канала 20 Мбит, сетевуха 100 Мбит, пользователи
> юзают P2P сети, то есть выжимают из канала всё.В сети гигабитные HUB-Switch используются? нет?, тогда как это скажется на производительности?
> В сети гигабитные HUB-Switch используются? нет?, тогда как это скажется на производительности?Всякие стоят и на 100 Мбит и на 1 Гбит пара-тройка есть, свитчей вообще гора, здание - общага, тут в коридоре на каждом этаже свитча по 4 более или мение нормальных и в каждой комнате стоит такой, как жильцы купят.
Сделала через 1 сетевуху, повесил на нее 2 ипа, грузится теперь вроде все полностью, но если раньше тест скорости у клиента стабильно выдавал 5-6 Мбит, то теперь выше 800 Кбит не поднимается. Не подходит получается такое решение к данной проблеме!?
> Сделала через 1 сетевуху, повесил на нее 2 ипа, грузится теперь вроде
> все полностью, но если раньше тест скорости у клиента стабильно выдавал
> 5-6 Мбит, то теперь выше 800 Кбит не поднимается. Не подходит
> получается такое решение к данной проблеме!?не могу по этому поводу ничего сказать, т.к. не проводил исследований.
И так на всех клиентах?
> И так на всех клиентах?Вроде на всех
>> И так на всех клиентах?
> Вроде на всехХотя НЕТ! У кого какой MAC из двух возможных определяется