3COM Switches/Коммутаторы

[RiddlerX2]

Здравствуйте всем,
У меня на фирме возникает временами непонятная мне проблема, в одной из логических подсетей установлены свичи, последовательно друг за другом, таким образом получается цепочка:
Маршрутизатор 3com4500-\1000Mb/s\-3Com4200-\100mb/s\-D-Link DSS-16+
К 3com подключено 10 компов, к D-link - 8
В произвольное время 4200 отключает порт на котором сидит D-link, при этом более не восстанавливая подключение.
По статистике 4200 пишет, что на этом порту происходят ошибки.
Мне понятно что по требованию стандарта Ethernet порт при определенной частоте ошибок порт обязан быть отключен, это и происходит.
Но я проверил все что можно: оборудование, кабель, коннекторы, и все идеально.
Переключал свич в другой порт, все равно вылетает, если не через пару часов, то на следующий день.
Было подозрение, что отключение происходит в моменты нагрузок, но имеются случаи отключения ночью, когда в помещениях никого не было, такое ощущение, что просто кадры теряет в процессе обмена служебными сообщениями.
Есть конечно подозрение, хотя и маленькое, на агрессивность среды, но я не знаю как ее проверить.

Есть и идеи решения проблемы (пока ничего не пробовал, хотел посоветоваться):
1. Снизить скорость до 10mb/s.
2. Установить полудуплекс вместо полного.
3. Дотянуть крайний свич непосредственно до маршрутизатора (но это практически не выполнимо из-за превышения длины сегмента получится более 100 м., я замерил где-то 130 м.)
4. Есть конечно возможность перетянуть все концы на 4200, а крайний свич вообще убрать.

И еще есть вопрос, сама сеть весьма обширна 10 свичей, маршрутизатор, 3 логических сегмента, 60 рабочих станций и 2 сервера.
Правило 4-х свичей ограничивается одной подсетью или распространяется на всю физическую структуру?
Вопроса на этот ответ в самом правиле я почему-то не нашел, или может я плохо читал :-(

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

[kim-aa]

по требованию стандарта Ethernet порт при определенной частоте ошибок порт обязан быть отключен, это и происходит.
Думаю это настройки 4200. По требованию стандарта Ethernet отключения пртов происходят лишь при наличии петель.
Неправильные фреймы просто отбрасываются.
Возможны отключения в случае сильных наводок или явном присутствии фазы питания на одном из информационных проводников кабеля.
Попробуйте померить напряжение тестером между каждым проводником кабеля (при включенном D-Link) и батареей или арматурой.

на агрессивность среды, но я не знаю как ее проверить.
Снифером сети типа Ethereal.

Правило 4-х свичей ограничивается одной подсетью или распространяется на всю физическую структуру?
Правило 4-х сегментов (3х хабов/репитеров/поаторителей) вобще-то существовало для 10Base-T.
Правило действует в домене коллизий, т.е. физическом сегменте (Т.е до первого порта хотя-бы второго уровня, а они у Вас все второго).
Для 100Base-TX есть правило 2-х повторителей (хабов).
Для свичей явно такого правила не существует. У них есть ограничение вызванное стандартными настройками Spanning Tree протокола в 7 мостов/свичей, но и оно не существенно при явном отсутствии петель в топологии.

Чесно говоря, я бы или перетянул все на 4200 или взял в долг свичик поприличнее D-Link (хотя бы Alied Telesyn) и попробовал, не хочу возводить напраслину, но больно D-Link'овское оборудование иногда странно работает.

[ShellL]

предварительно я бы посадил вероятно проблеммное сетевое оборудование на гарантированное питание с фильтрацией (поставил бы хорошие ИБП)

[RiddlerX2]

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

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

Снифером сети типа Ethereal
Попробую раздобыть и проверить, спасибо за подсказку.

[kim-aa]

Сегодня рискнул на эксперимент и переключил порт в полудуплекс, дикие коллизии, фактически каждый третий октет, но порт за сегодня не отвалился

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

Я бы:
- при наличии кабельного тестера проверил линию соединяющую свичи (но он редок - недешевая штука)
- В случае наличия бухты приличного кабеля - размотал бы прямо по коридору резервную ветку, обжал бы ее кроссовым соединением на 100 и проверил по ней.
(Кстати соединения свичей "прямое" - т.е. Вы воспользовались автосогласованием или "кроссовое"?)
- Ну и повторю свой совет по поводу пробы иного свичика.
- Кстати если свич работает некорректно и "взбесился" какой-либо клиент сегмента, то проверку можно осуществить простым поочередным физическим подключением их к свичу сегмента и одновременным мониторингом состояния порта 4200 - тут главное не торопится и выдерживать 3-5 минутные паузы между подключениями, дабы видно лучше было.

[ShellL]

3. Дотянуть крайний свич непосредственно до маршрутизатора (но это практически не выполнимо из-за превышения длины сегмента получится более 100 м., я замерил где-то 130 м.)
я как понял у Вас кусок кабеля такой длины, предлагаю попробовать заземлить оплетку кабеля (если UTP5 с фольгой) а именно фольгу с одной из сторон

[RiddlerX2]

To kim-aa,
Да вот фиг знает что происходит, у меня уже нет никакого терпения )))
1. По порядку отвечаю, широковещательная активность не велика, ну или для меня не велика (опять таки я ссылаюсь на статистику порта на 4200, но у него статистика в октетах, а они бывают разной длины, возможно имеет смысл статистику посмотреть?).
2. Кабельный тестер есть, линия в порядке, проверял несколько раз.
3. Да соединение прямое, поскольку на сегодня я так понимаю это не принципиально, по поводу кросса ниже.
4. Пока не могу достать другого свича ((.

Небольшая предистория всей этой ерунды:
Проблемы начались где-то год назад.
Когда у нас сгорел один из двух восьмипортовых хабов стоявших на месте сегодняшнего злополучного Д-Линка.
Т.е. фактически как только поставил 16-ти портовый свич, тут же начались траблы с отключением, буквально на следующий день.
Был поменян сперва свич, но к сожалению на аналог, проблема не исчезла, я отвозил его в сервисцентр, но там его вернули и сказали, что они не приделах все работает.
Менял этот сегмент кабеля, обжимал его сперва кроссом потом прямым.
Результатов не было.
А потом когда я доделывал сетку и за Д-Линком ставил дополнительный хаб пятипортовый, все проблемы резко исчезли.
До недавнего времени, когда у нас случилась куча переездов и я тот хаб убрал.
Все проблемы снова начались, собственно поэтому уже и обращаюсь к общественности.

Может вернуть тот хаб на место просто для красоты лишь бы только сеть работала, но это смешно, я хочу найти проблему.

To ShellL,
Нет два свича стоят схематически как бы вряд, и получается два сегмента кабеля по 90 и 60 метров, я посчитал и походил по зданию, если прямой тянуть он получится короче, но не сильно, минимум 130 метров.

[ShellL]

верни обратно этот хаб

может проанализировать что в принципе поменяется в сети и в распределении сигналов с появлением этого хаба
вот у меня как раз и никакой мысли по этому поводу нет
может у тебя есть какие догадки ?

[kim-aa]

Сегодня рискнул на эксперимент и переключил порт в полудуплекс, дикие коллизии, фактически каждый третий октет, но порт за сегодня не отвалился.
Нахожусь в замешательстве.
Кстати такое возможно если не прошла процедура автосогласования режимов портов, т.е. порт одного свича работает в дуплексе, а второго в полудуплексе.
http://wiki.oszone.net/index.php/IEEE_802.3#.D0.9F.D0.BE.D0.BB.D0.BD.D0.BE.D0.B4.D1.83.D0.BF.D0.BB.D0.B5.D0.BA.D1.81.D0.BD.D1.8B.D0.B 9_.D1.80.D0.B5.D0.B6.D0.B8.D0.BC


А потом когда я доделывал сетку и за Д-Линком ставил дополнительный хаб пятипортовый, все проблемы резко исчезли.
Тут возможны два сценария, но по одной причине - кривой свич:
1) Свич не держит электрически нагрузочную способность.
2) Помер какой то из буферов и свич фактически хреново работает в полном дуплексе, хотя сам (что нормально) при малейшей возможности пытается перейти в полнодуплексный режим.

[RiddlerX2]

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

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

верни обратно этот хаб
Это не совсем приемлемо, но если уж совсем руки опустятся, то верну, но я ищу не временное решение, а проблему.

[toll3]

Имеется пару свичей аля "3com SuperStack 4500 switch" - пытаюсь их в стэк вогнать. Делаю всё как в мануале сказано вроде, свичи видят друг друга, стэк поднимается, сетка вроде работает, но есть несколько но:
1. Над портами гигабитными горит жёлтый индикатор, что по идее неправильно;
2. На интерфейсах ошибки сплошные:
<4500>disp interface GigabitEthernet 1/0/52
GigabitEthernet1/0/52 current state : UP
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0026-с02c-1254
The Maximum Transmit Unit is 1500
Media type is twisted pair, loopback not set
Port hardware type is 1000_BASE_T_AN_SFP
1000Mbps-speed mode, full-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 1522
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
PVID: 1
Priority: trust
Mdi type: auto
Port link-type: xrn-fabic
Tagged VLAN ID : all
Untagged VLAN ID : none
Last 300 seconds input: 134 packets/sec 23060 bytes/sec
Last 300 seconds output: 152 packets/sec 82979 bytes/sec
Input(total): 122036 packets, 23306992 bytes
25556 broadcasts, 25353 multicasts
Input(normal): - packets, - bytes
- broadcasts, - multicasts
Input: 820 input errors, 0 runts, 820 giants, - throttles, 0 CRC
0 frame, - overruns, 0 aborts, 0 ignored, - parity errors
Output(total): 177711 packets, 52376525 bytes
76134 broadcasts, 28900 multicasts, 0 pauses
Output(normal): - packets, - bytes
- broadcasts, - multicasts, - pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, - no carrier

Собственно не могу понять куда копать? Может порты не те соединяю, кто-н работал с данным семейством свичей? У них 4 гигабитных порта, при чём идёт парами (и промаркированы они па разному).

Заранее спасибо.

[kim-aa]

820 giants
Все фреймы прибывшие на интерфейс GE 1/0/52 распознаны как превышающие максимально допустимую длинну. Копайте настройки интерфейса на обратной стороне.

Да кстати, в кабеле/пачкорде вы уверены?

[rcn]

Прив всем! помогите сломался свитч 3300XM(3C16985). При включении загорается лампочка Self-test потом с 1 по 12 порт пробегает желтый огонек и снова запускается self-test и так по кругу! Терминалом подключился- пару раз успел дойти до ввода логин, но тут же все подвисало!

[toll3]

kim-aaсе фреймы прибывшие на интерфейс GE 1/0/52 распознаны как превышающие максимально допустимую длинну. Копайте настройки интерфейса на обратной стороне.ммм... настройки интерфейсов всех одинаковые - дефолтные. По вашему мнению причиной ошибок является строчки:
The Maximum Transmit Unit is 1500
The Maximum Frame Length is 1522
(одиаковые для всех свичей) - насколько я понимаю длина фрема приходящего превышает 1522 байта?
Но интересно, у меня исходящий и приходящий интерфейс то один и тотже - в стэке свичи соеденены 1 проводм (обычнае витая пара 5-й категории) - т.е. 1-й свитч одним проводом воткнут во второй свич, второй 2-м проводом воткнут в 3-й свич. (как это и сказано в мануале). Соот-но если уменьшить frame size на исходящем интефейсе свича наск. я понимаю это автоматом уменьшит входящий размер фрейма и мы придём к тому же самому варианту...? :search:
Да кстати, в кабеле/пачкорде вы уверены?их несколько и у всех типичная ошибка... сами провода (как я уже писал протые вит.пары 5-й категории) в обычной 100М сетке работают нормально, тестером тестируются тоже вроде всё впорядке...

[kim-aa]

toll3
Вы наверное меня не поняли. Настройки размеров фреймов правильны, только они правильны для стандартного ethernet-соединения.
Думаю (это мои допущения тк я не специалист по стекируемым коммутаторам 3COM) при стекировании порт переходит в нестандартный режим работы, и сообщение сигнализирует что отправляются фреймы нормально, только вот приемный порт не распознает формат. Он воспринимает их как стандартные и выводит ошибку превышения макс. допустимого размера.

Опять же в гигабитном режиме существуют моды когда размер фреймов превышает стандартные значения для 10/100 (см. )Расширение несущей для 1000-BaseT (http://wiki.oszone.net/index.php/IEEE_802.3#Gigabit_Ethernet_.E2.80.93_.D0.B4.D0.B8.D0.B0.D0.BC.D0.B5.D1.82.D1.80_.D1.81.D0.B5.D1.82. D0.B8._.D0.A0.D0.B0.D1.81.D1.88.D0.B8.D1.80.D0.B5.D0.BD.D0.B8.D0.B5_.D0.BD.D0.B5.D1.81.D1.83.D1.89.D 0.B5.D0.B9.)

Что касается кабеля, то он должен быть маркирован как 5E или 6.
Я бы не рисковал и обжал стандартный кросс кабель для 1000-BaseT (см. предыдущую ссылку рис. 13)

[toll3]

kim-aa
да спасибо, похоже это именно неправильное формирование фрема у коммутатора приводит к таким ошибкам:
4500 - Giant errors incrementing on XRN uplink ports

Problem: Giant errors incrementing on XRN uplink ports

Fact: Switch 4500
Fact: Switch 4500 26-Port
Fact: Switch 4500 50-Port

Fact: giant counter incrementing
Fact: Jumbo packets incrementing giant counter
Fact: input error total
Cause: The giant count will increment for packets larger than 1522 bytes for a standard LAN port.
If a packet length of 1515 - 1518 bytes must traverse an XRN port, 4 bytes are added for VLAN tag information and 4 bytes for special XRN processing, exceeding the 1522 packet size, which will increment a giant counter.

Giants are mistakenly counted in the "input error" total and they shouldn't be, as they are not errored packets, just ones greater than the Standard Ethernet maximum.


Fix: This is working as designed.
спасибо за подсказку!!

[tranceporter]

всем привет.
имеется 3com 3040.
я настроил dhcp и atm

1) как настроить dns? в cli нет ни одной команды, которые есть в описании
2) atm видит adsl, но dialer все время up и меньше чем через секунду down.
3) в описании сказано создать virtual-ethernet для atm0 - не понимаю, как внутренний ethernet 1/0 зароутить на этот virtual-ethernet ?

заранее балгарин.