Jump to content

Recommended Posts

Posted

Есть у меня присоединение с одним оператором, который дает мне L2VPN до одного объекта (IP-камера).

Канал скромный (5 Мбит/с), присоединение по витой паре на портах FastEthernet 100 Мбит/с.

Несколько месяцев все работало без нареканий. С месяц назад начались проблемы — задержки, потери пакетов.

Между нашим стыком и конечным объектом много всего — помоему даже радиоканал и SDH имеется — к тому же именно тогда на узле, в который включался конечный объект, оператор делал довольно значительные изменения.

Вообщем начал я выносить мозг тех.поддержке. Перепробовали все — увеличивали MTU, расширяли шейпер, вообще его отключали, меняли приоритет трафика на максимальный, пускали по другим трассам. Но ситуация практически не менялась: непрерывный ping с размером пакета 1000 байт стабильно выдавал около 8% потерь, время отклика было стабильным. Причем процент потерь мало зависил от загрузки канала — ошибки шли даже при нулевой загрузке. От загрузки канала немного увеличивалось время отклика, а потери зависели только от размера пакета - до 500 байт потери были незначительны (менее процента), 800-1200 байт потери были в пределах 10%, а при размере пакета выше 1400 потери приближались к 15-20%.

В конечном итоге решили проверить наш стык. Сама линия (уличная витая пара, примерно 40 метров) была в порядке, а вот на узле оператора я обнаружил то самое, что показано на фотографии. Если плохо видно, то расшифрую — порядок жил: БО, О, С, БЗ, БС, З, БК, К. На второй стороне (у меня) обжато правильно.

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

rj45.jpg

Posted

Есть у меня присоединение с одним оператором, который дает мне L2VPN до одного объекта (IP-камера).

Канал скромный (5 Мбит/с), присоединение по витой паре на портах FastEthernet 100 Мбит/с.

Несколько месяцев все работало без нареканий. С месяц назад начались проблемы — задержки, потери пакетов.

Между нашим стыком и конечным объектом много всего — помоему даже радиоканал и SDH имеется — к тому же именно тогда на узле, в который включался конечный объект, оператор делал довольно значительные изменения.

Вообщем начал я выносить мозг тех.поддержке. Перепробовали все — увеличивали MTU, расширяли шейпер, вообще его отключали, меняли приоритет трафика на максимальный, пускали по другим трассам. Но ситуация практически не менялась: непрерывный ping с размером пакета 1000 байт стабильно выдавал около 8% потерь, время отклика было стабильным. Причем процент потерь мало зависил от загрузки канала — ошибки шли даже при нулевой загрузке. От загрузки канала немного увеличивалось время отклика, а потери зависели только от размера пакета - до 500 байт потери были незначительны (менее процента), 800-1200 байт потери были в пределах 10%, а при размере пакета выше 1400 потери приближались к 15-20%.

В конечном итоге решили проверить наш стык. Сама линия (уличная витая пара, примерно 40 метров) была в порядке, а вот на узле оператора я обнаружил то самое, что показано на фотографии. Если плохо видно, то расшифрую — порядок жил: БО, О, С, БЗ, БС, З, БК, К. На второй стороне (у меня) обжато правильно.

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

А что может быть проще-то? Duplex mismatch на эзернет интерфейсе.

Из-за криво обжатых проводов, или по другим причинам, автоопределение отработало неверно. С одной стороны стал duplex full, с другой - half.

Если бы с двух сторон сделали бы half - возможно работало бы стабильно и с кривыми проводами.

Posted

У меня такое ощущение, что бело-зелёный с синим в один "контакт" попали. Фото с обратной стороны могло бы прояснить этот момент.

Posted (edited)

Фото с обратной стороны могло бы прояснить этот момент.

зачем, если и так понятно что проблема в раскладке.

Вопрос в том, что должно было быть 100% потерь, а не 10.

Edited by Iapetus
Posted

Фото с обратной стороны могло бы прояснить этот момент.

С обратной стороны сделано правильно.

 

why not?

Я подумал, может быть в БЗ наводки от С были, потому и работало как-то.

Posted

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

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