Локальные сети

У меня дома была локалка для двух компов на витой паре без хьюба. На одном - Win3.11, на другом - Win98. Протокол был NetBEUI, без TCP/IP.

Дилетант прав.

1) - нет

2) - конечно, можно через IPX, но зачем?
Делай через ТЦП/ИП и поставь еще и ИПХ. Для игрушек, да?
И ось - 98 <-> 98.

Так легче всего настраивается.

IP адресса:

1. 192.168.0.1
2. 192.168.0.2

Маски - 255.255.255.0

В свойствах сетевого окружения надо прописать одна и та же рабочая группа, разрешить шеринг файлов (и если есть, принтеров).

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

А, еще. Если обе карточки на витой паре, то хаб не нужен. Но нужен перекрестный сетевой кабель! Это важно! Иначе просто сетевые карты работать не будут.

varban>IP адресса:

varban>1. 192.168.0.1
varban>2. 192.168.0.2

varban>Маски - 255.255.255.0

varban, а и не знал, что ты хакер Falcon ставь ЛЮБЫЕ адреса(например 10.0.0.1 и 10.0.0.2), от балды(и желательно балды рандомизированной ), особенно, если хочешь выходить в Инет!

Ник

Please help!

1) Нужно-ли для локалки из двух компов ставить на сервере (протокол TCP/IP) специальную операционку(2000, NT)?

2) Подскажите как замутить локалку ч/з IPX .

Я продолжу старческое ворчание.

