У меня плохо себя ведет Cisco 2811. Он обслуживает наш офис из 20 человек с Интернетом и телефонами через Call Manager Express. За исключением того, что в последнее время телефоны не работают должным образом, а интернет нестабилен. Внешний интерфейс, подключенный к нашему интернет-провайдеру, в порядке. Внутренний интерфейс подключен к 2960, к которому подключена наша внутренняя сеть. В интерфейсе шоу есть очевидные проблемы:
FastEthernet0/1 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 001b.d40a.e071 (bia 001b.d40a.e071)
Internet address is 192.168.1.254/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 13/255, rxload 19/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive not set
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:54:10
Input queue: 1/150/420/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7463000 bits/sec, 1038 packets/sec
5 minute output rate 5244000 bits/sec, 880 packets/sec
3021883 packets input, 2691686783 bytes
Received 7649 broadcasts, 0 runts, 0 giants, 95 throttles
2155 input errors, 0 CRC, 0 frame, 0 overrun, 2155 ignored
0 watchdog
0 input packets with dribble condition detected
2537251 packets output, 1717084791 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
464 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Я заменил кабель на новый, безрезультатно. Я установил switchport nonegotiate на 2960, к которому он подключен. Я убедился, что настройки одинаковы для обоих интерфейсов (100M, Авто / Авто). Я убедился, что CDP включен, а пакеты поддержки отключены.
Сегодня я удален, но завтра я собираюсь установить порт SPAN на 2960, чтобы попытаться получить больше информации. Могу ли я еще что-нибудь сделать, чтобы выяснить, откуда берутся эти проблемы?
Я сделал интерфейс для Mac-Accounting, и компьютер одного человека отправляет около 80% всего трафика на маршрутизатор ... 2800 МБ из 3100 МБ. Моя ассистентка проверила свой компьютер и не обнаружила ничего необычного.
РЕДАКТИРОВАТЬ:
По запросу вот sh int от порта коммутатора:
GigabitEthernet1/0/48 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is b414.89ba.32b0 (bia b414.89ba.32b0)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 22/255, rxload 4/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 20147
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1883000 bits/sec, 693 packets/sec
5 minute output rate 8721000 bits/sec, 1020 packets/sec
64561402 packets input, 46701593519 bytes, 0 no buffer
Received 109892 broadcasts (102372 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 102372 multicast, 0 pause input
0 input packets with dribble condition detected
66138056 packets output, 36914890016 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Попробуйте отключить DTP на интерфейсе коммутатора. switchport nonegotiate Поскольку маршрутизатор не является коммутатором, он не распознает протокол динамического транкинга.
Итак, отойдя от предыстории устранения неполадок, я бы посмотрел на это с другой стороны.
Все прерывисто / медленно, верно? Интернет и телефоны. И вы показали нам статистику интерфейса. Я смотрю на это здесь:
->3021883 packets input, 2691686783 bytes
->Received 7649 broadcasts, 0 runts, 0 giants, 95 throttles
->2155 input errors, 0 CRC, 0 frame, 0 overrun, 2155 ignored
->464 unknown protocol drops
Во-первых, давайте устраним простую - потери протокола и ошибки ввода. 464 отбрасывания составляют 0,01% из этих 3 021 883 входных пакетов, опять же, с ошибками ввода аналогичная история. Такие вещи случаются время от времени, это вас беспокоит, но я готов поспорить, что вы сказали бы, что это хуже, чем на 0,01% медленнее, верно?
Так или иначе, дросселирование может пролить свет на проблемы, дросселирование происходит при перегрузке устройства. Так что это может быть чем-то, на что стоит обратить внимание.
Медлительность - это боль в заднице, которую нужно диагностировать, хотя я бы действительно попытался привязать ее к временному периоду, возможно, остаться допоздна на одну ночь, когда большинство людей ушло, и посмотреть, все ли идет медленно? В 90% случаев я обнаружил, что вся медленность связана с производительностью.
Итак, несколько вещей, которые нужно проверить.
Я лично подозреваю, что где-то есть узкое место в процессоре / памяти, это не будет отображаться в обычных командах интерфейса. Из вставленной вами команды show я не вижу никаких «реальных» проблем, ничего, что могло бы вызвать заметные проблемы.
Также перезагрузите его. Никогда не знаешь :)
Artanix предложил несколько отличных советов по устранению неполадок, которые являются отличным способом начать работу с маршрутизатором.
Я также воспользовался некоторыми советами по устранению неполадок Вот потому что загрузка ЦП на маршрутизаторе обычно составляет 99–100%.
Настройка учета MAC-адресов через NetFlow (как описано Вот) привел меня к одному устройству, которое генерировало 80% трафика, поступающего через интерфейс Fa0 / 1. Проследив это до одного компьютера, мой стажер не нашел ничего, в чем он мог бы обвинить, но я проверил ее исходящие сообщения в MS Outlook ... она отправила электронное письмо с вложениями более 50 МБ (наш предел исходящего размера - 40 МБ) коллеге в нашем офисе в другом городе.
Согласно моему сеансу SPAN, почтовый сервер послушно получит все эти данные, затем сообщит Outlook, что размер превышен, и разорвет соединение. Outlook, зная, что он еще не отправил сообщение, продолжал попытки отправить его снова, причем очень агрессивно. Я не знаю, почему сообщения об ошибках не возвращались, но подозреваю, что это как-то связано с тем, что Outlook предполагает, что пропускная способность почтового сервера является дешевой.
После того, как мы удалили это почтовое сообщение из почтового ящика и прочитали небольшую лекцию об использовании файлового сервера для передачи больших файлов, а не электронной почты, загрузка ЦП вернулась к нормальному диапазону 40-60%, а телефоны и сеть вернулись в нормальное состояние. и дросселирование интерфейса вернулось к нулю.
Итак, это устранило проблему и сделало вопрос относительно спорным. Я до сих пор не знаю, какие были неизвестные протоколы, но уверен, что в моем сеансе SPAN они есть в списке.