The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Один из методов устранения перегруженности Cisco (cisco trouble speed route)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: cisco, trouble, speed, route,  (найти похожие документы)
From: Дмитрий Новиков <[email protected]> Newsgroups: http://www.artmagic.ru/labs/ Date: Mon, 4 Dec 2002 13:01:37 +0000 (UTC) Subject: Один из методов устранения перегруженности Cisco Один из методов устранения перегруженности Cisco ROUTER. http://www.artmagic.ru/labs/short/short-rec5.shtml Это описание - решение одной частной проблемы с CISCO сугубо эксперементальным способом. Методы примененные здесь не являются универсальными и могут не подходить к другим случаям. Однако, может быть этот рецепт поможет при решении довольно распространенной проблемы "перегруженности" CISCO. Если статья требует уточнений/исправлений - напишите по адресу [email protected]. Д.Новиков. Недавно пришлось столкнуться с непрятной проблемой: наш Cisco 2611 стал интенсивно "тормозить" при большом потоке данных через нее. Через маршрутизатор получают доступ к интернет примерно 300 рабочих станций, а сам маршрутизатор подключен к 2-м синхронным каналам. На CISCO стоит NAT, Policy ROUTING. И вот в самых пиковых часах CISCO начинает "тормозить" - это сразу видно по отклику на Ethernet интерфейсе (вплоть до 1000ms). Более научный подход: посмотреть назагрузку процессора. sh proc cpu CISCO выдаст таблицу загруженности процессора: CPU utilization for five seconds: 71%/65%; one minute: 81%; five minutes: 76% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 6854 89676 76 0.00% 0.00% 0.00% 0 Load Meter 2 200 158 1265 0.08% 0.16% 0.03% 66 Virtual Exec 3 313946 54404 5770 0.00% 0.04% 0.04% 0 Check heaps 4 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager 5 963 434 2218 0.00% 0.00% 0.00% 0 Pool Manager 6 0 2 0 0.00% 0.00% 0.00% 0 Timers 7 136 242 561 0.00% 0.00% 0.00% 0 Serial Backgroun 8 806 14949 53 0.00% 0.00% 0.00% 0 Environmental mo 9 916 7856 116 0.00% 0.00% 0.00% 0 ARP Input 10 0 3 0 0.00% 0.00% 0.00% 0 DDR Timers 11 0 2 0 0.00% 0.00% 0.00% 0 Dialer event 12 12 2 6000 0.00% 0.00% 0.00% 0 Entity MIB API 13 0 1 0 0.00% 0.00% 0.00% 0 SERIAL A'detect 14 0 1 0 0.00% 0.00% 0.00% 0 Critical Bkgnd 15 33793 82553 409 0.00% 0.00% 0.00% 0 Net Background 16 4 45 88 0.00% 0.00% 0.00% 0 Logger 17 28851 446609 64 0.00% 0.00% 0.00% 0 TTY Background 18 73494 446618 164 0.00% 0.00% 0.00% 0 Per-Second Jobs 19 4 2 2000 0.00% 0.00% 0.00% 0 Hawkeye Backgrou 20 26839 133673 200 0.00% 0.00% 0.00% 0 Net Input 21 12582 89676 140 0.00% 0.00% 0.00% 0 Compute load avg ... 23 78581793 37913291 2072 54.74% 63.83% 54.51% 0 IP Input ... Листинг показывает общую загрузку процессора (за последнюю процессора процессами. Как показали неоднократные измерения, процессорное время кушает один процесс - "IP Input" (в листинге выделено жирным). Если процессор "тормозят" другие процессы - Вы столкнулись с другой проблемой. Как выяснилось после изучения вопроса - это достаточно распространенная проблема. Происходит это потому что при примнении policy routing (политика роутинга, позволяющая разруливать трафик по разным интерфейсам) используется process switching. В это режима для каждой входящей дейтограммы требуется запуск центрального процессора. Соотвественно при интенсивном трафике этот процесс занимает все процессорное время. Как выяснилось, бороться с этим эффектом можно. Для этого, нужно включить кеширование обработки дейтаграмм. Такой режим называется fast-switching. В таком режиме работы маршрутизатор запоминает маршрут в кеше и на следующий пакет в маршруте время уже не затрачивается. Включается fast switching командой на интерфейсе, где включен policy routing: nnz-cisco#conf t nnz-cisco(config)#in e0/0 nnz-cisco(config-if)# ip route-cache В нашем IOS команда "ip route cache" требует дополнительный параметр из списка: cef Enable Cisco Express Forwarding flow Enable Flow fast-switching cache policy Enable fast-switching policy cache for outgoing packets same-interface Enable fast-switching on the same interface Это разные алгоритмы кеширования. Для верности нужно попробовать включить их все один за одним. Для того, чтобы включился cef (Cisco Express Forwardingнужно включить cef в режиме config: ip cef. ip route-cache cef ip route-cache flow ip route-cache policy ip route-cache same-interfaces Полезно сделать тоже самое на выходящих интерфейсах (у нас это s0/0 & s0/3). Посмотреть сработал ли кеш для системыы можно по загруженности процессора. У нас загрузка упала до 10-20 процентов и выше не поднималась. А ping до e0/0 больше не увеличивался. Посмотреть таблицу кешированных маршрутов можно посмотреть с помошью команд: sh ip cache IP routing cache 866 entries, 140344 bytes 415526 adds, 414660 invalidates, 0 refcounts Minimum invalidation interval 2 seconds, maximum interval 5 seconds, quiet interval 3 seconds, threshold 0 requests Invalidation rate 0 in last second, 0 in last 3 seconds Last full cache invalidation occurred 6d16h ago Prefix/Length Age Interface Next Hop 10.7.1.24/32 02:04:24 Ethernet0/0 10.58.0.2 10.7.1.41/32 00:20:15 Ethernet0/0 10.58.0.2 10.7.1.50/32 00:15:56 Ethernet0/0 10.58.0.2 10.7.3.74/32 00:21:07 Ethernet0/0 10.58.0.2 10.8.1.3/32 00:18:31 Ethernet0/0 10.58.0.2 10.12.0.3/32 00:15:05 Ethernet0/0 10.58.0.2 10.12.1.2/32 00:13:16 Ethernet0/0 10.58.0.2 10.12.1.10/32 00:07:53 Ethernet0/0 10.58.0.2 10.15.0.1/32 00:02:11 Ethernet0/0 10.58.0.2 10.15.0.2/32 00:31:56 Ethernet0/0 10.58.0.2 10.15.0.4/32 00:01:48 Ethernet0/0 10.58.0.2 10.15.0.5/32 00:34:43 Ethernet0/0 10.58.0.2 10.15.0.6/32 00:10:06 Ethernet0/0 10.58.0.2 10.15.0.10/32 00:34:45 Ethernet0/0 10.58.0.2 10.15.0.12/32 00:07:00 Ethernet0/0 10.58.0.2 ..... Судя по количеству кеширующих записей, на практике, действительно "ускоряет" процесс раскладывания ip cache. Всего наблюдалось около 1000 кешированных сетей. Команда sh ip cef показала не очень много записей (порядка 20). После включения кеширования, загрузка процессора падает: CPU utilization for five seconds: 18%/12%; one minute: 18%; five minutes: 20% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 8459 115534 73 0.00% 0.00% 0.00% 0 Load Meter 2 7922 2506 3161 0.16% 0.08% 0.33% 66 Virtual Exec 3 397597 69995 5680 0.49% 0.08% 0.06% 0 Check heaps 23 89200253 41662481 2141 10.64% 7.40% 6.65% 0 IP Input Вобщем то, несколько дней замеров показали, что нагрузкане поднимается выше 50%.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, realghost (ok), 17:57, 01/04/2005 [ответить]  
  • +/
    Есть один неприятный момент - при включенном CEF не работает GTS (Generic Traffic Shaping), по крайней мере на нашей Cisco 1711 (IOS 12.2(15)ZL). При включенном NetFlow на интерфейсе (команда ip route-cache flow) все нормально.
     
  • 2, DarK (ok), 11:27, 23/05/2012 [ответить]  
  • +/
    таже самая проблема, включил на интерфейсе
    ip route-cache policy
    ip route-cache cef
    Все равно не помогает
    и еще кода смотрю show run-ом
    ip route-cache cef нет его
     
  • 3, volxv (ok), 13:44, 13/06/2012 [ответить]  
  • +/
    ip route-cache
    в моем случае что-то не помогло.
     
  • 4, felix (??), 14:05, 02/12/2015 [ответить]  
  • +/
    у меня нагрузка на процессе IP Input
    чаще возникала из за мультикаста..
    проверяется просто,если после no ip multicast-routing нагрузка упала, то следует разбираться с мультикастом..
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру