Jump to content
Калькуляторы

6500 - дроп пакетов Input queue: 0/2000/316937210/0 (size/max/drops/flushes);

Reply to this topic

artplanet   

artplanet
Posted (edited)

Недавно прилетела ддос атака в 14-15Mpps syn флуда. Прилетела атака с двух провайдеров которые заведены на один бордер vs-s720-3c.

на входе в 6500 собран портчанел из портов Te3/8 и 4/8 - обе платы - WS-X6708-10G-3CXL

так же в шасси стоит плата WS-X6704-10G-3CXL во втором модуле.

Схема как были нагружены порты во время атаки: http://owncloud.su/index.php/s/rn8iMRgMe1w2dde

Вот график с одного из портов по mpps: http://owncloud.su/index.php/s/is5Sq2yUPe4JUN6 http://owncloud.su/index.php/s/WySvrOVdK5LPio0

То есть все пакеты долетели до порта и их посчитали счетчики на 6500

Далее - на обоих портах стали появлятся дропы пакетов:

Input queue: 0/2000/316937210/0 (size/max/drops/flushes); Total output drops: 0

Input queue: 0/2000/315218095/0 (size/max/drops/flushes); Total output drops: 0

во время атаки фабрика выдала макс нагрузку 47%

3 0 20G 4% 47% @21:07 15Nov16 2% 22% @21:07 15Nov16

3 1 20G 2% 7% @20:21 15Nov16 1% 8% @06:00 15Nov16

4 0 20G 3% 47% @21:07 15Nov16 3% 22% @21:07 15Nov16

4 1 20G 1% 8% @17:08 13Nov16 1% 8% @17:59 15Nov16

При этом наблюдались потери пакетов которые прилетали в порт Te3/8 и улетали в порт Te3/5 - а так как стоит плата DFC - то пакеты не покидали модуль.

А так же были потери пакетов из порта Te3/8 в порт Te3/1. Аналогично на 4ом модуле.

Настройка портов:

description Nexus
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 8,28,101,102,208-210,1069
switchport mode trunk
load-interval 30
channel-group 1 mode active

 

теперь настройка двух int vlan с который прилетела атака:

interface Vlan209
ip address 87.x.y.z 255.255.255.254
ip access-group uplink in
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip route-cache policy
ip policy route-map PBR-PROTECT
load-interval 30
end

и

interface Vlan102
ip address 62.x.y.z 255.255.255.254
ip access-group uplink in
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip route-cache policy
ip policy route-map PBR-PROTECT
load-interval 30
end

 

ip access-group uplink in - тут просто acl вида - deny ip 10.10.0.0 0.0.255.255 any

ip policy route-map PBR-PROTECT - тут PBR роутинг на входящие пакеты - чтобы делить атаку на 4ре параллельные железки по фильтрации атаки

 

немного слов о PBR 

show route-map  PBR-PROTECT
route-map PBR-PROTECT, deny, sequence 2
 Match clauses:
   ip address (access-lists): NO-PBR 
 Set clauses:
 Policy routing matches: 0 packets, 0 bytes
route-map PBR-PROTECT, permit, sequence 100
 Match clauses:
   ip address (access-lists): ADDOS-00 
 Set clauses:
   ip next-hop x.y.z.247
 Policy routing matches: 7743855 packets, 2182511306 bytes
route-map PBR-PROTECT, permit, sequence 101
 Match clauses:
   ip address (access-lists): ADDOS-01 
 Set clauses:
   ip next-hop x.y.x.245
 Policy routing matches: 5918721 packets, 1439344022 bytes

первое правило говорит о том - что мы не обрабатываем пакеты на те ip которые мы не защищаем.

120 permit ip x.y.z.0 0.0.3.255 any - такого плана ACL NO-PBR

но при этом при трассировке до хоста из этого блока Ip адресов были потери

8. m9-bb-po5.corbina.net                           0.0%     7    2.7   4.1   2.6  12.3   3.6
9. filanco.corbina.net                             0.0%     7    2.8   2.5   2.4   2.8   0.0
10. ???
11. prov.spb.cloud-ix.net                      14.3%     7   10.0  89.9  10.0 157.5  75.0
12. main.prov.ru                    28.6%     7   10.1  73.1  10.1 157.6  77.5

11 - это Cisco где были дропы пакетов

 

 

по графикам во время атаки нагрузка на процессор выросла на 3-4%

 

в итоге хочется понять откуда дропы пакетов. netflow? oversubscription на модулях не может быть виноват - трафик в одной группе портов был не выше 5Gb/s

Edited by artplanet

Share this post

Link to post
Share on other sites

dignity   

dignity
Posted

Я в прошлый раз уже хотел написать "что вы трупик насилуете", но не стал... Ну что вы трупик насилуете-то? Cisco 6500 - интеллектуальный коммутатор с кучей ограничений. Это не адская пакетная фабрика. Такие штуки делают force10, extreme networks, brocade.

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted (edited)

Я в прошлый раз уже хотел написать "что вы трупик насилуете", но не стал... Ну что вы трупик насилуете-то? Cisco 6500 - интеллектуальный коммутатор с кучей ограничений. Это не адская пакетная фабрика. Такие штуки делают force10, extreme networks, brocade.

 

А можно по делу? Без оффтопа. К тому же Ваши железки не держат FullView.

Edited by artplanet

Share this post

Link to post
Share on other sites

dmvy   

dmvy
Posted

По опыту Catalyst 3550/3750 крайне не рекомендуется в PBR использовать Deny. Удалите первое правило. К тому же оно ничего не матчит, а только занимает время при обработке. У нас для FV стоит 2 Juniper MX80 (раньше вообще 1 был) и 2 Extreme X670. По две штуки только ради резерва. Атаки до 15Гбит не замечаем. Дальше уже шейпер начинает деградировать из-за неоптимальной балансировки по очередям карточек intel x520.

Share this post

Link to post
Share on other sites

dignity   

dignity
Posted

А можно по делу? Без оффтопа. К тому же Ваши железки не держат FullView.

Full-view много что успешно держит, если что. Brocade MLX, MLXe, XMR, к примеру. А как многократно тут обсуждалось, FV, часто вообще нафиг не нужен... Как вариант, можно Вашу Cisco просто воткнуть в какую-нибудь VRRP-like топологию, в которой Вы будете делать failover в случае атак на модель без FV.

Share this post

Link to post
Share on other sites

mikezzzz   

mikezzzz
Posted

Далее - на обоих портах стали появлятся дропы пакетов:

Input queue: 0/2000/316937210/0 (size/max/drops/flushes); Total output drops: 0

Input queue: 0/2000/315218095/0 (size/max/drops/flushes); Total output drops: 0

а на SVI 209 и 102 счетчики не росли?

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

По опыту Catalyst 3550/3750 крайне не рекомендуется в PBR использовать Deny. Удалите первое правило. К тому же оно ничего не матчит, а только занимает время при обработке. У нас для FV стоит 2 Juniper MX80 (раньше вообще 1 был) и 2 Extreme X670. По две штуки только ради резерва. Атаки до 15Гбит не замечаем. Дальше уже шейпер начинает деградировать из-за неоптимальной балансировки по очередям карточек intel x520.

 

но у нас то не 3550/3750 - а 6500 с процом vs-s720-3cxl. Но в новой схеме мы будем выносить PBR на Cisco Nexus 3064-X (железка куплена и едет, но приедет через месяц). То есть 3064-X будет подключаться к двум бордерам и анонсировать ту сеть что мы защищаем. И уже на 3064-X будет PBR.

Но до этой схемы нам еще месяц жить минимум. А до этого хочется решить проблему на том оборудовании что есть.

К тому же на 6500 по документациям PBR работает с максимальной скоростью.

 

По поводу первого правила DENY - мы думали добавить в него те сети что не нужно защищать для того - чтобы внутри ACL с защитой не указывать те блоки что мы защищаем.

к примеру сейчас получается следующие ACL

show ip access-lists NO-PBR
 100 permit ip 10.10.10.0 0.0.0.255 any

(при трафике с этих IP не нужно учитывать PBR) - это служебная сеть в которой у нас коммутаторы. А на входе с аплинков стоит ACL который блокирует входящие пакеты с наших ip

 110 permit ip any 90.0.0.0 0.0.3.255   тут идет блок который мы не хотим защищать

А теперь внутри ACL с защитой

 

show ip access-lists ADDOS-00
 10 permit ip 0.0.0.0 255.255.255.252 0.0.0.0 0.0.0.0
show ip access-lists ADDOS-01
 10 permit ip 0.0.0.1 255.255.255.252 0.0.0.0 0.0.0.0
show ip access-lists ADDOS-02
 10 permit ip 0.0.0.2 255.255.255.252 0.0.0.0 0.0.0.0
show ip access-lists ADDOS-03
 10 permit ip 0.0.0.3 255.255.255.252 0.0.0.0 0.0.0.0

 

в итоге чтобы убрать первый DENY PBR придется переделать все ACL с защитой:

show ip access-lists ADDOS-00
  5 deny ip 10.10.10.0 0.0.0.255 any
  7 deny ip any 90.0.0.0 0.0.3.255
 10 permit ip 0.0.0.0 255.255.255.252 0.0.0.0 0.0.0.0
show ip access-lists ADDOS-01
  5 deny ip 10.10.10.0 0.0.0.255 any
  7 deny ip any 90.0.0.0 0.0.3.255
 10 permit ip 0.0.0.1 255.255.255.252 0.0.0.0 0.0.0.0
show ip access-lists ADDOS-02
  5 deny ip 10.10.10.0 0.0.0.255 any
  7 deny ip any 90.0.0.0 0.0.3.255
 10 permit ip 0.0.0.2 255.255.255.252 0.0.0.0 0.0.0.0
show ip access-lists ADDOS-03
  5 deny ip 10.10.10.0 0.0.0.255 any
  7 deny ip any 90.0.0.0 0.0.3.255
 10 permit ip 0.0.0.3 255.255.255.252 0.0.0.0 0.0.0.0

 

либо на вариант

show ip access-lists ADDOS-00
  5 deny ip 10.10.10.0 0.0.0.255 any
 10 permit ip 0.0.0.0 255.255.255.252 150.0.0.0 0.0.1.255
show ip access-lists ADDOS-01
  5 deny ip 10.10.10.0 0.0.0.255 any
 10 permit ip 0.0.0.1 255.255.255.252 150.0.0.0 0.0.1.255
show ip access-lists ADDOS-02
  5 deny ip 10.10.10.0 0.0.0.255 any
 10 permit ip 0.0.0.2 255.255.255.252 150.0.0.0 0.0.1.255
show ip access-lists ADDOS-03
  5 deny ip 10.10.10.0 0.0.0.255 any
 10 permit ip 0.0.0.3 255.255.255.252 150.0.0.0 0.0.1.255

 

в практике блоков ipv4 без защиты намного больше. И acl будет намного больше. К тому же при установке 8 железок по защите - то придется делать больше ACL

изначально у нас была схема без DENY в PBR - но в один прекрасный момент циска ругнулась что не хватает TCAM для программирования - так как сложный ACL

 

Nov  5 22:51:18.227: %FM-2-ACL_MERGE_NUM_ACES: ACL merge aborted due to number of ACEs threshold for features on interface Vlan505 in ingress direction, traffic may be switched in software
Nov  5 22:51:23.527: %FM-2-ACL_MERGE_NUM_ACES: ACL merge aborted due to number of ACEs threshold for features on interface Vlan3634 in ingress direction, traffic may be switched in software

 

хотя превышений не было и памяти свободной было уйма. и TCAM был свободный

 

 

show 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
 1          1%     5%     1%     1%     1%     1%     0%     0%   0%  0%   1%
 2          1%     4%     1%     1%     1%     1%     0%     0%   0%  0%   1%
 3          1%     5%     1%     1%     1%     1%     0%     0%   0%  0%   1%
 4          1%     5%     1%     1%     1%     1%     0%     0%   0%  0%   1%

 

а на SVI 209 и 102 счетчики не росли?

 

 

не проверил если честно - но потери были и на том трафике что прилетал через другие SVI в тех же физических портах. Но на всех этих SVI был ip flow ingress и PBR Roiting с теми же правилами.

Share this post

Link to post
Share on other sites

mikezzzz   

mikezzzz
Posted

CoPP

 

только через кактус - но ошибки на порту не снимали. только unicast packet

не совсем понял Вас, на 6500 настроена Control Plane Policy? графиков по полисерам для неё не строите?

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted (edited)

на 6500 настроена Control Plane Policy

 

значит я Вас не понял. Нет не стоит - не строим. Сейчас погуглим что это и попробуем поднять

 

(config)#control-plane 
(config-cp)#?
Control Plane configuration commands:
 exit            Exit from control-plane configuration mode
 no              Negate or set default values of a command
 service-policy  Configure QOS Service Policy

(config-cp)#service-policy input PBR-PROTECT
Policy PBR-PROTECT does not exist
error: failed to install policy map PBR-PROTECT

 

у нас же не шейпер - а просто PBR

Edited by artplanet

Share this post

Link to post
Share on other sites

mikezzzz   

mikezzzz
Posted

на 6500 настроена Control Plane Policy

 

значит я Вас не понял. Нет не стоит - не строим. Сейчас погуглим что это и попробуем поднять

 

(config)#control-plane 
(config-cp)#?
Control Plane configuration commands:
 exit            Exit from control-plane configuration mode
 no              Negate or set default values of a command
 service-policy  Configure QOS Service Policy

(config-cp)#service-policy input PBR-PROTECT
Policy PBR-PROTECT does not exist
error: failed to install policy map PBR-PROTECT

 

у нас же не шейпер - а просто PBR

 

я понял, просто думал может у вас настроена CoPP и какой-то трафик уходил на CPU, где и подыхал,

но раз CoPP нет и роста CPU в момент DDoS не было - видимо не оно

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

но раз CoPP нет и роста CPU в момент DDoS не было - видимо не оно

 

 

в том то и дело - все что было на порту - это PBR И netflow

а, еще есть 

monitor session 3 source vlan 2 - 3 , 28 , 102 , 208 - 210 , 603 rx
monitor session 3 destination interface Te1/4

 

но трафик отправлялся в порт процессора.

Share this post

Link to post
Share on other sites

mikezzzz   

mikezzzz
Posted

 

monitor session 3 source vlan 2 - 3 , 28 , 102 , 208 - 210 , 603 rx
monitor session 3 destination interface Te1/4

 

прикольно, а тут чего?

show monitor | b Egress

show platform hardware capacity rewrite-engine drop

show fabric errors

show fabric drop

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

show monitor | b Egress

show platform hardware capacity rewrite-engine drop

show fabric errors

show fabric drop

 

show monitor | b Egress
Egress SPAN Replication State:
Operational mode       : Centralized
Configured mode        : Centralized (default)


#show platform hardware capacity rewrite-engine drop
slot channel packet drops         total overruns
----+-------+--------------------+--------------+
1    0       0                    0
1    1       0                    0
2    0       0                    0
2    1       0                    0
3    0       0                    0
3    1       0                    0
4    0       0                    0
4    1       0                    0

#show fabric errors
Module errors:
slot    channel        crc      hbeat       sync   DDR sync
   1          0          0          0          0          0
   1          1          0          0          0          0
   2          0          0          0          0          0
   2          1          0          0          0          0
   3          0          0          0          0          0
   3          1          0          0          0          0
   4          0          0          0          0          0
   4          1          0          0          0          0

