отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Cisco ISR 4431 аномальная загрузка CPU

Здравствуйте.

Имеется CISCO ISR4431/K9
Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S5,
RELEASE SOFTWARE (fc2)
System image file is "bootflash:/isr4400-universalk9.03.16.05.S.155-3.S5-ext.SPA.bin"
Лицензия securityk9


На маршрутизаторе настроен VRF с выходом в сеть Интернет, в VRF настроен Dynamic VTI IPSec.
Между VRF и GRT построен GRE туннель через который они обмениваются трафиком, а так же
информацией о маршрутах по протоколу EIGRP.
Схема прохождения трафика следующая:
IPSec клиент(из Интернет) <--->(IPSec сервер (DVTI in VRF) <--->Tunnel(GRE) <--->GRT<--->LAN)


Проблема заключается в том, что при подключении 3-х и более IPSec DVTI туннелей и при
суммарной нагрузке от них 15-20 Mbit/s загрузка процессора подымается до 50%. При
увеличении трафика загрузка процессора увеличивается.

Ниже привожу результаты вывода команд загрузки процессора:
sh processes cpu sorted | ex 0.00%
CPU utilization for five seconds: 46%/26%; one minute: 42%; five minutes: 41%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
195 37342454 493858493 75 16.00% 14.59% 13.89% 0 IP Input
117 22585467 548936068 41 7.91% 7.61% 7.54% 0 IOSXE-RP Punt Se
15 6888912 86066689 80 0.63% 0.93% 0.97% 0 ARP Input
544 402709 5267063 76 0.23% 0.09% 0.08% 0 EIGRP-IPv4 Hello
344 1650687 62994501 26 0.23% 0.18% 0.17% 0 HSRP Common
249 1788865 100430778 17 0.15% 0.18% 0.17% 0 Inline Power
191 577743 31557978 18 0.15% 0.06% 0.07% 0 IPAM Manager
182 545034 15818680 34 0.07% 0.04% 0.06% 0 VRRS Main thread
194 536391 31557569 16 0.07% 0.07% 0.07% 0 IP ARP Retry Age
79 449333 3712379 121 0.07% 0.04% 0.05% 0 IOSD ipc task


sh processes cpu plat sorted | ex _0%_
CPU utilization for five seconds: 15%, one minute: 11%, five minutes: 11%
Core 0: CPU utilization for five seconds: 18%, one minute: 21%, five minutes: 22%
Core 1: CPU utilization for five seconds: 4%, one minute: 8%, five minutes: 7%
Core 2: CPU utilization for five seconds: 15%, one minute: 12%, five minutes: 8%
Core 3: CPU utilization for five seconds: 16%, one minute: 8%, five minutes: 10%
Core 4: CPU utilization for five seconds: 5%, one minute: 12%, five minutes: 12%
Core 6: CPU utilization for five seconds: 1%, one minute: 8%, five minutes: 7%
Core 7: CPU utilization for five seconds: 13%, one minute: 8%, five minutes: 10%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
26649 25641 49% 50% 53% S 2502656000 linux_iosd-imag
3898 3114 11% 11% 11% R 4294967295 fman_fp_image
26357 25445 5% 5% 5% R 42741760 hman
10862 2 2% 2% 2% S 0 lsmpi-xmit
10 2 2% 2% 2% S 0 sirq-tasklet/0
23703 22803 1% 1% 1% S 380276736 bsm
10863 2 1% 1% 1% S 0 lsmpi-rx

Во вложении картинки с системы мониторинга и часть файла конфигурации

16 ОТВЕТ.
New Member

Добрый день,

Добрый день,

покажите пожалуйста вывод команды

show ip cef

Есть подозрение, что это вызвано применением NBAR

если есть возможность, удалите команду "ip nbar protocol-discovery" с интерфейса Gi0/0/0 и замерьте загрузку.

New Member

удалил команду ip nbar

удалил команду ip nbar protocol-discovery, ничего не поменялось. Так же пробовал полностью отключать Netflow.

во вложении вывод sh ip cef для GRT и для VRF

New Member

Значит NBAR ни при чём.

Значит NBAR ни при чём.

Всё же проблема заключается в том, что много пакетов не попадает в аппаратную обработку и идёт через CPU. Попробуйте помониторить, что за пакеты попадают туда. Сделайте следующее:

monitor capture buffer BUFF-PROCESS size 10240 max-size 1500
monitor capture point ip process-switched POINT-PROCESS in                                           monitor capture point associate POINT-PROCESS BUFF-PROCESS                                         monitor capture point start POINT-PROCESS

Думаю 10 мегабайтный буфер заполнится быстро. Проверьте заполнение командой 