Так вот, когда говорят о классах, то маски не нужны - и так структура адреса жесто задана певыми битами адреса (напомню, что есть еще и класс D, который используется для muliticasting). А маска это другое выражение нотации /число. /число определяет число единиц в маске если считать слева. Так например, 192.168.0.0/24 говорит о том, что первые 24 бита это номер сети, а остальные 8 - номер хоста, что эквивалентно маске 255.255.255.0. Если постмотреть на RIPE политику (http://www.ripe.net), то выясниться, что эта организация установила правила по выделению сетей минимального размера - надо 9 IP - выделять сетку на 16 - с маской /28 (255.255.255.240) - не хватает IP адресов. Но это плохо согласуется с агрегацией в BGP4 протоколе - и приходиться иногда их дурить или мудрить с upstream интернет провайдером, особенно когда более одного канала через разных провайдеров и хочеться адвертайзать пути так, чтобы разный трафик ходил разными путями.

все закончил, тем более, что это оффтоп.

Nick_Crak>от балды(и желательно балды рандомизированной ), особенно, если хочешь выходить в Инет!

Не заметил сначала. оба компа должны находиться в одной (!) подсети. иначе друг друга не увидят (та часть адреса, что покрыта 1-и в маске должна быть одинакова). Для форточек это еще более важно, т.к. они отрабатывают таблицу роутинга немного не так как все. Можно добиться того, чтобы на одной физической сети существует несколько IP подсетей, но для этого надо делать телодвижения.

varban>>IP адресса:

varban>>1. 192.168.0.1
varban>>2. 192.168.0.2

varban>>Маски - 255.255.255.0

Nick_Crak>varban, а и не знал, что ты хакер Falcon ставь ЛЮБЫЕ адреса(например 10.0.0.1 и 10.0.0.2), от балды(и желательно балды рандомизированной ), особенно, если хочешь выходить в Инет!

??? А чем 10 лучше 192.168??? те же non routable адреса, только класса А, а не С. Кстати, на интеренете давно уже нет классов - с момента введения CIDR - RFC 1467, 1517, 1519, 1520, 1817. Во многих местах говорят о масках как /число - 192.168.0.0/24 - это класса С как ранее было, 192.168.0.0/16 - это класса В по ранней классификации, а можно и 192.168.1.252/30 - всего 2 компьютера (0 и 255 специальные адреса).

Кстати, если охота в интернет выходить с реальными адресами, то от балды нельзя, а то придеться NAT ставить, а он обрезает настоящий интернет по самое нихочу.

А адреса не случайно выбрали почитайте http://www.ietf.org/rfc/rfc1918.txt?number=1918, вот цитата:
3. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

We will refer to the first block as "24-bit block", the second as
"20-bit block", and to the third as "16-bit" block. Note that (in
pre-CIDR notation) the first block is nothing but a single class A
network number, while the second block is a set of 16 contiguous
class B network numbers, and third block is a set of 256 contiguous
class C network numbers.

Кстати, вот и про CIDR.

А, если адреса от балды ставить, и ваш NAT упустит их каким-то образом в интернет, то ситуация такая - если это прайвет адрес, то ближайший раутер его проигнорирует и дальше не пошлет, а, если реальный, то может и переслать (если у провадера AL настроены коряво или же оказался через чур реальным), а это может сойти за спуф и можно получить от провайдера по голове.

Но обычно dial up получает динамически адрес и, если таблицу роутинга не трогать, то все работает ок.

Nick_Crak>Ник

По существу топика - Варбан прав - два адреса, одна рабочая группа (это, чтобы Форточкам было легче). Только зачем IPX еще? Кто-то объяснит? А то я более по IP сетям все больше...

Да, если все-таки есть интернет доступ, то с разделением файлоы и принтеров надо быть очень осторожным - 98 и так не шибко защищена, а с шерами и вообще ломается за милую душу. Я не знаю как сейчас, но обычно найти программку на инете, которая это делает - не занимает много времени. Да и опыт имею - нахождение в dialup-е в районе 2 часов уже достаточно чтобы тебя успевали пощупать несколько раз. Я разные проги устанвливал, чтобы это дело отсекать и провайдерам щупальщикаа отсылать - такой счет закрывался иногда в считаные часы.

IPX нужен для старых игрух Diablo, WarCraft2, Doom/etc

Falcon, получилось?

Мы ставили ip адреса (задолго до того как повесил топик) такими:

172.16.1.N , где N - номер компа

маска: 255.255.255.0

Кстати Starcraft:BW тоже хочет ipx

Но все это напрасно. Мой друг меня обломал. Он снял сетевуху и сказал, что не будет ее пока ставить, гад.

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

Итак, BBR (Bottleneck Bandwidth and RTT) — алгоритм управления задержками на основе заторов. Основная идея: изменение скорости соединения таким образом, чтобы RTT был минимален и утилизация канала была максимальной. Для этого оба параметра постоянно контролируются.

С другими алгоритмами, которые использовались до написания BBR, есть проблема: они используют для контроля скорости потерю пакетов.

Эти проблемы возникли из-за выбора архитектуры, который был сделан при создании системы регулирования заторов TCP в 80-е годы — тогда потерю пакетов решили интерпретировать как «затор». [13] Эквивалентность этих понятий была справедливой для того времени, но только из-за ограничений технологии, а не по определению. Когда NIC (контроллеры сетевых интерфейсов) модернизировали с мегабитных до гигабитных скоростей, а микросхемы памяти — с килобайт до гигабайт, до связь между потерей пакетов и заторами стала менее очевидной.

В современном TCP регулирование заторов по потере пакетов — даже в наиболее совершенной технологии такого рода CUBIC [11] — основная причина этих проблем. Если буферы узких мест слишком большие, то система регулирования заторов по потере пакетов держит их полными, вызывая излишнюю сетевую буферизацию. Если буферы слишком маленькие, то система регулирования заторов по потере пакетов неверно интерпретирует потерю пакета как сигнал затора, что ведёт к снижению пропускной способности. Решение этих проблем требует альтернативы регулированию заторов по потере пакетов. Для нахождения этой альтернативы следует разобраться, где и как возникают заторы.

 

Итак, чем грозит внедрение этого алгоритма? Всякими приятными плюшками как для трафика внутри высокоскоростной сети за счёт уменьшения влияния микробёрстов (из-за переполнения буферов на свитчах), так и для для трафика наружу/снаружи. При этом, достаточно включить данный алгоритм на сервере и все клиенты данного сервера будут использовать все плюшки от этого алгоритма.

Вот картинка:

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

Мы у себя уже начали внедрять эту штуку, благо, она уже в ядре 4.9 присутствует. Достаточно иметь вкомпилированный алгоритм и через sysctl выбрать bbr.

Дополнительные материалы по теме:

Краткая статья

Большая статья

и перевод
UPDATE: Забыл упомянуть, что ещё, через sysctl следует выбрать дисциплину обслуживания fq. Таким образом, ставим ядро 4.9 с активированными нужными опциями и через sysctl задаём:

1. net.core.default_qdisc = fq
2. net.ipv4.tcp_congestion_control = bbr

Учтите, что в рантайме ранее установленная qdisc не поменяется, её можно либо сменить через tc, либо просто перезагрузить хост.