Fabric errors:
slot    channel       sync     buffer    timeout
   1          0          0          0          0
   1          1          0          0          0
   2          0          0          0          0
   2          1          0          0          0
   3          0          0          0          0
   3          1          0          0          0
   4          0          0          0          0
   4          1          0          0          0

#show fabric drop
 Polling interval for drop counters and timestamp is 15 in seconds 

 Packets dropped by fabric for different queues:
slot    channel    Low-Q-drops                  High-Q-drops
   1          0             19 @11:52 11Oct16              0
   1          1              2 @11:52 11Oct16              0
   2          0              0                             0
   2          1              0                             0
   3          0              0                             0
   3          1              0                             0
   4          0             21 @11:52 11Oct16              0
   4          1             21 @11:52 11Oct16              0

 

правда после полного дебага проблемы 15 ноября (на сколько хватило у нас знаний)

были выполнены команды

clear fabric peak-utilization

clear mls statistics

clear counters

Share this post

Link to post
Share on other sites

applx   

applx
Posted (edited)

а сколько по вашему нужно PPS чтоб переполнить буфер порта в 200MB и начать дропать? какой был средний размер пакета SYN атаки?

Edited by applx

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

все же мне думается что виноват именно netflow

во время атаки прилетело 16Mpps - у всех пакетов был random sorce ip и random source port. А теперь представьте что за секунду netflow должен генерировать 16 миллионов уникальных записей каждую секунду

Share this post

Link to post
Share on other sites

rover-lt   

rover-lt
Posted (edited)

один пакет - 40 байт. И при чем тут буфер - ведь в полку не упирались

 

в полку не упирались по усредненным за 5 минут графикам. А что было на секундном, миллисекундном уровне?

Edited by rover-lt

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

в полку не упирались по усредненным за 5 минут графикам. А что было на секундном, миллисекундном уровне?

 

 

у нас графики ежеминутные. Атака была минуты 3. по графикам не упирались.

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

а по какой причине мог закончиться буфер? прилетело 8mpps на порт - на порту шейперов и ничего нету что бы требовало обработку пакетов. значит пакет сразу ушел в обработку.

к тому же в счетчики пакетов трафик попадал - так как графики кактуса всё вывели.

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

Кстати - раз пакет посчитался процессором - значит пакет ушел в обработку и уже не находиться в буфере.

Ведь проблема видна - прилетело по графику 16mpps - а на защиту ушло всего 10mpps - а раз пакеты считались - то они из буферов ушли в модули на обработку.

Если бы был виноват буфер - то тогда бы плата не знала о его существовании и не посчитала бы его.

Share this post

Link to post
Share on other sites

applx   

applx
Posted

ваших 200МБ хватит на 200мс буфера при траффике в 10Гбпс от этого и посчитайте как быстро буфера просядут от DDos атаки (по ППС).обычно input / output drops на интерфейсе об этом говорят

Share this post

Link to post
Share on other sites

artplanet   

artplanet
Posted

еще раз - буфер тут не причем. сделали некий тест - отправили тестовую атаку сами на себя.

итого - в тот же модуль только в другой порт прилетело 9Mpps (без портчанелов - просто в физический порт)

http://owncloud.su/index.php/s/UFzEQlyE9di3Mfl

ни одного дропа - весь трафик нормально ушел на железки по защите и был отфильтрован.

 

 Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
 30 second input rate 5121262000 bits/sec, 9125122 packets/sec
 30 second output rate 235600000 bits/sec, 86061 packets/sec

 

фабрика почти так же была загружена.

 

   3       0        20G    4%   18% @23:49 17Nov16    3%   24% @21:36 18Nov16
   3       1        20G    2%   39% @21:40 18Nov16    2%    7% @21:39 18Nov16

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Followers 0
Go to topic listing Активное оборудование Ethernet, IP, MPLS, SDN/NFV...