BGP traffic engineering flow მონაცემებით: community-ები, local-pref და AS-path prepending

Traffic engineering multi-homed ქსელში ორი სხვადასხვა ამოცანაა, რომელსაც ხშირად ერთად უყურებენ. გამავალი ტრაფიკი გადის იმ გზით, რომელსაც თქვენ ირჩევთ — ანუ სრულად აკონტროლებთ. შემომავალი ტრაფიკი მოდის იმ გზით, რომელსაც ათასობით სხვა ქსელი ირჩევს — ანუ მასზე მხოლოდ გავლენას ახდენთ, და ყოველი ბერკეტი, რომელიც გაქვთ, არის თხოვნა, რომლის იგნორირების უფლებაც დაშორებულ ქსელს სრულად აქვს.

ჯგუფის საკუთარი ქსელი ამისთვის კარგი საყრდენია: AS203136 აანონსებს 185.143.176.0/22-ს და multi-homed არის სამ uplink-ზე — Caucasus Online, System Net და Silknet. ქვემოთ აღწერილი ლოგიკა სწორედ ასეთი ფორმის ტოპოლოგიას ეხება.

best-path-ის თანმიმდევრობა წყვეტს, რომელი ბერკეტი იმუშავებს#

სანამ რამეს შეეხებით, გაიხსენეთ, რა თანმიმდევრობით ამოწმებს BGP თავის კრიტერიუმებს — ბერკეტს აზრი მხოლოდ მაშინ აქვს, თუ შედარება მასამდე მივიდა:

1. უმაღლესი weight (Cisco-ს ლოკალური, როუტერს არ ტოვებს)
2. უმაღლესი local-preference
3. ლოკალურად წარმოშობილი მარშრუტები
4. უმოკლესი AS path
5. დაბალი origin ტიპი
6. დაბალი MED (ნაგულისხმევად მხოლოდ ერთი და იმავე მეზობელი AS-ის მარშრუტებს შორის)
7. eBGP უპირატესია iBGP-ზე
8. დაბალი IGP მეტრიკა next hop-მდე
9. უფრო ძველი მარშრუტი, შემდეგ დაბალი router-id, შემდეგ დაბალი peer მისამართი

მთავარი შედეგი ერთია: local-preference მოწმდება AS path-ის სიგრძემდე. თუ დაშორებული ქსელი local-pref-ს აყენებს თავისი იაფი ტრანზიტიდან მიღებულ მარშრუტებზე, თქვენს prepending-მდე შედარება საერთოდ არ მიდის. prepending მხოლოდ იმ გზებს შორის წყვეტს, რომლებიც დაშორებული ქსელისთვის სხვა მხრივ თანაბარია.

გამავალი: local-pref არის ბერკეტი, რომელიც სრულად თქვენია#

local-preference არის well-known discretionary ატრიბუტი: სავალდებულო თქვენი AS-ის შიგნით და არასოდეს იგზავნება eBGP peer-თან — სწორედ ამიტომაა საიმედო. აყენებთ იმპორტზე, და თქვენს AS-ში ყველა როუტერი შემდეგ თანხმდება, რომელი გასასვლელი გამოიყენოს.

BIRD 2:

filter import_upstream_a {
    bgp_local_pref = 150;
    accept;
}

protocol bgp upstream_a {
    local as 203136;
    neighbor 192.0.2.1 as 65001;
    ipv4 {
        import filter import_upstream_a;
        export filter { if net = 185.143.176.0/22 then accept; else reject; };
        import limit 1000000 action restart;
    };
}

FRR:

route-map FROM-UPSTREAM-A permit 10
 set local-preference 150
!
router bgp 203136
 neighbor 192.0.2.1 remote-as 65001
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map FROM-UPSTREAM-A in
  neighbor 192.0.2.1 route-map TO-UPSTREAM-A out
  neighbor 192.0.2.1 maximum-prefix 1000000 restart 15
 exit-address-family

