Автор | Сообщение |
---|---|
Заголовок сообщения: DES-1210-28/ME и Excessive Deferral Добавлено: Вт янв 31, 2017 19:30 |
|
|
Добрый день! Мы предоставляем услуги интернет со скоростью до 100 мбит/с и IPTV. Уровень доступа и агрегации построен на коммутаторах d-link 1210-28, 3200-28 и 3526. Кольцевая топология. Port Number : 6 При этом абоненты жалуются на низкую скорость по вечерам. Прошивка: Пробовали также на место 1210 ставить 3200 — с ними всё хорошо. |
Вернуться наверх |
|
Ivan Kostyrya |
Заголовок сообщения: Re: DES-1210-28/ME и Excessive Deferral Добавлено: Пт мар 17, 2017 09:00 |
|
dolgincevo писал(а): Добрый день! Пробовали также на место 1210 ставить 3200 — с ними всё хорошо. Добрый день! Попробуйте для начала обновить ПО, причем, (насколько я правильно понял, то у Вас модель DES-1210-28|ME B2) через промежуточную версию. Инструкция и ссылки доступны тут: viewtopic.php?f=2&t=92700 |
Вернуться наверх |
|
michailbugati |
Заголовок сообщения: Re: DES-1210-28/ME и Excessive Deferral Добавлено: Пн мар 20, 2017 00:19 |
|
System Firmware Version : 6.10.B020 куда уж новее а Excessive Deferral все равно растут!!! _________________ |
Вернуться наверх |
|
Ivan Kostyrya |
Заголовок сообщения: Re: DES-1210-28/ME и Excessive Deferral Добавлено: Пн мар 20, 2017 05:39 |
|
michailbugati писал(а): System Firmware Version : 6.10.B020 куда уж новее а Excessive Deferral все равно растут!!! Добрый день! Сама по себе ошибка Excessive Deferral — это счётчик количества пакетов, первая попытка отправки которых была отложена по причине Ранее, говорили, что на 3200-м коммутаторе нет такой проблемы, так что было бы не плохо сравнить 2 конфига с коммутаторов и прибавить схему сети. |
Вернуться наверх |
|
RDC |
Заголовок сообщения: Re: DES-1210-28/ME и Excessive Deferral Добавлено: Пн мар 20, 2017 18:53 |
|
а попробуйте включить flow control между 1210-28 и его аплинком |
Вернуться наверх |
|
olnet |
Заголовок сообщения: Re: DES-1210-28/ME и Excessive Deferral Добавлено: Ср дек 27, 2017 14:44 |
|
Подыму тему….аналогичная проблема… Клиенты жалуются на низкую скорость по вечерам. Ревизия и ПО: |
Вернуться наверх |
|
Помогите, пожалуйста, разобраться со следующей проблемой.
При подключении lan-кабеля в роутер (интернет > роутер > компьютер по кабелю), периодически пропадает интернет, на стороне провайдера видны ошибки и т.д., на какое-то время помогает перезагрузка роутера.
Казалось бы, очевидно проблема в роутере, но.
Проблема началась с роутера TP-LINK TL-WR841N, отдал его другу, и взял Cisco LinkSys EA3500 (работающий на другом провайдере у друга без проблем вообще), и опять та же проблема. Но только LinkSys не требовалось перезагружать, достаточно передёрнуть кабель (его видят ноут, телефоны и т.д., а интернета нет, т.е. роутер вроде как не зависает).
Ок, взял у соседа другой TP-LINK, ему отдал свой Cisco. У соседа целый день всё ок, у меня те же проблемы.
Подключаю lan-кабель напрямую в компьютер — ни ошибок, ни проблем.
Провайдер соответственно не может выяснить в чём проблема, т.к. напрямую всё ок.
Не знаю связанно ли это или нет, но проблемы начались после полной смены сетапа (был интел, стал амд). Может ли компьютер (его сетевая карта) как-то влиять на роутер?
Даже не знаю за что зацепиться, куда смотреть. Сейчас основной роутер это Cisco LinkSys EA3500. Есть какие-то мысли на этот счёт?
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
У друга и соседа один и тот же провайдер, не такой как у меня.
Отправлено спустя 1 минуту 52 секунды:
Во время пропадания интернета (не зависания роутера/ов) по вайфаю интернет тоже пропадает, хотя все устройства видят роутер/ы.
Отправлено спустя 29 секунд:
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
Уверен, у него проц не более 600-800Мгц, и скорее 1 ядро всего, если запросы летят напрямую к цпу ( широковещалки броадкаста или еще какая дрянь ) то в лучшем случае он будет заметно плохо жевать трафик, в худшем повесится, и скорее повесится еще и от перегрева.
Увы я уважаю только среднецоновой и выше сегмент микротик, циско, джунипер или полноценный боард сервер на линукс etc., с нормальными сетевыми.
Линксис — огрызок циски, не более.
Отправлено спустя 1 минуту 15 секунд:
А по arp -a выдаёт 11 адресов.
тут бы глянуть что от них летит еще
Отправлено спустя 3 минуты 16 секунд:
Попросите КЦ провайдера соединить с тех.отделом.
Тех.отдел попросите переселить вас в другой сегмент сети, зачастую в другой VID, сообщите то что описали тут.
Как подтвердят что сделали — пробейте снова arp -a, гляньте правда ли, или врут.
Если выполнили требования — наблюдайте за инетом.
Самый простой способ проверить что не так, если поддержка у провайдера адекватна.
Отправлено спустя 7 минут 18 секунд:
Ах да, еще момент, вы уверены что вешается роутер не от вашего ПК?
Банальная проверка на вирусню с помощью cureit!, и сброс сетевого стека, в командной строке:
netsh winsock reset
netsh int ip reset
Думаю не повредят, только после команд настроек на сетевой не будет, так что если у вас статический IP их следует записать.
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
- Профиль
- Цитата
papamama: Помогите, пожалуйста, разобраться со следующей проблемой.
При подключении lan-кабеля в роутер (интернет > роутер > компьютер по кабелю), периодически пропадает интернет, на стороне провайдера видны ошибки и т.д., на какое-то время помогает перезагрузка роутера.
Какие ошибки?
Для понимания:
CRC Error 7 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 0 Late Collision 0
Fragment 1 Excessive Collision 0
Jabber 0 Single Collision 0
Symbol Error 4 Collision 0
Buffer Full Drop 101629 STP Drop 18065
ACL Drop 0 HOL Drop 0
Multicast Drop 0
VLAN Ingress Drop 22332842
Invalid IPv6 0
STP Drop 6595
Storm and FDB Discard 0
MTU Drop 0
Вот их сколько разных, и это только малая капля на недосвитче Dlink, стянул с первого попавшегося под руку коммутатора статистику рандомного порта.
Самые распространенные:
CRC — ошибки контрольной суммы, пакеты бьются не долетая к вас/ от вас
Fragment — то же самое, но когда идет дробление больших пакетов на более мелкие, мало вероятно
Collision — столкновение пакетов из-за несогласованности меж отправитиелем и получателем
acl drop — отброс пакета согласно установленных «правил» свитча, это настройка провайдера
STP drop — дропы лишних stp пакетов, когда STP выключен, или пакеты STP не распознаны
Storm and FDB Discard — дропы согласно встроенных механизмов защиты коммутатора от шторма и петли
MTU drop — дропы из-за несогласованности MTU
Так вот, если прут CRC, Fragment, Collision, просим провайдера проверить длину и целостность кабеля, при наличии норм коммутаторов они это могут, и просим назвать сколько.
Если кабеля больше 70м, не исключено что просто не пробивает, или плохой кабель, просим заменить
Типы ошибок (dlink)
Undersize — возникают при получение фрейма размером 61-64 байта.
Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
Какие пакеты входят в Drop Packets при выводе show error ports?
Переполнение входного буфера на порту
Пакеты, отброшенные ACL
Проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается
Why do UDP packets get dropped?
The first time I heard this joke I did not understand it because I didn’t really understand what UDP was. UDP is a network protocol. The deal is: I send you a network packet. Maybe you get it, maybe you don’t. I have no idea whether it arrived or not. UDP doesn’t care.
When you’re losing UDP packets, it’s sort of tempting to say “well, whatever, that’s what happens when you use UDP!” But UDP packets don’t get lost by magic.
I was pretty confused about some the details of dropping UDP packets (how do you know how many packets got dropped? what causes a packet to be dropped exactly?) Maggie Zhou (who is the best) explained some new things to me today! All the parts of this that are right are thanks to her and all the parts that are wrong are thanks to me.
This is all on Linux, as usual. There are going to be sysctls! It will be the best.
lost on the way out
Imagine you’re sending a lot of UDP packets. Really a lot. On every UDP socket, there’s a “socket send buffer” that you put packets into. The Linux kernel deals with those packets and sends them out as quickly as possible. So if you have a network card that’s too slow or something, it’s possible that it will not be able to send the packets as fast as you put them in! So you will drop packets.
I have no idea how common this is.
lost in transit
It’s possible that you send a UDP packet in the internet, and it gets lost along the way for some reason. I am not an expert on what happens on the seas of the internet, and I am not going to go into this.
lost on the way in
Okay, so a UDP packet comes into your computer. You have an application that is listening and waiting for a packet. Awesome! This packet goes into – maybe you guessed it – a socket receive buffer. How big is that buffer? Everything you might want to know about socket send and receive buffer sizes is helpfully explained in the man page for socket . Here’s the maximum receive buffer size on my computer:
man udp says that that last number from net.ipv4.udp_mem (362220) means “Number of pages allowed for queueing by all UDP sockets.” 362220 pages is 1.7GB? That’s a lot of pages! Weird. Not sure what’s up with that.
Then your application reads packets out of that buffer and handles them. If the buffer gets full, the packets get dropped. Simple!
You can see how many packets have been dropped on your machine with netstat -suna . Mine has dropped 918 packets so far apparently (“918 packet receive errors”)
This is cool! This means that if you have a machine which is trying to drop as few UDP packets as possible (for instance if you’re running statsd), then you can monitor the rate at which that machine is dropping packets!
buffers everywhere
After I published this blog post initially, @gphat and @nelhage very astutely pointed out that the OS socket send/receive buffers are not the only buffers.
EVERYTHING IS BUFFERS. Your network card has a buffer that can get full! There are a bunch of intermediate routers between your computer and my computer. All of those have buffers! Those buffers can get full! My current understanding is that most packet loss is because of full buffers one way or another.
If you’re interested in learning more details about the Linux networking stack, there is this huge post called Monitoring and Tuning the Linux Networking Stack: Receiving Data. I have not read it yet but it looks amazing.
Also everything here I said about UDP packets applies just as well to any kind of IP packet – TCP packets can get dropped just as easily, but they’ll get retried, so you’re not as likely to notice.
Здравствуйте.
Имею дивную проблему (вернее она меня) с ошибками на порту коммутатора.
Схема простенькая:
Коммутатор Dlink 3200-10 включен в беспроводной мост RedLine AN80(порт1), к Dlink 3200-10 (порт 2-4) подключены сегменты сети.
Были замечены значительные ошибки на порту1 (Длинк).Имея опыт с RedLine AN80, было включено на обоих сторонах 100FD. После этого канал был нагружен трафиком, протестирован — вроде все ок.
По ходу рабочего дня контрольные провеки (1-2 раза в час) показали отсуствие ошибок. Думал проблема решена.
Но это показалось — на следующий день по приходу утром на работу, проверка коммутатора показала, что на порту1 в счетчиках ошибок Excessive Deferral появились приличные цифры. Но! В даный момент на порту ошибки не появлялись.
В логе делинка было замечено следущее:
фрагмент лога
….
687 2011-08-08, 00:00:32 Port 1 link down
1686 2011-08-08, 00:00:25 Port 1 link up, 100Mbps FULL duplex
1685 2011-08-08, 00:00:24 Port 1 link up, 100Mbps FULL duplex
1684 2011-08-08, 23:59:04 Port 1 link up, 100Mbps FULL duplex
1683 2011-08-08, 23:59:03 Port 1 link up, 100Mbps FULL duplex
1682 2011-08-08, 23:57:17 Port 1 link up, 100Mbps FULL duplex
1681 2011-08-08, 23:57:16 Port 1 link up, 100Mbps FULL duplex
1680 2011-08-08, 23:44:52 Port 1 link up, 100Mbps FULL duplex
1679 2011-08-08, 23:44:50 Port 1 link down
1678 2011-08-08, 23:39:34 Port 1 link up, 100Mbps FULL duplex
1677 2011-08-08, 23:39:33 Port 1 link up, 100Mbps FULL duplex
1676 2011-08-08, 23:33:15 Port 1 link up, 100Mbps FULL duplex
1675 2011-08-08, 23:33:14 Port 1 link up, 100Mbps FULL duplex
1674 2011-08-08, 23:28:38 Port 1 link up, 100Mbps FULL duplex
И такое с 22-00 по 03-00.
Было сделано предположение, что проблема между редлайном и делинком (порт редлайна, порт делинка, кабель, RJ-45 и т.п.). Тоесть при увеличении трафика порты-кабеля начинают глючить. Все бы хорошо, но — эта ситуация повторяется каждый день (вечер) с 22-00 до 03-00 (+-10-15 минут).
Утром, днем все пучком, даже при наличии днем двухкратного вечернего трафика.
Только наступает около 22-00 ситуация повторяется.
Причем ошибки только на порту порт1.
Есть идея, что проблема с питанием, при наступлении 22-00 (+-) — фактически это наступление полной темноты народ активно юзает сеть-220В и наше оборудование начинает «играть». Хотя если ошибки только на порту порт1 , то подозрение падает на блок питания Редлайна. Но при этом пинг на Редлайл со сторони аплинк не пропадает.
Кто что посоветует?
Как с этим бороться ?
RX (recive) — принимать пакеты приходящие от клиента
TX (transmit) передавать— пакеты приходящие к клиенту
Типы ошибок:
CRC Error — ошибки проверки контрольной суммы
Undersize — возникают при получение фрейма размером 61-64 байта.
Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
Какие пакеты входят в Drop Packets при выводе show error ports?
Переполнение входного буфера на порту
Пакеты, отброшенные ACL
Проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается
Single Collision — единичная коллизия
CRC Error — ошибки проверки контрольной суммы
Undersize — возникают при получение фрейма размером 61-64 байта. Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
переполнение входного буфера на порту
пакеты, отброшенные ACL
проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончились неудачей. данный пакет больше не передается
Single Collision — единичная коллизия