NetFlow/IPFIX პაიპლაინი Akvorado-სა და ClickHouse-ზე Tier-2 ISP-სთვის

ინტერფეისის მრიცხველი გეუბნებათ, რომ 10G uplink 70 პროცენტზეა. ის ვერ გეტყვით, რომელი დანიშნულების AS, რომელი კლიენტის პრეფიქსი ან რომელი UDP პორტია ამის მიზეზი. flow მონაცემები სწორედ ამ კითხვას პასუხობს, და ტრანზიტის მყიდველი ISP-სთვის ეს არის განსხვავება peering-ის გადაწყვეტილების გამოცნობასა და ცოდნას შორის.

Akvorado არის flow კოლექტორი, აგებული ზუსტად ამ ტიპის ამოცანისთვის: იღებს NetFlow v9-ს, IPFIX-სა და sFlow-ს, ამდიდრებს ყოველ ჩანაწერს მარშრუტიზაციისა და ინტერფეისის კონტექსტით და ათავსებს ClickHouse-ში, სადაც მას SQL-ით ეკითხებით. ქვემოთ აღწერილია, როგორ ეწყობა ეს ნაწილები ერთმანეთს და სად ტყდება.

პაიპლაინი კომპონენტების მიხედვით#

Akvorado არის სამი სერვისი პლუს ორი საცავი:

• inlet — უსმენს flow პაკეტებს UDP-ზე, ხსნის template-ებს, ატარებს გამდიდრებას და ჩანაწერებს აგზავნის Kafka-ში. ეს ერთადერთი ნაწილია, რომელიც აუცილებლად უნდა აუბამდეს ფეხს ტრაფიკის აფეთქებებს.
• Kafka — ბუფერი. სწორედ ის გაძლევთ საშუალებას, გადატვირთოთ ClickHouse, ხელახლა გაშალოთ სქემა ან ათი წუთით დაკარგოთ consumer flow-ების დაკარგვის გარეშე.
• ClickHouse — საცავი. ნედლი flow-ები პლუს აგრეგირებული rollup-ები, თითოეული საკუთარი შენახვის ვადით.
• orchestrator — ფლობს ClickHouse-ის სქემას და კონფიგურაციას გადასცემს დანარჩენ კომპონენტებს. ის ქმნის ცხრილებს, Kafka engine ცხრილებს და materialized view-ებს.
• console — მოთხოვნების API და ვებ-ინტერფეისი ზემოდან.

ექსპორტერები თავად როუტერებია. ყველაფერი, რაც მათ ქვემოთაა, მხოლოდ იმდენად კარგია, რამდენადაც ისინი აგზავნიან.

ექსპორტერების კონფიგურაცია#

შაბლონი ყველა ვენდორთან ერთნაირია: აღწერეთ sampler, აღწერეთ ექსპორტის მიზანი, ორივე მიაბით ინტერფეისებს. ქსელის საზღვარზე გააკეთეთ sampling შემომავალ მიმართულებაზე და იყავით თანმიმდევრული — ingress და egress sampling-ის შერევა ერთსა და იმავე გზაზე ტრაფიკს ორმაგად თვლის.

Juniper (inline sampling, IPFIX)#

services {
    flow-monitoring {
        version-ipfix {
            template ipv4-tpl {
                flow-active-timeout 60;
                flow-inactive-timeout 15;
                template-refresh-rate seconds 30;
                option-refresh-rate seconds 30;
                ipv4-template;
            }
        }
    }
}
forwarding-options {
    sampling {
        instance flow-ins {
            input { rate 1000; }
            family inet {
                output {
                    flow-server 10.20.0.5 {
                        port 2055;
                        version-ipfix { template ipv4-tpl; }
                    }
                    inline-jflow { source-address 10.0.0.1; }
                }
            }
        }
    }
}
chassis { fpc 0 { sampling-instance flow-ins; } }

Cisco IOS XR#

