×

Предупреждение

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Cisco 2821 - увеличение "input errors" и "ignored errors" на интерфейсе

Неотвеченый вопрос
июл 11th, 2013
User Badges:

Добрый день.


Понимаю, что по данному вопросу достаточно пишут на форумах, все же решил спросить.

Значит имеется 2821, через которую порядка 80 VoIP телефонов с "серыми" IP адресами регистрируются по SIP посредством NAT (PAT) оператора VoIP. При увеличении телефонной нагрузки начинают увеличиваться счетчики input errors и ignored errors на обоих интерфейсах. Наблюдается прерывистая речь. Вывод команды show buffers показывает увеличение счетчика failures в Middle buffers:

!

GigabitEthernet0/1 is up, line protocol is up

  Hardware is MV96340 Ethernet, address is 0017.95bc.8999 (bia 0017.95bc.8999)

  Description: Outside

  Internet address is

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, media type is T

  output flow-control is XON, input flow-control is XON

  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 01:01:40

  Input queue: 0/500/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  30 second input rate 353000 bits/sec, 175 packets/sec

  30 second output rate 352000 bits/sec, 151 packets/sec

     219946 packets input, 54046444 bytes, 0 no buffer

     Received 573 broadcasts, 0 runts, 0 giants, 0 throttles

     43 input errors, 0 CRC, 0 frame, 0 overrun, 43 ignored

     0 watchdog, 0 multicast, 0 pause input

     0 input packets with dribble condition detected

     177747 packets output, 54034239 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier, 86 pause output

     0 output buffer failures, 0 output buffers swapped out

!

Middle buffers, 600 bytes (total 251, permanent 210, peak 626 @ 04:00:05):

     248 in free list (180 min, 250 max allowed)

     8299846 hits, 275239 misses, 69992 trims, 70033 created

     39674 failures (0 no memory)

!

interface GigabitEthernet0/1

description Outside

ip address

ip access-group ge0/1-in in

no ip redirects

no ip unreachables

no ip proxy-arp

ip nbar protocol-discovery

ip nat outside

ip virtual-reassembly

ip route-cache flow

load-interval 30

duplex auto

speed auto

no cdp enable

no mop enabled

hold-queue 500 in

!

Роутер был выделен исключительно под голосовой трафик. ACL ge0/1-in запрещает все, кроме voip.

Не хватает производительности чего - CPU, Ethernet controller, Memory Buffers? Может сама схема включения VoIP не корректна и Cisco 2821 сюда не подходит?


Спасибо...

I have this problem too.
0 голоса
Loading.
Sergey Goffert вс, 07/21/2013 - 20:14
User Badges:
  • Silver, 250 points or more
  • Почетные Знаки Сообщества,

    Выбор участников, Ноябрь 2014

Добрый день!

Загрузку CPU имеет смсыл смотреть в момент когда проявляется проблема командами:

sh proc cpu history

sh proc cpu sorted 5sec


Прерывистая речь обычно возникает при потерях\задержках на канале.

Потери на интерфейсах могут быть вызваны тем, что CPU не успевает обрабатывать пакеты.

Но это будет сказываться только в том случае, если все пакеты обрабатываются CPU.

А увас именно так и происходит и причина этому - NAT.

При наличии NAT на роутре автоматически включается NBAR, и все пакеты на интерфейсах начинают обрабатываться процессором, а следовательно вы таким образом ставите свой трафик в зависимость от ресурсов CPU, и если последних не хватает, то будут потери.


NAT у циски достаточно прожорливый, а 2821 железка слабенькая.

Я конечно сомневаюсь, что бы 80 фонов своим трафиком забили ресурсы CPU по NAT, но возможно вы всё же чего-то не договариваете и там может присутствовать и другой трафик, а в таком случае проблемы с CPU выглядят вполне реально.


P.S. Да, а у вас ширины канала-то до провайдера хватает?

А канал между вами и провайдером VOIP случайно не "интернет"?

Может у вас просто полосы не хватает и провайдер режет излишки вашего трафика?

korobkinaa вт, 07/23/2013 - 01:21
User Badges:

Избавиться от ошибок удалось путем установки "speed 10, duplex full" на интерфейсах.


Подскажите, если бы вместо NAT-а использовался GRE-туннель до провайдера, трафик также был зависим от ресурсов CPU?


Спасибо за ответ)

Sergey Goffert вт, 07/23/2013 - 02:23
User Badges:
  • Silver, 250 points or more
  • Почетные Знаки Сообщества,

    Выбор участников, Ноябрь 2014

Спасибо ставят оценкой ответа


Вообще-то говоря GRE-туннель  "is hardware accelerated", но надо рассматривать конкретную ситуацию и конкретную модель оборудования.


На всех ISR на сколько я знаю есть VPN-акселлераторы, проверить просто

sh crypto engine brief

Параметр "type" отображает тип  software\hardware, а параметр "state" - состяние  enabled\disabled.


Но, имхо есть смысл изучать этот вопрос только в том случае, если вы с помощью мониторинга или команд 

sh proc cpu history

sh proc cpu sorted 5sec

выявили наличие факта высокой загрзки CPU.


То что ваша проблема решилась фиксацией скорости и дуплекса намекает на проблемы на уровне физики.


Попробуйте потестировать ваш канал, например так:

ping x.x.x.x source y.y.y.y size 1400 repeat 10000

, где x.x.x.x - адрес ближайшего роутера провайдера, а y.y.y.y - адрес вашего интерфеса, который смотрит в сторону провайдера. Как альтернативный вариант в качестве x.x.x.x указать адрес VoIP-сервера, на котором регестрируются фоны.

И посмотреть есть ли там вообще потери, и будут ли они без фиксации скорости и дуплекса.

до 1% потерь - в пределах допустимого

2% потерь и более - уже крайне нежелательно, более 2% просто недопустимо, тем более для голоса.


Ещё можно воткнуться в этот сегмент любым ПК и выполнить из под cmd  pathping x.x.x.x  - очень хорошо показывает точки отказа в трейсе.


Рекомендации элементарные, но как показывает практика многие даже таких проверок не делают, а зря, в 90% случаев пинг и трассер позволяют выявить проблему с потерями и прохождением трафика.

korobkinaa вт, 07/23/2013 - 02:53
User Badges:

Нагрузка CPU составляла не более 20%, когда начинали увеличиваться ошибки и buffer failures. При этом VoIP трафик составлял 500кб/с.


Router#show crypto engine brief

        crypto engine name:  Virtual Private Network (VPN) Module

        crypto engine type:  hardware

                     State:  Enabled

                  Location:  onboard 0

              Product Name:  Onboard-VPN

        Middleware Version:  v1.2.0

          Firmware Version:  v2.2.0

              Time running:  328430 seconds

               Compression:  Yes

                       DES:  Yes

                     3 DES:  Yes

                   AES CBC:  Yes (128,192,256)

                  AES CNTR:  No

     Maximum buffer length:  4096

          Maximum DH index:  0300

          Maximum SA index:  0300

        Maximum Flow index:  2400

      Maximum RSA key size:  2048


        crypto engine name:  Cisco VPN Software Implementation

        crypto engine type:  software

             serial number:  11E683AF

       crypto engine state:  installed

     crypto engine in slot:  N/A


На счет проверки с помощью пинг буду иметь ввиду...

Sergey Goffert вт, 07/23/2013 - 03:04
User Badges:
  • Silver, 250 points or more
  • Почетные Знаки Сообщества,

    Выбор участников, Ноябрь 2014

Как вы видите


crypto engine name:  Virtual Private Network (VPN) Module

crypto engine type:  hardware

State:  Enabled


Т.е. у вас есть аппартный модуль и он включен, следовательно обработка трафика GRE-туннеля должна быть  аппаратой.  Я говорю "должна быть", а не "будет", потому что там бывают нюансы и всё зависит от конкретной ситуации и конфига. Например, на некоторых платформах два туннеля с одним src_ip не могут обрабатываться аппаратно - только процом, хотя если использовать для каждого GRE-туннеля свой src_ip, то всё идёт аппаратно.

Действия

Информация о дискуссии