Ключевые слова:cisco, trouble, speed, route, (найти похожие документы)
From: Дмитрий Новиков <dmn@nnz.ru>
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. Если статья требует
уточнений/исправлений - напишите по адресу dmn@nnz.ru.
Д.Новиков.
Недавно пришлось столкнуться с непрятной проблемой: наш 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%.
Есть один неприятный момент - при включенном CEF не работает GTS (Generic Traffic Shaping), по крайней мере на нашей Cisco 1711 (IOS 12.2(15)ZL). При включенном NetFlow на интерфейсе (команда ip route-cache flow) все нормально.
таже самая проблема, включил на интерфейсе
ip route-cache policy
ip route-cache cef
Все равно не помогает
и еще кода смотрю show run-ом
ip route-cache cef нет его
у меня нагрузка на процессе IP Input
чаще возникала из за мультикаста..
проверяется просто,если после no ip multicast-routing нагрузка упала, то следует разбираться с мультикастом..
