[alibek]

С позавчерашнего дня в сети вдруг появился непонятный трафик, который выглядит примерно так:

 

Сервисы предоставляются по PPPoE, абоненты l2connected, агрегация L2.

На агрегации в сторону абонентов вдруг появляется всплеск трафика под гигабит, который постепенно в течение 2-3 часов затухает. Потом снова повторяется.

 

Удалось снять дамп трафика (почти 4ГБ), где практически весь трафик посторонний (рабочий трафик очень незначительный).

И статистика показывает, что более 90% трафика в дампе — это PPPoE:

 

Основной объем трафика — это трафик с BDI-интерфейса BRAS, адресованный на CPE абонентов.

Ответного трафика нет (впрочем, за точкой съема трафика абонентов не было, поэтому и обратному трафику взяться неоткуда).

CPE разные, в основном Кинетики (потому что мы их рекомендуем абонентам), но есть и другие устройства, так что это не баг или уязвимость CPE.

На какие-то сетевые атаки снаружи или шторм изнутри не сильно похоже.

Больше всего похоже, что это какой-то глюк на самом BRAS.

 

Конфигурация BRAS примерно такая (убрал из конфигурации AAA-часть и ACL, оставил общий конфиг, интерфейсы и маршрутизацию):

Скрытый текст

version 16.9
service timestamps debug datetime localtime
service timestamps log datetime localtime
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
platform hardware throughput level 20000000
!
hostname BRAS15-ASR1001X
!
boot-start-marker
boot system bootflash:asr1001x-universalk9.16.09.08.SPA.bin
boot-end-marker
!
!
vrf definition CORE
 description "Service networks and backbone"
 !
 address-family ipv4
 exit-address-family
!
vrf definition MGMT
 description "Isolated control network"
 !
 address-family ipv4
 exit-address-family
!
vrf definition Mgmt-intf
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
aaa new-model
!
aaa group server radius BM6-PPPOE
 server-private **.**.**.** key *****
 ip vrf forwarding CORE
 ip radius source-interface Loopback1
!
aaa authentication login default local
aaa authentication ppp PPPOE group BM6-PPPOE
aaa authorization network PPPOE group BM6-PPPOE 
aaa accounting delay-start
aaa accounting jitter maximum 10
aaa accounting update periodic 10
aaa accounting network PPPOE start-stop group BM6-PPPOE
!
aaa nas port extended
!
aaa server radius dynamic-author
 client **.**.**.** vrf CORE
 client **.**.**.** vrf CORE
 client **.**.**.** vrf CORE
 client **.**.**.** vrf CORE
 server-key *****
 auth-type any
!
aaa session-id common
aaa policy interface-config allow-subinterface
clock timezone MSK 3 0
!
no ip domain lookup
ip domain name cybercom.local
!
subscriber templating
subscriber authorization enable
!
multilink bundle-name authenticated
!
spanning-tree extend system-id
diagnostic bootup level minimal
!
bba-group pppoe global
 virtual-template 1
 vendor-tag circuit-id service
 vendor-tag strip
 sessions max limit 65530
 sessions per-mac limit 10
 sessions per-vlan limit 1024
!
interface Loopback0
 description SELF
 vrf forwarding CORE
 ip address 10.1.255.255 255.255.255.255
!
interface Loopback1
 description LOOP-PPP
 vrf forwarding CORE
 ip address 10.255.255.215 255.255.255.255
!
interface TenGigabitEthernet0/0/0
 description UPLINK
 ip address **.**.**.** 255.255.255.240
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip access-group WAN_ACCESS in
 history BPS
!
interface TenGigabitEthernet0/0/1
 description SUBS
 no ip address
 history BPS
 service instance 400 ethernet
  encapsulation default
  bridge-domain 400
 !
!
interface Virtual-Template1
 mtu 1492
 ip unnumbered Loopback1
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 peer default ip address pool CLIENT-PPP
 ppp authentication pap PPPOE
 ppp authorization PPPOE
 ppp accounting PPPOE
 ppp timeout idle 60
!
interface BDI400
 no ip address
 vlan-range dot1q 400 499
  pppoe enable group global
 !
!
ip local pool STATIC-PPP ...
ip local pool CLIENT-PPP ...
ip route 0.0.0.0 0.0.0.0 <uplink>
ip route 10.0.0.0 255.0.0.0 Null0
ip route 172.16.0.0 255.240.0.0 Null0
ip route 192.168.0.0 255.255.0.0 Null0
ip route <sub-ip-pool> 255.255.248.0 Null0
ip route <sub-ip-pool> 255.255.252.0 Null0
ip route <sub-ip-pool> 255.255.248.0 Null0
ip route <sub-ip-pool> 255.255.248.0 Null0
ip route <sub-ip-pool> 255.255.252.0 Null0
ip route vrf Mgmt-intf 10.1.0.0 255.255.0.0 10.1.10.250 10
ip route vrf CORE 10.1.0.0 255.255.0.0 10.1.3.25
!

 

 

Вроде бы unknown unicast браться неоткуда, BRAS знает всех своих активных абонентов (connected) и неизвестные IP-адреса из абонентского пула (если это вдруг атака или спуфинг) должен просто дропать.

Никто с подобным не сталкивался?

Это какая-то ошибка в конфигурации? Или баг в железке?

[VolanD666]

 А по графикам если пойти и посмотреть с какого порта/на какой порт льется?