flow exporter-map AKVORADO
 version v9
  options interface-table timeout 60
  options sampler-table timeout 60
  template data timeout 60
 !
 transport udp 2055
 source Loopback0
 destination 10.20.0.5
!
sampler-map SAMPLE-1K
 random 1 out-of 1000
!
flow monitor-map FMM-IPV4
 record ipv4
 exporter AKVORADO
 cache timeout active 60
!
interface HundredGigE0/0/0/0
 flow ipv4 monitor FMM-IPV4 sampler SAMPLE-1K ingress

MikroTik RouterOS#

/ip traffic-flow
set enabled=yes active-flow-timeout=1m inactive-flow-timeout=15s
/ip traffic-flow target
add dst-address=10.20.0.5 port=2055 version=ipfix v9-template-refresh=20

RouterOS-ს sampler აქვს, ოღონდ ნაგულისხმევად გამორთულია — /ip traffic-flow-ის packet-sampling, sampling-interval და sampling-space. ზემოთ მოცემულ კონფიგურაციაში, sampling-ის გარეშე, ის ყველა პაკეტს ითვლის: ერთი მხრივ სიზუსტისთვის მოსახერხებელია, მეორე მხრივ დატვირთულ მოწყობილობაზე CPU-ს ძვირად უჯდება — და ნიშნავს, რომ ეს ექსპორტერი Akvorado-ში sampling rate 1-ით უნდა დარეგისტრირდეს და არა იმ 1000-ით, რომელიც გვერდით მდგარ როუტერებზე გაქვთ. თუ packet-sampling-ს ჩართავთ, შესაბამისი rate დაარეგისტრირეთ.

Sampling rate: ციფრი, რომელიც ყველაფერს აფუჭებს#

კონსოლში ყოველი ბაიტის მაჩვენებელი არის Bytes * SamplingRate. თუ როუტერი 1:1000-ზე აკეთებს sampling-ს, ხოლო Akvorado თვლის, რომ 1:1-ზე, ამ ექსპორტერის ყველა გრაფიკი სამი რიგით არასწორია — და დამაჯერებლად გამოიყურება, რადგან მრუდის ფორმა სწორი რჩება.

ზოგი პლატფორმა თავის rate-ს IPFIX options template-ში აცხადებს და Akvorado მას ავტომატურად იღებს. ზოგი — არა, და მაშინ თქვენ აღწერთ მას ექსპორტერის ქვექსელზე. შეამოწმეთ თითოეულ ექსპორტერზე ერთხელ: შეადარეთ flow-დან გამოთვლილი ინტერფეისის სიჩქარე იმავე ინტერფეისის SNMP ან gNMI მრიცხველს იმავე ფანჯარაზე. თუ ისინი რამდენიმე პროცენტის ფარგლებში ემთხვევა, rate სწორია; თუ სხვაობა თქვენს sampler კონფიგურაციას ჰგავს — არა.

sampling-ს სტატისტიკური ზღვარიც აქვს. კონკრეტულ flow-ზე ფარდობითი ცდომილება უხეშად უკუპროპორციულია მისი შერჩეული პაკეტების რაოდენობის კვადრატული ფესვისა, ამიტომ საათიან აგრეგატს ენდობით, ხოლო ერთწუთიან ფანჯარაში ერთ პატარა flow-ს — არა. გამოიყენეთ flow პროპორციებისა და რანჟირებისთვის; აბსოლუტური მოცულობისთვის — მრიცხველები.

გამდიდრება: რა აქცევს ჩანაწერს პასუხად#

ნედლი flow ჩანაწერი შეიცავს მისამართებს, პორტებს, პროტოკოლს, ბაიტებისა და პაკეტების რაოდენობას და ifIndex-ს. თავისთავად ეს თითქმის უსარგებლოა. Akvorado სამი სახის კონტექსტს ამატებს:

