Алексей Андриянов Опубликовано 11 марта, 2009 · Жалоба Есть 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) Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных. Как победить эту проблему, не объединяя эти маршрутизаторы и не втыкая их последовательно, придумать не могу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 11 марта, 2009 (изменено) · Жалоба какой sdm prefer? в дефолте нету PBR, поэтому оно в софтваре. sh sdm prefer Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных.Как победить эту проблему, не объединяя эти маршрутизаторы и не втыкая их последовательно, придумать не могу. ну допустим сделать отдельный vrf с этими клиентами и "их маршрутизатором" а если нужна связность внутренняя, то между "их маршрутизатором" и обычным шлюзом поднять линк и маршрутизацию. Изменено 11 марта, 2009 пользователем ingress Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 11 марта, 2009 (изменено) · Жалоба 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 маршрутизаторов в одном, чем гонять трафик туда-сюда. Изменено 11 марта, 2009 пользователем Алексей Андриянов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cmhungry Опубликовано 11 марта, 2009 · Жалоба Интерфейс, на который приходят пакеты, и на котором идет перенаправление, один и тот же? т.е. пакет в SVI вошел и в нем же перенаправлен? ip route-cache same-interface может помочь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 11 марта, 2009 · Жалоба Интерфейс, на который приходят пакеты, и на котором идет перенаправление, один и тот же? т.е. пакет в SVI вошел и в нем же перенаправлен?ip route-cache same-interface может помочь Нет, пакеты уходят на другой SVI, не на тот, с которого пришли. И вообще всякие эксперименты с ip route-cache не помогают, там он и так включен по умолчанию, как я понял. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chocholl Опубликовано 12 марта, 2009 · Жалоба а попробуйте поставить на 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) Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных. Как победить эту проблему, не объединяя эти маршрутизаторы и не втыкая их последовательно, придумать не могу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 12 марта, 2009 · Жалоба а попробуйте поставить на sviip 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 включен на этой платформе по умолчанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chocholl Опубликовано 12 марта, 2009 · Жалоба show ip interface vlan x покажет, что включено по-дефолту. set ip default next-hop действительно обрабатывается софтварно. поэтому обратите еще раз внимание на vrf с route leaking. а попробуйте поставить на sviip 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 включен на этой платформе по умолчанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 апреля, 2009 · Жалоба Удалось ли решить проблему? кто что думает по поводу http://www.certification.ru/cgi-bin/forum....ad&id=28972 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
packetizer Опубликовано 27 апреля, 2009 (изменено) · Жалоба интересует данный вопрос, похожая ситуация "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 нет , немогу проверить Изменено 28 апреля, 2009 пользователем packetizer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 29 апреля, 2009 · Жалоба packetizer Страшно пробовать, как железка освободиться - отпишу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...