local-pref დააყენეთ შერჩევით და არა გლობალურად. საერთო „ვამჯობინოთ uplink A“ გადაიტანს მთელ ტრაფიკს და, როგორც წესი, იმავე გადატვირთვას სხვაგან წარმოქმნის; uplink-ის მიერ მინიშნებულ community-ზე ან იმ დანიშნულებების prefix-list-ზე დამთხვევა, რომელთა გადატანაც ნამდვილად გინდათ, მხოლოდ იმას ცვლის, რაც იგულისხმეთ.

შემომავალი: ოთხი ბერკეტი, სასოწარკვეთის ზრდადი რიგით#

uplink-ის შემოთავაზებული community-ები#

ეს არის პირველი, რაც უნდა სცადოთ, და ის, რასაც ყველაზე ხშირად ტოვებენ გვერდზე. ტრანზიტის მომწოდებელთა უმეტესობა აქვეყნებს community-ების ნუსხას, რომლითაც შეგიძლიათ თქვათ „სამჯერ დაამატე prepend AS X-ისკენ“, „არ გამოაცხადო AS Y-სთვის“ ან „დააყენე local-pref 80 შენს ქსელში“. ისინი მოქმედებენ uplink-ის საზღვარზე, გადაწყვეტილების წერტილთან უფრო ახლოს, ამიტომ ზუსტია და შექცევადი.

! მაგალითი: მომწოდებლის გამოქვეყნებული TE community ანონსზე
route-map TO-UPSTREAM-A permit 10
 match ip address prefix-list OUR-PREFIXES
 set community 65001:1234 additive

აქ მნიშვნელოვანია RFC 8092 large community-ები: 4-ბაიტიან ASN-ებთან ASN:function:parameter ტრიპლეტი ერთადერთი კოდირებაა, რომელიც ეტევა, ამიტომ თანამედროვე მომწოდებლის TE დოკუმენტაცია სწორედ ამ ფორმით ჩამოთვლის მათ.

ორი სტანდარტული community ღირს ცოდნად მომწოდებლის მიუხედავად: no-export (65535:65281) პრეფიქსს ტოვებს მეზობელი AS-ის შიგნით, ხოლო graceful shutdown (RFC 8326, 65535:0) ეუბნება peer-ს, დააქვეითოს სესია, რომელსაც პროფილაქტიკისთვის აპირებთ ჩამოგდებას — ეს გაცილებით სუფთაა, ვიდრე სესიის უბრალოდ გაწყვეტა.

AS-path prepending#

prepending უხეშია, სამაგიეროდ უნივერსალური. ის მუშაობს მხოლოდ იქ, სადაც local-pref უკვე არ წყვეტს, რაც პრაქტიკულად ნიშნავს იმ ტრაფიკს, რომელიც თქვენამდე საკუთარი მკაცრი პოლიტიკის არმქონე ქსელებით მოდის.

Junos:

policy-options {
    policy-statement to-upstream-a {
        term announce {
            from {
                route-filter 185.143.176.0/22 exact;
            }
            then {
                as-path-prepend "203136 203136";
                accept;
            }
        }
        then reject;
    }
}

Cisco IOS:

route-map TO-UPSTREAM-A permit 10
 match ip address prefix-list OUR-PREFIXES
 set as-path prepend 203136 203136

დაიწყეთ ერთი prepend-ით და გაზომეთ, სანამ მეორეს დაამატებთ. გრძელი prepend პროპორციულად მეტ ტრაფიკს არ გადაიტანს; რამდენიმეს შემდეგ დარჩენილი ტრაფიკი მოდის სხვაგან მიღებული local-pref გადაწყვეტილებების გამო და მას prepending ვერანაირი რაოდენობით ვერ დაძრავს. ძალიან გრძელი AS path-ები იმ ქსელების ფილტრებსაც იზიდავს, რომლებიც მას leak-ის ნიშნად თვლიან.

MED#

MED სასარგებლოა მხოლოდ მაშინ, როცა ერთსა და იმავე მეზობელ AS-თან რამდენიმე სესია გაქვთ — მაგალითად, ორი არხი ერთ uplink-ზე. ნაგულისხმევად ის შედარებადია მხოლოდ ერთი მეზობელი AS-ის ფარგლებში, ხოლო always-compare-med-ის ჩართვა ამის შესაცვლელად ცნობილი გზაა არადეტერმინირებული best-path შერჩევის მისაღებად. დატოვეთ გამორთული.