• ინტერფეისის მეტამონაცემები SNMP-ით. inlet ეკითხება თითო ექსპორტერს, რომ ifIndex გადათარგმნოს ifName-ად, ifDescr-ად და სიჩქარედ, ხოლო თქვენ თითო ინტერფეისს კლასიფიცირებთ როგორც external (ტრანზიტი, peering, IX) ან internal (კლიენტი, core), რათა კონსოლმა ტრანზიტი on-net ტრაფიკისგან გაარჩიოს.
• მარშრუტიზაციის მონაცემები BMP-ით. მიმართეთ როუტერების BMP ნაკადი Akvorado-ზე და ყოველი flow მიიღებს რეალურ AS path-ს, community-ებს და next hop-ს, რომელიც როუტერმა ნამდვილად გამოიყენა. ეს გაცილებით სჯობს origin AS-ის გამოცნობას GeoIP ტიპის ბაზიდან და სწორედ ეს ხდის შესაძლებელს თითო uplink-ზე ანალიზს.
• გეო და ASN ბაზები. ქვეყანა და ორგანიზაცია იმ მისამართებისთვის, რომლებსაც თქვენი მარშრუტიზაციის ცხრილი არ აღწერს.

თუ ინტერფეისების კლასიფიკაცია არასწორია, კონსოლში „ტრანზიტი vs peering“-ის ყველა ციფრი მასთან ერთად არასწორია. მოეპყარით საზღვრის კონფიგურაციას როგორც პროდაქშენ კონფიგურაციას: ვერსიების კონტროლში, როუტერის ცვლილების მსგავსი განხილვით.

ClickHouse: სქემა, rollup-ები და შენახვის ვადა#

orchestrator ქმნის ნედლ flows ცხრილს პლუს აგრეგირებული ცხრილების ნაკრებს უფრო მსხვილი დეტალიზაციით, თითოეულს materialized view-თი და საკუთარი TTL-ით. ჩანაფიქრი მარტივია: სრული დეტალიზაცია მოკლე ფანჯარაზე, აგრეგატები — გრძელზე.

დეტალიზაციის საფეხურები აირჩიეთ იმ კითხვებიდან, რომლებზეც პასუხი გჭირდებათ:

• ნედლი flow-ები: ინციდენტების გამოძიება და abuse-ის დამუშავება. მოკლე ვადა — ეს ცხრილი დანარჩენებს მრავალჯერ აღემატება.
• ერთწუთიანი აგრეგატები: capacity და traffic engineering დღეების მასშტაბით.
• ერთსაათიანი აგრეგატები: peering-ის ბიზნეს-დასაბუთება და წლიური შედარებები. საკმარისად იაფია დიდხანს შესანახად.

ორი პრაქტიკული შენიშვნა. შენახვის ვადა არა მხოლოდ დისკის, არამედ პოლიტიკის გადაწყვეტილებაა: flow ჩანაწერები შეიცავს კლიენტების IP მისამართებს, ამიტომ ნედლი ცხრილის TTL არის პასუხი კითხვაზე „რამდენ ხანს ვინახავთ აბონენტის იდენტიფიცირებად მონაცემს“. ეს ჩაწერეთ მანამ, სანამ ვინმე გკითხავთ. და Kafka-ს retention დატოვეთ იმაზე გრძელი, ვიდრე თქვენი ყველაზე ცუდი რეალისტური ClickHouse-ის შეფერხებაა, რადგან სწორედ ეს ფანჯარაა თქვენი მთელი აღდგენის შესაძლებლობა.

მოთხოვნები, რომლებსაც რეალურად უშვებთ#

კონსოლი ტიპურ ხედებს ფარავს, მაგრამ საინტერესო კითხვები SQL-შია. ტოპ დანიშნულების ქსელები ბოლო საათში:

SELECT
    DstAS,
    sum(Bytes * SamplingRate) * 8 / 3600 AS bits_per_second
FROM flows
WHERE TimeReceived > now() - INTERVAL 1 HOUR
  AND OutIfBoundary = 'external'
GROUP BY DstAS
ORDER BY bits_per_second DESC
LIMIT 20

რომელი uplink ატარებს კონკრეტულ დანიშნულების AS-ს და როგორ იყოფა:

SELECT
    ExporterName,
    OutIfName,
    sum(Bytes * SamplingRate) * 8 / 3600 AS bits_per_second
FROM flows
WHERE TimeReceived > now() - INTERVAL 1 HOUR
  AND DstAS = 15169
GROUP BY ExporterName, OutIfName
ORDER BY bits_per_second DESC

სწრაფი შემოწმება შესაძლო ამპლიფიკაციურ შეტევაზე — ერთი დანიშნულება, ერთი ამპლიფიკატორის საწყისი პორტი და reflector-ების დიდი რაოდენობა:

SELECT
    DstAddr,
    SrcPort,
    sum(Packets * SamplingRate) AS pps,
    uniq(SrcAddr) AS sources
FROM flows
WHERE TimeReceived > now() - INTERVAL 5 MINUTE
  AND Proto = 17
GROUP BY DstAddr, SrcPort
ORDER BY pps DESC
LIMIT 20

სვეტების სახელები Akvorado-ს სქემას მიჰყვება; დაშბორდში ჩასმამდე შეადარეთ ისინი თქვენი ინსტალაციის ვერსიას.

რა შეიძლება გატყდეს#

• sampling rate-ის შეუსაბამობა. აღწერილია ზემოთ და ყველა დანარჩენზე გაცილებით ხშირი მიზეზია იმისა, რომ flow-ის დანერგვას არავინ ენდობა.
• ifIndex-ის ცვლა. ბარათის გადატვირთვა ინდექსებს გადაანომრავს; სანამ SNMP poller არ განაახლებს, ტრაფიკი მიეწერება არასწორ ინტერფეისს ან — არცერთს.
• ექსპორტერის საწყისი მისამართი. Akvorado ექსპორტერებს flow პაკეტების საწყისი IP-თი ცნობს. როუტერი, რომელიც გადატვირთვის შემდეგ სხვა ინტერფეისიდან იწყებს გაგზავნას, ჩნდება როგორც სრულიად ახალი, დაუკონფიგურირებელი ექსპორტერი ნაგულისხმევი პარამეტრებით.
• ასიმეტრიული მარშრუტიზაცია. მხოლოდ ingress sampling ასიმეტრიულ გზაზე ხედავს ერთ მიმართულებას. პროპორციები შესაბამისად წაიკითხეთ.
• გვირაბებში და MPLS-ში ინკაფსულირებული ტრაფიკი. პლატფორმისა და template-ის მიხედვით, ექსპორტირებული გასაღებები შეიძლება მხოლოდ გარე სათაურს აღწერდეს. იცოდეთ, რომელ გზებს ეხება ეს, სანამ მათზე დასკვნებს გამოიტანთ.
• UDP-ის დანაკარგი დატვირთვისას. flow ექსპორტი UDP-ია. თუ კოლექტორი ან მისკენ მიმავალი გზა გადატვირთულია ზუსტად იმ ინციდენტის დროს, რომელიც გაინტერესებთ, ჩანაწერები უხმაუროდ იკარგება. inlet-ის საკუთარი drop მრიცხველები აქციეთ სრულფასოვან სერვისულ მეტრიკად.

საით მიდის ეს#

flow პაიპლაინი მიზანი არ არის; ის შესატანია. როცა ხედავთ მოცულობებს თითო uplink-სა და თითო დანიშნულების AS-ზე რეალური AS path-ებით, შემდეგი ნაბიჯია მათზე მოქმედება — ტრაფიკის გადანაწილება ტრანზიტებს შორის, IX პორტის დასაბუთება ან route leak-ის ამოცნობა მისი ტრაფიკული ხელწერით. ეს აღწერილია სტატიაში BGP traffic engineering flow მონაცემებით.

მრიცხველების მხარისთვის — ინტერფეისისა და რიგების მეტრიკები, რომლებთანაც ამას აკორელირებთ — იხილეთ SNMP polling თუ streaming telemetry.