[noobie]

Добрый день.

 

Есть Cisco 6505 SUP720-3b (Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXH, RELEASE SOFTWARE (fc5)).

 

На vlan, который смотрит в сторону бордера навешивается ACL, которые заполняется по rsh с биллинга:

 

!
interface Vlan800
description BORDER
ip address xx.xx.xx.106 255.255.255.252
ip access-group 198 out
no ip proxy-arp
end
!
access-list 198 dynamic BADBOYS deny   ip any any
access-list 198 permit ip any any
!
#sh access-lists 198
30 Dynamic BADBOYS deny   ip any any
   30   deny ip host хх.хх.хх.105 any
......

 

Все бы ничего, но когда настает новый месяц - доступ блокируется. Юзеров, которым запрещен доступ становится сильно много + начинаются ежесекундные проплаты и процесc FM-Core выжирает весь CPU.

В эти моменты снимаем ACL и ждем пока их становится меньше 1000.

 

Ведь не должна же умирать от такого количества. Пробовал и через vlanACL - тоже самое.

 

Я предполагаю, что это из-за логики самих ACL. Так ли это?

Стоит вешать на клиентские vlan листы вида : "разрешить конкретным юзерам", а остальное блокируем ? Если так, то хотелось бы узнать: у меня используется ip unnumbered, можно ли вешать на loopback интерфейс, а не на каждый vlan, будут ли в этом случае проблемы с производительностью?

 

И ещё вопрос: кто как устроил взаимодействие между биллингом и циской ? По rsh медленно и можно заполнять только dynamic ACL.

 

Большое спасибо!

Изменено 14 декабря, 2011 пользователем noobie

[passer]

В логах что?

 

Ознакомьтесь: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

 

 

[noobie]

В логах что?

 

Ознакомьтесь: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

 

В логах ничего. В данном документе не нашел того, чего нужно. Может не внимательно читал. Процессор грузит именно процесс FM-Core, это происходит только, когда много ACL такого вида, как я привел выше и они часто изменяются. Именно перестройка TCAM, и вызывает загрузку.

Но ведь их очень мало для такого железа, отсюда делаю вывод, что что-то не так с логикой самих ACL.

В этом и прошу помочь.

[SergeiK]

Почему не должна? Железка обрабатывает ACL чипом. Все, что не помещается в ЧИП - уходит на процессор.

Ресурсы чипа ограничены схемотехникой, как раз TCAM и есть.

 

Есть интересная технология блокировки большого количества адресов именно по IP.

Используется URPF и роутинг адресов в null. Можно с ипользованием BGP.

Суть процесса такова. URPF обрабатывается на уровне CEF, то есть тоже ЧИПОМ, но на основе таблиц маршрутизации.

На интерфейсе настроенно, но пускать оттуда только те адреса, которые маршрутизируются в этот самый интерфейс (можно - в любой интефейс, кроме null).

IP или статиком роутите в null или через BGP (в этом случае один адрес роутится в null, а по BGP приходит next-hop этот самый адрес).

Тогда можно, во первых, не перезаливать весь ACL, как в вашем случае; во-вторых, управлять этим процессом на отдельном одном роутере, который связан по BGP с несколькими.

[Zaqwr]

попробуйте заюзать 98 acl может extended больше кушает

[passer]

А посмотреть как используется tcam?

Кстати, применительно к ACL в 6500 это читали: http://www.cisco.com...0800c9470.shtml

Там имеется некоторая информация, относительно использования ACL. Мое мнение относительно вашей проблемы - нехватка tcam и переход на программный свитчинг. А extended acl на некоторых железках использует tcam в 2 раза быстрее. Сейчас 6500 под рукой нет, чтобы проиллюстрировать.

 

 

 

 

 

Изменено 14 декабря, 2011 пользователем passer

[noobie]

CLs Processed in Software in Cisco Catalyst 6500 Series Switches

 

It is important to understand that some ACL and ACL-based feature configurations are not supported in hardware on the PFC/PFC2/PFC3, and will cause some traffic to be redirected to the MSFC for ACL processing in software. The following configurations will result in software processing:

 

•ACL denied traffic

 

–Supervisor 720 with PFC3—ACL denied packets are leaked to the MSFC3 if unreachables are enabled. Packets requiring ICMP unreachables are leaked at a user-configurable rate (500 pps by default)

 

Правильно я понял, что все deny ACL попадают в software ?

Так-же все unreacheble packet, если не включен no ip unreachable. И все ICMP unreachables, которые не отсекаются рейт-лимитами ?

 

Спасет ли меня в таком случае перевод на permit acl, таких будет около 6000 тысяч, и можно ли вешать на loopback при использовании ip unnumbered ?

 

