RTL8309SB глючит trunk

[=Dmitry=]

Запаял 4,7к с 97-й ноги на землю, соединил порты 0,1 двумя

патчкордами, транк на портах 0,1 включился, но:

- пакеты ходят только через порт 1.

- если выдернуть один из транковых портов (любой), пакеты не ходят вообще.

 

Что с EEPROM что без нее, ситуация одинаковая.

Перекрещивание транковых портов (0-1 1-0) то же не помогает.

Порту 0 как я выяснил, нужен просто линк, с кем угодно,

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

С помощью EEPROM перекидывал транк на порты 6,7, опускал эти порты на 10мбит, ставил свичам разные MAC, ни чего не помогает.

 

Это баг чипа, или я что то не так делаю?

 

Свичи Canyon, оба одинаковые.

Порты в них развернуты задом на перед, это я в курсе.

 

Кстати, для нормальной работы EEPROM (24LC02) ей надо не 3,3 а 2,5...2,7в, подпорки 4,7к на ее же питание по SDA/SLC/WP, другие варианты глючат (питание у свича одно - 1,9в).

[Barsick]

Проверял на столе с двумя компами или на реальной сети?

[=Dmitry=]

Проверял на столе с двумя компами или на реальной сети?

 

А разница?

Сервак под FreeBSD 4 и станция под Win2k, станция воткнута в отдельную сетевуху сервака по соображениям секурити, все настроено, проверенно, работает.

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

[=Dmitry=]

Проверял на столе с двумя компами или на реальной сети?

 

Наводящий вопрос попал в точку :-)

Подключил вторую станцию и обнаружил...

 

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

 

Реалтек опять дурит потребителя, как много лет назад с "16-битными"

ISA видяхами 3105, которые на деле оказались 8-битными, а дорожки

старших 8-и бит заканчивались под буфером ПЗУ :-(((

[Nailer]

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

 

Что по-вашему есть "грязный хак MAC-автомата"? Даже каталисты балансируют по хэшу из SMAC+DMAC, что вам не нравится, собственно?

 

Попакетно баласировать умеют только роутеры, и то не все..

[=Dmitry=]

Вот SMAC+DMAC и есть "грязный хак", по тому как "балансировкой" это назвать ну ни как нельзя.

Одна пара может полностью загрузить один канал, второй при этом будет практически простаивать, при обрыве одного из линков пол сети вообще отрубится :-(

 

Собственно от чего сыр-бор...

Настала пора думать о расширении одного DSL-линка,

2,3Mbps скоро закончатся, недорогое оборудование

типа Planet GRT-402 при падении одного из транзитов

требует ручного переключения режима с 4-х на 2-х проводку,

причем на обоих концах :-(

Вот и хочется два 2-х проводных модема и что то балансирующее попакетно, причем понимающее

pause frames в случае переполнения буфера одного из них, при падении

или уменьшении скорости одного из линков.

 

В принципе это реализуемо программно на сервере, но несколько

сложновато и менее надежно.

[Nailer]

Вот SMAC+DMAC и есть "грязный хак", по тому как "балансировкой" это назвать ну ни как нельзя.

Одна пара может полностью загрузить один канал, второй при этом будет практически простаивать, при обрыве одного из линков пол сети вообще отрубится :-(

 

Ну нету другого механизма балансировки на втором уровне. Можно еще при помощи PVST/MST - но тоже все статистическим методом, нету per-packet.

 

Собственно от чего сыр-бор...

Настала пора думать о расширении одного DSL-линка,

2,3Mbps скоро закончатся, недорогое оборудование

типа Planet GRT-402 при падении одного из транзитов

требует ручного переключения режима с 4-х на 2-х проводку,

причем на обоих концах :-(

Вот и хочется два 2-х проводных модема и что то балансирующее попакетно, причем понимающее

pause frames в случае переполнения буфера одного из них, при падении

или уменьшении скорости одного из линков.

 

В принципе это реализуемо программно на сервере, но несколько

сложновато и менее надежно.

 

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

 

ИМХО, вам лучший выход - использовать роутеры.

[=Dmitry=]

Попакетно - не лучший вариант, пакеты могут приходить в изменившемся порядке

 

До этих тонкостей пока не докапывался,

на сколько это болезненно для GRE/PPPoE/IP?

(под IP подразумевается не только TCP, а все что там может бегать).

[Nailer]

Попакетно - не лучший вариант, пакеты могут приходить в изменившемся порядке

 

До этих тонкостей пока не докапывался,

на сколько это болезненно для GRE/PPPoE/IP?

(под IP подразумевается не только TCP, а все что там может бегать).

 

Для UDP и особенно VoIP - вообще смертельно, невовремя пришедший пакет дропается. А вообще болезненно для любого протокола, который не может восстановить правильную последовательность пакетов.. TCP, если память не изменяет, восстанавливает, а вот PPPoE - не знаю..