Jump to content

80% загрузка CPU на C3560G

Алексей Андриянов
 Share

Recommended Posts

Алексей Андриянов

Алексей Андриянов

Posted
Posted

Есть Cisco Catalyst 3560G, у которой частенько полностью загружен CPU:

 

core#sh proc cpu sorted
CPU utilization for five seconds: 85%/74%; one minute: 84%; five minutes: 83%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
226      471399    396572       1188  2.39%  0.19%  0.04%   0 SNMP ENGINE
   4     1774737    152678      11624  1.11%  0.16%  0.12%   0 Check heaps
214      162886    776437        209  0.79%  0.06%  0.01%   0 IP SNMP
218       76479    388234        196  0.47%  0.03%  0.00%   0 PDU DISPATCHER
157     1859354   9144594        203  0.31%  0.11%  0.11%   0 IP Input
115      938939    236540       3969  0.15%  0.10%  0.10%   0 HQM Stack Proces
   7     1272636   2456675        518  0.15%  0.09%  0.07%   0 ARP Input
160     3715873  31734198        117  0.15%  0.22%  0.22%   0 Spanning Tree
230         101        44       2295  0.15%  0.09%  0.02%   2 Virtual Exec
   9           0         2          0  0.00%  0.00%  0.00%   0 AAA high-capacit
  10           0         1          0  0.00%  0.00%  0.00%   0 Policy Manager

 

Трафик через нее ходит смешной:

 

  5 minute input rate 16081000 bits/sec, 4009 packets/sec
  5 minute output rate 71942000 bits/sec, 7110 packets/sec

 

Подозреваю, что все из-за вот этого route-map, прицепленного к паре SVI, так как на нем и на его ACL быстро растут счетчики пакетов, а значит все обрабатывается на CPU:

core#sh route-map rFromHome
route-map rFromHome, permit, sequence 20
  Match clauses:
    ip address (access-lists): rACL_from10_fastroute
  Set clauses:
  Policy routing matches: 2472767969 packets, 865799606 bytes
route-map rFromHome, permit, sequence 30
  Match clauses:
  Set clauses:
    ip next-hop 10.0.100.10
  Policy routing matches: 2483 packets, 2493699 bytes

core#sh access-l rACL_from10_fastroute
Extended IP access list rACL_from10_fastroute
    10 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 (2398023137 matches)
    20 permit ip 10.0.0.0 0.255.255.255 xx.xxx.xxx.0 0.0.0.255 (5882107 matches)
    30 permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.0.255 (55673890 matches)
    40 permit ip 192.168.0.0 0.0.255.255 any (13739593 matches)

 

Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных.

 

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

ingress

ingress

Posted
Posted (edited)

какой sdm prefer? в дефолте нету PBR, поэтому оно в софтваре.

 

sh sdm prefer

 

Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных.

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

ну допустим сделать отдельный vrf с этими клиентами и "их маршрутизатором"

а если нужна связность внутренняя, то между "их маршрутизатором" и обычным шлюзом поднять линк и маршрутизацию.

Edited by ingress
Алексей Андриянов

Алексей Андриянов

Posted
  • Author
Posted (edited) 

core#sh sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  3K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    11K
    number of directly-connected IPv4 hosts:        3K
    number of indirect IPv4 routes:                 8K
  number of IPv4 policy based routing aces:         512
  number of IPv4/MAC qos aces:                      512
  number of IPv4/MAC security aces:                 1K

core#sh platform tcam utilization

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

Unicast mac addresses:                        400/3200         67/482
IPv4 IGMP groups + multicast routes:          144/1152         33/213
IPv4 unicast directly-connected routes:       400/3200         67/482
IPv4 unicast indirectly-connected routes:    1040/8320         58/372
IPv4 policy based routing aces:               512/512          11/11
IPv4 qos aces:                                512/512           8/8
IPv4 security aces:                          1024/1024        447/447

 

ну допустим сделать отдельный vrf с этими клиентами и "их маршрутизатором"

а если нужна связность внутренняя, то между "их маршрутизатором" и обычным шлюзом поднять линк и маршрутизацию.

Связность внутренняя конечно нужна. То есть, пакеты в сети, присутсвующие в routing table, отправляются минуя этот маршрутизатор, а на него отправляется только интернет-трафик. Локального трафика может быть много.

А насчет второго предложения - поправьте меня, если не так понял, но суть именно в последовательном соединении маршрутизаторов, т.е. с основного роутера пакеты пойдут уже на "их роутер"? Такой вариант тоже не самый желанный, поэтому я его заранее в первом посте исключил.

 

Если с циской "договориться" не удастся, то мне лучше будет объединить функции этих 2 маршрутизаторов в одном, чем гонять трафик туда-сюда.

Edited by Алексей Андриянов
cmhungry

cmhungry

Posted
Posted

Интерфейс, на который приходят пакеты, и на котором идет перенаправление, один и тот же? т.е. пакет в SVI вошел и в нем же перенаправлен?

ip route-cache same-interface может помочь

Алексей Андриянов

Алексей Андриянов

Posted
  • Author