Но опять-же :

Сейчас 614 таких acl.

Процессор не нагружен:

CPU utilization for five seconds: 8%/4%; one minute: 11%; five minutes: 10%

TCAM ресурсов полно:

#sh platform hardware capacity acl
ACL/QoS TCAM Resources
 Key: ACLent - ACL TCAM entries, ACLmsk - ACL TCAM masks, AND - ANDOR,
      QoSent - QoS TCAM entries, QOSmsk - QoS TCAM masks, OR - ORAND,
      Lbl-in - ingress label, Lbl-eg - egress label, LOUsrc - LOU source,
      LOUdst - LOU destination, ADJ - ACL adjacency

 Module ACLent ACLmsk QoSent QoSmsk Lbl-in Lbl-eg LOUsrc LOUdst  AND  OR  ADJ
 5          2%     4%     1%     1%     1%     1%     0%     0%   0%  0%   1%
show tcam counts
          Used        Free        Percent Used       Reserved
          ----        ----        ------------       --------
Labels:(in)  9        4087            0
Labels:(eg)  5        4091            0

ACL_TCAM
--------
 Masks:    164        3932            4                    72
Entries:    717       32051            2                   576

QOS_TCAM
--------
 Masks:     25        4071            0                    18
Entries:     33       32735            0                   144

   LOU:      0         128            0
 ANDOR:      0          16            0
 ORAND:      0          16            0
   ADJ:      3        2045            0

Даже когда их будет 3000 он будет далек от заполнения.

 

This FM core process is responsible from translating the access-list/PBR and move this into a format that can be used to program this into the TCAM for traffic-processing.

 

Отсюда делаю вывод, что дело не в software свитчинге/форвадинге. А именно в перестройке TCAM этим FM.

Есть люди, которые контролируют доступ на 6500? Хотелось бы услышать как у них реализовано.

 

2 SergeiK:

 

Можно пример, или ссылку где почитать о реализации такого метода контроля доступа?

Изменено 14 декабря, 2011 пользователем noobie

[Tosha]

У нас 76 циска на 720 - в принципе то же железо.

При изменении ACL тормозит - при каждой команде железо переконфигурирует...

 

Ускорение при массовых операциях можно только двумя путями

1) ACL отписывается от порта, меняется, потом приписывается

2) Ведутся два ACL. Сначала меняется второй, потом он назначается на интерфейс, потом меняется первый, и если у Вас сложности с выяснением какой из них активный первый снова вешается на интерфейс.

 

Неактивный ACL (не назначенный ни на один порт) не ест tcam и меняется относительно мгновенно (ну то есть тоже немного тормозит но по сравнению - летает).

 

В обоих случаях тормоза при любом объеме катострофически меньше.

 

А да, биллинг надо отучать от дергания циски напрямую и писать прослойку (скрипт), который вбивает запомненную очередь команд за последнюю минуту. Время накопления подбирать по вкусу. Менее 10 секунд думаю не стоит.

 

P.S.

У нас некоторый подвид первого варианта.

 

P.S. 2

Если кто знает как еще можно ускорить - скажите пожалуйста

Изменено 15 декабря, 2011 пользователем Tosha

[denis_vid]

P.S. 2

Если кто знает как еще можно ускорить - скажите пожалуйста

acl на доступ по феншую

[SergeiK]

2 SergeiK:

 

Можно пример, или ссылку где почитать о реализации такого метода контроля доступа?

Дык, я же уже все написал. URPF в поиск, почитать, что это такое и потом уже думать, как применить. В гугле первые три строки объясняют, что это такое и как с этим бороться.

Я не буду специально приводить пример, так как фича довольно тонкая и перед применением требует понимания, что и как.

[Tosha]

Ну да, это вариант. У нас сейчас и на доступе и на 76 ACL.

Тут все зависит от того на чем доступ и что он может. Иногда хочется хитрого, чтобы интернета не было, но кое-чего было :)

[martini]

а не проще PBR заюзать ?? и на отдельном писюке делать с юзерами что угодно ..

[Tosha]

PBR и ACL компилируются в единый набор tcam. Без разницы что тронуть ACL или PBR - жэлезка будет кумекать над построением общего результата.

И даже если свести все чисто к PBR лучше не будет - писать те же tcam в то же железо.

 

Наибольшие тормоза начинаются возможно когда удаляется что-то спереди и надо все двигать.

А если на порту и ACL и PBR то в tcam просто винигрет какой-то... Добавляешь 1 ACL а железка кушает 5 tcam :)

Изменено 15 декабря, 2011 пользователем Tosha