უფრო კონკრეტული პრეფიქსები და ROA, რომელიც მათ განაგებს#

უფრო კონკრეტული პრეფიქსის (more-specific) გამოცხადება ის ბერკეტია, რომელიც მაშინ მუშაობს, როცა სხვა აღარაფერი, რადგან longest-prefix-match ნებისმიერ პოლიტიკას სჯობს — გარკვეულ ზღვრებში: /24-ზე გრძელ IPv4 და /48-ზე გრძელ IPv6 პრეფიქსებს DFZ-ის უმეტესობა ჭრის, ანუ /22 ორ სასარგებლო საფეხურს გაძლევთ, /24 კი — არცერთს. მას რეალური ფასიც აქვს: ის ამატებს ჩანაწერს გლობალურ ცხრილში ყველა იმ ქსელისთვის, რომელსაც სრული ხედი აქვს, და „წებოვანია“ — more-specific DFZ-ში რჩება მანამ, სანამ არ გამოიხმობთ და გამოხმობა არ გავრცელდება.

არსებობს უფრო მკაცრი შეზღუდვაც. ჯგუფის ROA 185.143.176.0/22-ისთვის გაცემულია maxLength /22-ით. ეს ნიშნავს, რომ ამ ბლოკიდან გამოყოფილი ნებისმიერი /23 ან /24, გამოცხადებული AS203136-იდან, არის RPKI Invalid — არა უბრალოდ უჩვეულო, არამედ აქტიურად უარყოფილი ყველა იმ ქსელის მიერ, რომელიც Route Origin Validation-ს ატარებს. ამიტომ traffic engineering-ისთვის დეაგრეგაცია მოითხოვს ჯერ ROA-ს განახლებას — და იმის მიღებას, რომ სწორედ თავისუფალი maxLength არის ის, რაც ყალბი more-specific hijack-ს შესაძლებელს ხდის.

როგორ გადავწყვიტოთ flow მონაცემებით, რა გადავიტანოთ#

ბერკეტები იაფია; ძნელი ისაა, იცოდე რისთვის დაქაჩო. სწორედ აქ იხდის flow პაიპლაინი თავის ფასს. სამუშაო თანმიმდევრობა:

1. გაზომეთ განაწილება. დააჯგუფეთ ტრაფიკი uplink-ის ინტერფეისისა და დანიშნულების AS-ის მიხედვით რეპრეზენტატულ ფანჯარაზე — სამუშაო დღის პიკზე, არა შაბათ-კვირის საშუალოზე. როგორც წესი, გამავალი მოცულობის ძირითად ნაწილს დანიშნულების ქსელების მცირე რაოდენობა იკავებს.
2. იპოვეთ გადასატანი წილი. გადასატანია ის ტრაფიკი, რომლის დანიშნულებაც ერთზე მეტი uplink-ით მიიღწევა. ტრაფიკი, რომელსაც მხოლოდ ერთი uplink ატარებს, არ გადადის, რასაც არ უნდა აკონფიგურიროთ.
3. აირჩიეთ ყველაზე მცირე ცვლილება, რომელიც პრობლემას ხსნის. ერთი დანიშნულების AS-ის გადატანა community-თი სჯობს მთელი ანონსის prepending-ს, რადგან დაზიანების რადიუსი ერთი AS-ია და არა მთელი ინტერნეტი.
4. შედეგი წინასწარ შეაფასეთ. თუ ამ AS-ს გადაიტანთ, აქვს თუ არა მიმღებ uplink-ს მარაგი თავის პიკზე და არა ამ წუთში?

პირველი ნაბიჯის SQL აღწერილია სტატიაში NetFlow/IPFIX პაიპლაინი Akvorado-სა და ClickHouse-ზე; ჩართული BMP გამდიდრებით ყოველ flow-ს ერთვის რეალური AS path და community-ები, რაც მეორე ნაბიჯს საერთოდ პასუხგასაცემს ხდის.