show monitor capture buffer BUFF-PROCESS parameters

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

monitor capture point stop POINT-PROCESS                                                                         monitor capture buffer BUFF-PROCESS export disk0:/capture1.pcap

Далее копируете файл capture1.pcap на свою машину и открываете Wireshark'ом.

Если что подозрительное или интересное - выкладывайте сюда :)

New Member

К сожалению в моем IOS не

К сожалению в моем IOS не нашлось команды monitor capture point, но я сделал monitor capture CAP control-plane both (есть варианты снимать еще дамп с интерфейсов) и то что я увидел в дампе меня смутило. Буду рад помощи, что бы разобрать этот дамп.

P.S.

добавил расширение txt так как данная форма не поддерживает файлы *.pcap

New Member

Так... Пока я пытаюсь

Так... Пока я пытаюсь проанализировать дамп, попробуйте ещё снизить МТУ на interface virtual-template2 и снизить ip tcp adjust-mss.

 

New Member

И ещё одно. Попробуйте

И ещё одно. Попробуйте удалить "ip route-cache policy" под "interface virtual-template2". Может быть это принудительно включает fast-switching вместо CEF.

New Member

ip route-cache policy - это я

ip route-cache policy - это я уже экспериментировал, что с ним что без него одинаково

Вот вид интерфейса Virtual-Template2 сейчас:
interface Virtual-Template2 type tunnel
description VPN_FG1
ip vrf forwarding FG1
ip unnumbered Loopback1
ip mtu 1400
ip tcp adjust-mss 1360
ip policy route-map DefGW_FG
tunnel mode ipsec ipv4
tunnel vrf FG1
tunnel protection ipsec profile FG1_pr
end

Но загрузка ЦП такая же.

Что примечательно при выводе sh interfaces virtual-access 1 MTU 1438
#sh interfaces virtual-access 1
Virtual-Access1 is up, line protocol is up
Hardware is Virtual Access interface
Description: VPN_FG1
Interface is unnumbered. Using address of Loopback1 (195.XX.132.XXX)
MTU 9938 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 224/255, rxload 255/255
Encapsulation TUNNEL
Tunnel vaccess, cloned from Virtual-Template2
Vaccess status 0x4, loopback not set
Keepalive not set
Tunnel linestate evaluation up
Tunnel source 195.XXX.132.XXX, destination 178.XXX.163.XXX
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1438 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "FG1_pr")
Last input never, output never, output hang never
Last clearing of "show interface" counters 00:13:22
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 2973000 bits/sec, 401 packets/sec
5 minute output rate 88000 bits/sec, 207 packets/sec
315052 packets input, 292187038 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
161525 packets output, 8323780 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

при выводе sh ip interface virtual-access 1 есть такая строчка IP route-cache flags are Fast, CEF, вроде бы CEF на интерфейсе включен.

sh ip interface virtual-access 1
Virtual-Access1 is up, line protocol is up
Interface is unnumbered. Using address of Loopback1 (195.XXX.132.XXX)
Broadcast address is 255.255.255.255
MTU is 1400 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
VPN Routing/Forwarding "FG1"
Associated unicast routing topologies:
Topology "base", operation state is UP
Tunnel VPN Routing/Forwarding "FG1"
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is enabled, using route map DefGW_FG
Network address translation is disabled
BGP Policy Mapping is disabled
Input features: Policy Routing, MCI Check, TCP Adjust MSS
Output features: TCP Adjust MSS
Post encapsulation features: IPSEC Post-encap output classification
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled

New Member

Только сейчас заметил! А для

Только сейчас заметил! А для чего Вам роут-мап на интерфейсе? Это гарантированный punt в CPU. Вы используете другой default next-hop. Для чего это? Думаю, что если уберёте, то полегчает.

New Member

Я тоже так подумал сначала, и

Я тоже так подумал сначала, и роут-мап отключал, и вот только что, для верности, попробовал еще раз, но ничего не меняется.
Этот роут-мап нужен для того, что бы пользователи VPN сетей имели контролируемый доступ в интернет которым управляет отдельное устройство и оно находится в GRT, которая находится за default next-hop указанным в роут-мапе. Но трафик в интернет там ничтожно мал и на сколько я понимаю, если в роут-мапе указана команда set ip default next-hop, то сначала происходит поиск в таблице маршрутизации, а если там совпадений не найдено, то происходит маршрутизация по PBR согласно роут-мапу.

Основной трафик от VPN сетей - это видео трафик по протоколу RTSP и он, как видно из дампа, по какой-то причине весь проходит через Control-plane.

Сейчас еще попробую отключить EIGRP и прописать маршруты статически, уже даже не знаю, что еще придумать(

Вот пока писал ответ, нарисовались картинки в мониторинге - это без роут-мапа...

New Member

ОК, попробуем зайти с другого

ОК, попробуем зайти с другого конца :) Что за зверь 10.1.18.44? Похоже, что основной трафик который вызывает нагрузку идёт оттуда.

New Member

Путем проб и ошибок я только

Путем проб и ошибок я только что выяснил где собака зарыта :)

Для обмена трафиком между VRF и GRT я использую GRE туннель настроенный по следующей схеме (это схему я позаимствовал где-то на просторах интернета. Народ писал, что все работает и никто не жаловался)
Собственно схема из конфига:

Делаем 2 лупбэка в GRT


interface Loopback2000
description Tun2000_src
ip address 20.70.50.7 255.255.255.255
!
interface Loopback2001
description Tun_2001_src
ip address 20.70.50.8 255.255.255.255

и от них строим туннели из GRT и из VRF

interface Tunnel2000
 description Tunn_to_vrf_FG1
 bandwidth 100000
 ip address 20.70.51.13 255.255.255.252
 ip mtu 1400
 ip route-cache policy
 ip tcp adjust-mss 1360
 tunnel source Loopback2000
 tunnel destination 20.70.50.8
!
interface Tunnel2001
 description Tunn_from_vrf_KS1
 bandwidth 100000
 ip vrf forwarding FG1
 ip address 20.70.51.14 255.255.255.252
 ip mtu 1400
 ip route-cache policy
 ip tcp adjust-mss 1360
 tunnel source Loopback2001
 tunnel destination 20.70.50.7

Трафик ходит, все ОК, но как оказалось не корректно :(

Сейчас я сделал следующее, создал на свиче, к которому подключена циска, отдельный VLAN и пробросил туда порт из GRT и порт из VRF и пустил трафик туда. Сейчас трафик 20 Mbit/s, а загрузка CPU <10%. (картинки в аттаче)

Теперь вопрос в другом, как можно изящно организовать динамическую перетечку маршрутов между GRT и VRF не используя физ интрефейсы свича? Так как ручками прописывать route leak маршруты в более чем 30 сетей не охота, а решение со свичем не совсем красивое :)

New Member

Честно говоря я вообще ничего

Честно говоря я вообще ничего не понял. Можете выложить диаграмму сети и для чего вообще используете VRF/PBR?

New Member

В аттаче упрощенная схема

В аттаче упрощенная схема сети, именно той части которую я реализовал.

Нужно принимать ВПНы от мини офисов на отдельный интернет канал, для этого был организован VRF, так как при подключении еще одного интернет канала, появляется еще 1 шлюз по умолчанию. Получается, что на VRF будут концентрироваться сети от ВПНов и им нужен доступ в сеть GRT, а так же доступ в интернет, который необходимо контролировать, а значит он должен попадать на фаервол, который находится в GRT. Но если не делать роут-мап, то весь интернет трафик будет уходить на интерфейс провайдера который принимает ВПНы, а там кроме ВПНов ничего ходить не должно.
И это все уже работает, просто мне нужно красиво сделать обмен трафиком между VRF и GRT, что бы в дальнейшем это было удобно обслуживать и делать поменьше ручной работы.

New Member

Если я Вас правильно понял,

Если я Вас правильно понял, то сделать это проще простого:

Не нужен лупбэк интерфейс.

1. Создаёте VRF.

2. Заводите туда физический интерфейс.

3. Создаёте маршрут по умолчанию в VRF.

4. Создаёте туннельный интерфейс.

5. Указываете, что канальный интерфейс для туннеля находится в VRF. Это команда "tunnel vrf VRF-NAME".

6. Самое главное - сам туннельный интерфейс в VRF не заводите.

Всё. Получается туннель, который принадлежит дефолтной таблице маршрутов при этом используя для инкапсуляции физический интерфейс, который не принадлежит ей. Поскольку в VRF свой шлюз по умолчанию, никаких других изменений не требуется. Всё очень аккуратно. Если будут вопросы - пишите, постараюсь ответить. Рекомендую протестировать решение в GNS3.

New Member

Решил задачу немного по

Решил задачу немного по другому.

Дабы не плодить лишние интерфейсы поднял на маршрутизаторе BGP для GRT и для VRF и настроил импорт-экспорт маршрутов между таблицами. Сейчас все работает отлично.

Сергей спасибо за помощь!)


New Member

Всегда пожалуйста :)

Всегда пожалуйста :)

126
Просмотры
0
Полезный материал
16
Ответы
СоздатьДля создания публикации, пожалуйста в систему