Posted
Интерфейс, на который приходят пакеты, и на котором идет перенаправление, один и тот же? т.е. пакет в SVI вошел и в нем же перенаправлен?

ip route-cache same-interface может помочь

Нет, пакеты уходят на другой SVI, не на тот, с которого пришли. И вообще всякие эксперименты с ip route-cache не помогают, там он и так включен по умолчанию, как я понял.
chocholl

chocholl

Posted
Posted

 

а попробуйте поставить на svi

ip route-cache policy

 

Есть Cisco Catalyst 3560G, у которой частенько полностью загружен CPU:

 

core#sh proc cpu sorted
CPU utilization for five seconds: 85%/74%; one minute: 84%; five minutes: 83%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
226      471399    396572       1188  2.39%  0.19%  0.04%   0 SNMP ENGINE
   4     1774737    152678      11624  1.11%  0.16%  0.12%   0 Check heaps
214      162886    776437        209  0.79%  0.06%  0.01%   0 IP SNMP
218       76479    388234        196  0.47%  0.03%  0.00%   0 PDU DISPATCHER
157     1859354   9144594        203  0.31%  0.11%  0.11%   0 IP Input
115      938939    236540       3969  0.15%  0.10%  0.10%   0 HQM Stack Proces
   7     1272636   2456675        518  0.15%  0.09%  0.07%   0 ARP Input
160     3715873  31734198        117  0.15%  0.22%  0.22%   0 Spanning Tree
230         101        44       2295  0.15%  0.09%  0.02%   2 Virtual Exec
   9           0         2          0  0.00%  0.00%  0.00%   0 AAA high-capacit
  10           0         1          0  0.00%  0.00%  0.00%   0 Policy Manager

 

Трафик через нее ходит смешной:

 

  5 minute input rate 16081000 bits/sec, 4009 packets/sec
  5 minute output rate 71942000 bits/sec, 7110 packets/sec

 

Подозреваю, что все из-за вот этого route-map, прицепленного к паре SVI, так как на нем и на его ACL быстро растут счетчики пакетов, а значит все обрабатывается на CPU:

core#sh route-map rFromHome
route-map rFromHome, permit, sequence 20
  Match clauses:
    ip address (access-lists): rACL_from10_fastroute
  Set clauses:
  Policy routing matches: 2472767969 packets, 865799606 bytes
route-map rFromHome, permit, sequence 30
  Match clauses:
  Set clauses:
    ip next-hop 10.0.100.10
  Policy routing matches: 2483 packets, 2493699 bytes

core#sh access-l rACL_from10_fastroute
Extended IP access list rACL_from10_fastroute
    10 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 (2398023137 matches)
    20 permit ip 10.0.0.0 0.255.255.255 xx.xxx.xxx.0 0.0.0.255 (5882107 matches)
    30 permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.0.255 (55673890 matches)
    40 permit ip 192.168.0.0 0.0.255.255 any (13739593 matches)

 

Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных.

 

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

Алексей Андриянов

Алексей Андриянов

Posted
  • Author
Posted
а попробуйте поставить на svi

ip route-cache policy

Я пробовал вчера вечером. Не помогает.

потом убрал это через no ip route-cache, оно так и осталось в конфиге "no ip route-cache policy"

И циска после этого реально стала все пакеты на том интерфейсе обрабатывать программно, CPU usage стал 99%, Ip input отжирал около 70%, и пропускная способность катастрофически снизилась.

Я сделал "default ip route-cache policy", но это ничего не изменило, как раньше не стало.

 

Пришлось перезагружать. После перезагрузки на том же конфиге стало как было.

 

Я так понял, что всякого рода route-cache включен на этой платформе по умолчанию.

chocholl

chocholl

Posted
Posted

show ip interface vlan x

покажет, что включено по-дефолту.

set ip default next-hop действительно обрабатывается софтварно.

поэтому обратите еще раз внимание на vrf с route leaking.

 

 

а попробуйте поставить на svi

ip route-cache policy

Я пробовал вчера вечером. Не помогает.

потом убрал это через no ip route-cache, оно так и осталось в конфиге "no ip route-cache policy"

И циска после этого реально стала все пакеты на том интерфейсе обрабатывать программно, CPU usage стал 99%, Ip input отжирал около 70%, и пропускная способность катастрофически снизилась.

Я сделал "default ip route-cache policy", но это ничего не изменило, как раньше не стало.

 

Пришлось перезагружать. После перезагрузки на том же конфиге стало как было.

 

Я так понял, что всякого рода route-cache включен на этой платформе по умолчанию.

  • 1 month later...
packetizer

packetizer

Posted
Posted (edited)

интересует данный вопрос, похожая ситуация "route-map" без "set" или прийдется перечислять все дестинейшины в интернете

 

ни одно ни другое неподходят

 

как насчет тог чтобы "route-map" который без "set" заменить на конструкцию вида

 

route-map pbr permit 10

match ip address 100

set ip next-hop Loopback0

....

access-list 100 permit свои локальные сетки

 

Вроде и ACL с пермитом и set есть , должно работать на асике

 

 

PS

Пока под рукой 3550 нет , немогу проверить

Edited by packetizer

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.

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