როგორ გავაკეთოთ ცვლილება უსაფრთხოდ#

• თითო ცვლადი ცალკე. შეცვალეთ ერთი პოლიტიკა, ერთ სესიაზე, და დააკვირდით. ორი ერთდროული ცვლილება იძლევა შედეგს, რომელსაც ვერავის მიაწერთ.
• ჯერ ფილტრები, მერე პოლიტიკა. prefix-list ექსპორტზე და maximum-prefix ლიმიტი იმპორტზე traffic engineering არ არის, მაგრამ სწორედ ისინი აჩერებენ პოლიტიკის შეცდომას ინციდენტად გადაქცევამდე.
• სამუშაო ფანჯარა და rollback ტექსტი. ზუსტი rollback ბრძანებები ჩაწერეთ ცვლილებამდე და არა მაშინ, როცა უკვე გაფუჭდა.
• Soft reconfiguration. გამოიყენეთ inbound soft reconfiguration ან route refresh, რომ პოლიტიკა ხელახლა შეაფასოთ სესიების ჩამოგდების გარეშე.

შემოწმება, რომ იმუშავა#

ჯერ ლოკალური მდგომარეობა — რას აგზავნით სინამდვილეში:

# Junos
show route advertising-protocol bgp 192.0.2.1 185.143.176.0/22 detail

# FRR
vtysh -c "show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes"

# BIRD
birdc "show route export upstream_a all"

შემდეგ გარე ხედი, რომელიც შემომავალი ტრაფიკისთვის ერთადერთი მნიშვნელოვანია. RIPE RIS და საჯარო looking glass-ები აჩვენებს, რას ხედავენ დაშორებული ქსელები, მათ შორის რამდენი prepend გადარჩა და რომელი community-ებია ჯერ კიდევ მიბმული. მსჯელობამდე მიეცით პროპაგაციას დრო: გლობალურ ცხრილში კონვერგენცია მყისიერი არ არის, და ცვლილებიდან ერთ წუთში აღებული გაზომვა არაფერს გეუბნებათ.

ბოლოს დაადასტურეთ, რომ ტრაფიკი ნამდვილად გადავიდა — გაუშვით იგივე flow მოთხოვნა, რომლითაც ცვლილება დაგეგმეთ. „მარშრუტიზაციის ცხრილში ახალი გზა ჩანს“ და „ინტერფეისების მრიცხველებზე ახალი განაწილება ჩანს“ ორი სხვადასხვა მტკიცებაა, და მიზანი მხოლოდ მეორეა.

ყველაზე ხშირი შეცდომები#

• ხუთჯერ prepend, შედეგის არარსებობა და კიდევ prepend — იმის ნაცვლად, რომ იკითხო, ხომ არ წყვეტს რეალურად local-pref uplink-ის მხარეს.
• local-pref-ის გლობალურად დაყენება ერთ uplink-ზე და იმ ტრაფიკის გადატანა, რომელსაც პრობლემა არ ჰქონდა.
• more-specific-ის გამოცხადება ROA-ს maxLength-ის შემოწმების გარეშე.
• community-ები, რომლებიც უხმაუროდ იშლება, რადგან uplink კლიენტებისგან შემომავალ community-ებს ჭრის — ეს ხშირია და წინასწარ იშვიათად კითხულობენ.
• maximum-prefix ლიმიტის არარსებობა, ანუ კლიენტისგან სრული ცხრილის leak თქვენს ავარიად იქცევა.
• პროფილაქტიკური გამორთვის პოლიტიკის ცვლილებად მოპყრობა RFC 8326 graceful shutdown-ის ნაცვლად და უმიზეზოდ მკვეთრი რეკონვერგენციის მიღება.

ამის სარეგისტრაციო მხარე — ROA-ები, route ობიექტები და as-set, რომლითაც uplink-ები გფილტრავენ — აღწერილია სტატიაში RIPE NCC-ის რესურსები თავიდან ბოლომდე. თუ ცვლილება საკმარისად დიდია, რომ სარისკო იყოს, ჯერ გაიმეორეთ ლაბორატორიაში: მიგრაციის ტესტირება EVE-NG-ში.