URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID6
Нить номер: 11476
[ Назад ]
Исходное сообщение
"Большие пинги на Catalyst"
Отправлено Jelis , 08-Сен-06 19:43 
Добрый день!

  В сети стоит несколько Catalyst 2950. При побольшом траффике они нчинают очень "медленно" отвечать - пинги подскакивают до 500-1000ms, ну и телнет тоже тормозит ощутимо. Нагрузки на цпу практически нету

baobab#sh proc cpu
CPU utilization for five seconds: 7%/3%; one minute: 6%; five minutes: 6%

  Пакеты проходящие через свич идут нормально, без задержек. Свичи стоят в довольно больших сегментах (500-1000 одновременно работяющих пользователей) и что настораживает, большое количество пакетов в trottles на vlan 1 :

baobab#sh int vlan1
Vlan1 is up, line protocol is up
  Hardware is CPU Interface, address is 0015.f94e.d180 (bia 0015.f94e.d180)
  Internet address is 213.xxx.xxx.5/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters 00:01:50
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 94000 bits/sec, 153 packets/sec
  5 minute output rate 4000 bits/sec, 7 packets/sec
     17280 packets input, 1300749 bytes, 0 no buffer
     Received 16919 broadcasts (0 IP multicast)
     0 runts, 0 giants, 1080 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 10968 ignored
     694 packets output, 76049 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out


1080 trottles за менее чем две минуты! Как с этим боротся? Пакетов то вроде не так и много, <200 в секунду!

Содержание
Сообщения в этом обсуждении
"Большие пинги на Catalyst"
Отправлено Nailer , 09-Сен-06 12:47 
>Добрый день!
>
>  В сети стоит несколько Catalyst 2950. При побольшом траффике они
>нчинают очень "медленно" отвечать - пинги подскакивают до 500-1000ms, ну и
>телнет тоже тормозит ощутимо. Нагрузки на цпу практически нету
>
>baobab#sh proc cpu
>CPU utilization for five seconds: 7%/3%; one minute: 6%; five minutes: 6%
>
>
>  Пакеты проходящие через свич идут нормально, без задержек. Свичи стоят
>в довольно больших сегментах (500-1000 одновременно работяющих пользователей) и что настораживает,
>большое количество пакетов в trottles на vlan 1 :
>
>baobab#sh int vlan1
>Vlan1 is up, line protocol is up
>  Hardware is CPU Interface, address is 0015.f94e.d180 (bia 0015.f94e.d180)
>  Internet address is 213.xxx.xxx.5/24
>  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>     reliability 255/255, txload 1/255, rxload 1/255
>  Encapsulation ARPA, loopback not set
>  ARP type: ARPA, ARP Timeout 04:00:00
>  Last input 00:00:00, output never, output hang never
>  Last clearing of "show interface" counters 00:01:50
>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>  Queueing strategy: fifo
>  Output queue: 0/40 (size/max)
>  5 minute input rate 94000 bits/sec, 153 packets/sec
>  5 minute output rate 4000 bits/sec, 7 packets/sec
>     17280 packets input, 1300749 bytes, 0 no
>buffer
>     Received 16919 broadcasts (0 IP multicast)
>     0 runts, 0 giants, 1080 throttles
>     0 input errors, 0 CRC, 0 frame,
>0 overrun, 10968 ignored
>     694 packets output, 76049 bytes, 0 underruns
>
>     0 output errors, 0 interface resets
>     0 output buffer failures, 0 output buffers
>swapped out
>
>
>1080 trottles за менее чем две минуты! Как с этим боротся? Пакетов
>то вроде не так и много, <200 в секунду!

Не использовать для управления тот же vlan, что и для пользователей.

"Большие пинги на Catalyst"
Отправлено Jelis , 09-Сен-06 13:58 
>>Добрый день!
>>
>>  В сети стоит несколько Catalyst 2950. При побольшом траффике они
>>нчинают очень "медленно" отвечать - пинги подскакивают до 500-1000ms, ну и
>>телнет тоже тормозит ощутимо. Нагрузки на цпу практически нету
>>
>>baobab#sh proc cpu
>>CPU utilization for five seconds: 7%/3%; one minute: 6%; five minutes: 6%
>>
>>
>>  Пакеты проходящие через свич идут нормально, без задержек. Свичи стоят
>>в довольно больших сегментах (500-1000 одновременно работяющих пользователей) и что настораживает,
>>большое количество пакетов в trottles на vlan 1 :
>>
>>baobab#sh int vlan1
>>Vlan1 is up, line protocol is up
>>  Hardware is CPU Interface, address is 0015.f94e.d180 (bia 0015.f94e.d180)
>>  Internet address is 213.xxx.xxx.5/24
>>  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>>     reliability 255/255, txload 1/255, rxload 1/255
>>  Encapsulation ARPA, loopback not set
>>  ARP type: ARPA, ARP Timeout 04:00:00
>>  Last input 00:00:00, output never, output hang never
>>  Last clearing of "show interface" counters 00:01:50
>>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>>  Queueing strategy: fifo
>>  Output queue: 0/40 (size/max)
>>  5 minute input rate 94000 bits/sec, 153 packets/sec
>>  5 minute output rate 4000 bits/sec, 7 packets/sec
>>     17280 packets input, 1300749 bytes, 0 no
>>buffer
>>     Received 16919 broadcasts (0 IP multicast)
>>     0 runts, 0 giants, 1080 throttles
>>     0 input errors, 0 CRC, 0 frame,
>>0 overrun, 10968 ignored
>>     694 packets output, 76049 bytes, 0 underruns
>>
>>     0 output errors, 0 interface resets
>>     0 output buffer failures, 0 output buffers
>>swapped out
>>
>>
>>1080 trottles за менее чем две минуты! Как с этим боротся? Пакетов
>>то вроде не так и много, <200 в секунду!
>
>Не использовать для управления тот же vlan, что и для пользователей.

  Да, о таком я тоже думал. Но это просто не получиться - до свича стоят тупые свичи с клиентами, и создать транк просто не получиться :-(
  А из-за чего такие задержки-то получаються?

"Большие пинги на Catalyst"
Отправлено Nailer , 09-Сен-06 16:59 
>>>Добрый день!
>>>
>>>  В сети стоит несколько Catalyst 2950. При побольшом траффике они
>>>нчинают очень "медленно" отвечать - пинги подскакивают до 500-1000ms, ну и
>>>телнет тоже тормозит ощутимо. Нагрузки на цпу практически нету
>>>
>>>baobab#sh proc cpu
>>>CPU utilization for five seconds: 7%/3%; one minute: 6%; five minutes: 6%
>>>
>>>
>>>  Пакеты проходящие через свич идут нормально, без задержек. Свичи стоят
>>>в довольно больших сегментах (500-1000 одновременно работяющих пользователей) и что настораживает,
>>>большое количество пакетов в trottles на vlan 1 :
>>>
>>>baobab#sh int vlan1
>>>Vlan1 is up, line protocol is up
>>>  Hardware is CPU Interface, address is 0015.f94e.d180 (bia 0015.f94e.d180)
>>>  Internet address is 213.xxx.xxx.5/24
>>>  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>>>     reliability 255/255, txload 1/255, rxload 1/255
>>>  Encapsulation ARPA, loopback not set
>>>  ARP type: ARPA, ARP Timeout 04:00:00
>>>  Last input 00:00:00, output never, output hang never
>>>  Last clearing of "show interface" counters 00:01:50
>>>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>>>  Queueing strategy: fifo
>>>  Output queue: 0/40 (size/max)
>>>  5 minute input rate 94000 bits/sec, 153 packets/sec
>>>  5 minute output rate 4000 bits/sec, 7 packets/sec
>>>     17280 packets input, 1300749 bytes, 0 no
>>>buffer
>>>     Received 16919 broadcasts (0 IP multicast)
>>>     0 runts, 0 giants, 1080 throttles
>>>     0 input errors, 0 CRC, 0 frame,
>>>0 overrun, 10968 ignored
>>>     694 packets output, 76049 bytes, 0 underruns
>>>
>>>     0 output errors, 0 interface resets
>>>     0 output buffer failures, 0 output buffers
>>>swapped out
>>>
>>>
>>>1080 trottles за менее чем две минуты! Как с этим боротся? Пакетов
>>>то вроде не так и много, <200 в секунду!
>>
>>Не использовать для управления тот же vlan, что и для пользователей.
>
>  Да, о таком я тоже думал. Но это просто не
>получиться - до свича стоят тупые свичи с клиентами, и создать
>транк просто не получиться :-(
>  А из-за чего такие задержки-то получаються?

control-plane свитча слабый, а ему падает куча пакетов, которые он должен обрабатывать, те же arp, например.

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

Конфиг покажите, чтоли..

"Большие пинги на Catalyst"
Отправлено Jelis , 09-Сен-06 23:48 
>
>control-plane свитча слабый, а ему падает куча пакетов, которые он должен обрабатывать,
>те же arp, например.
>
>Правда, странно, что загрузка при этом небольшая.
>
>Конфиг покажите, чтоли..

конфиг пожалуста :


Building configuration...

Current configuration : 5400 bytes
!
! Last configuration change at 21:03:44 EEST Wed Sep 6 2006
! NVRAM config last updated at 19:10:11 EEST Wed Sep 6 2006 by xxxxx
!
version 12.1
no service pad
service timestamps debug datetime
service timestamps log datetime localtime
service password-encryption
!
hostname baobab
!
logging buffered 500000 debugging
enable password 7 0000000000000000000
!
username xxxxxx privilege 15 password 7 00000000000000000
clock timezone EET 2
clock summer-time EEST recurring last Sun Mar 2:00 last Sun Oct 2:00
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause psecure-violation
errdisable recovery cause gbic-invalid
errdisable recovery interval 120
ip subnet-zero
no ip rcmd domain-lookup
ip rcmd rsh-enable
ip rcmd remote-host rswich 213.xxx.xxx.14 netadmin
!
ip domain-name baobab.xxxxx.xx
ip name-server 213.xxx.xxx.162
ip name-server 213.xxx.xxx.167
!
spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
!
!
!
interface FastEthernet0/1
description R
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/2
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/3
description P
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/4
description M
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/5
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/6
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/7
description M
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/8
description M
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/9
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/10
description M
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/11
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/12
description P
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/13
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/14
description P
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/15
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/16
description A
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/17
description M
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/18
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/19
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/20
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/21
description M
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/22
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/23
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface FastEthernet0/24
switchport mode access
storm-control broadcast level 2.00 1.00
no cdp enable
!
interface GigabitEthernet0/1
description SNIFFER
!
interface GigabitEthernet0/2
description K
storm-control broadcast level 2.00 1.00
!
interface Vlan1
ip address 213.xxx.xxx.5 255.255.255.0
ip access-group 105 in
no ip route-cache
!
ip default-gateway 213.xxx.xxx.1
no ip http server
logging history debugging
logging trap debugging
logging facility local5
logging 213.xxx.xxx.14
access-list 3 permit 213.xxx.xxx.161
access-list 3 permit 213.xxx.xxx.1
access-list 3 permit 213.xxx.xxx.14
access-list 3 deny   any log
access-list 105 permit icmp any any
access-list 105 permit ip host 213.xxx.xxx.1 any
access-list 105 permit ip host 213.xxx.xxx.14 any
access-list 105 permit ip host 213.xxx.xxx.161 any
access-list 105 permit udp host 213.xxx.xxx.162 eq domain any
access-list 105 permit udp host 213.xxx.xxx.167 eq domain any
access-list 105 deny   udp any any range netbios-ns netbios-ss
access-list 105 deny   udp any any eq bootps
access-list 105 deny   ip any any log-input
no cdp run
arp 213.xxx.xxx.1 0030.4875.16be ARPA
arp 213.xxx.xxx.14 4c00.1060.798a ARPA
!
line con 0
line vty 0 4
access-class 3 in
exec-timeout 30 0
password 7 000000000000000000
login local
line vty 5 15
no login
!
ntp clock-period 17179615
ntp server 213.xxx.xxx.161
!
!
monitor session 1 source interface Fa0/1 - 24
monitor session 1 destination interface Gi0/1
end


ну и sh ver думаю не помешает

baobab#sh ver
Cisco Internetwork Operating System Software
IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA4a, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Fri 16-Sep-05 10:46 by yenanh
Image text-base: 0x80010000, data-base: 0x80562000

ROM: Bootstrap program is C2950 boot loader

baobab uptime is 3 weeks, 2 days, 4 hours, 41 minutes
System returned to ROM by power-on
System restarted at 18:03:34 EEST Thu Aug 17 2006
System image file is "flash:/c2950-i6q4l2-mz.121-22.EA4a.bin"

cisco WS-C2950T-24 (RC32300) processor (revision R0) with 21039K bytes of memory.
Processor board ID FCZ0944X0JM
Last reset from system-reset
Running Enhanced Image
24 FastEthernet/IEEE 802.3 interface(s)
2 Gigabit Ethernet/IEEE 802.3 interface(s)

32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: 00:15:F9:4E:D1:80
Motherboard assembly number: 73-6114-10
Power supply part number: 34-0965-01
Motherboard serial number: FOC09412WPB
Power supply serial number: PHI092304PD
Model revision number: R0
Motherboard revision number: A0
Model number: WS-C2950T-24
System serial number: FCZ0944X0JM
Configuration register is 0xF

"Большие пинги на Catalyst"
Отправлено Jelis , 09-Сен-06 23:58 
>>
>>control-plane свитча слабый, а ему падает куча пакетов, которые он должен обрабатывать,
>>те же arp, например.
>>
>>Правда, странно, что загрузка при этом небольшая.
>>
>>Конфиг покажите, чтоли..
>

  А можно вообще arp отключить? пару мак адресов с которых должен быть доступ можно статически прописать (они у меня и так прописанны), а остальные чтоб игнорировать? пробовал no arp arpa на vlan'e но что-то арп таблица так и продолжала пополняться.
И не могут ли случаем тормоза быть связанны с тем что в acl'e  дропнутые пакеты логируються, причем и на удаленный сервер? Хотя их тоже не так то и много, даж можно сказать мало ...

"Большие пинги на Catalyst"
Отправлено Nailer , 10-Сен-06 11:09 
>>>
>>>control-plane свитча слабый, а ему падает куча пакетов, которые он должен обрабатывать,
>>>те же arp, например.
>>>
>>>Правда, странно, что загрузка при этом небольшая.
>>>
>>>Конфиг покажите, чтоли..
>>
>
>  А можно вообще arp отключить? пару мак адресов с которых
>должен быть доступ можно статически прописать (они у меня и так
>прописанны), а остальные чтоб игнорировать? пробовал no arp arpa на vlan'e
>но что-то арп таблица так и продолжала пополняться.
> И не могут ли случаем тормоза быть связанны с тем что
>в acl'e  дропнутые пакеты логируються, причем и на удаленный сервер?
>Хотя их тоже не так то и много, даж можно сказать
>мало ...

Может, в хардвере свитч делать опицю log не умеет, и начинает обрабатывать весь ACL программно..