Šodien mēs apskatīsim BGP protokolu. Nepavadīsim ilgu laiku runājot par to, kāpēc un kādēļ tas tiek izmantots kā vienīgais protokols. Ir pietiekami daudz informācijas par šo tēmu, piemēram, .
Tātad, kas ir BGP? BGP ir dinamiskās maršrutēšanas protokols, kas ir vienīgais EGP (External Gateway Protocol) protokols. Šo protokolu izmanto maršrutēšanas veidošanai internetā. Apskatīsim, kā tiek veidota kaimiņattiecība starp diviem BGP maršrutētājiem.
Apskatīsim kaimiņattiecību starp Router1 un Router3. Iestatīsim tos, izmantojot šādas komandas:
router bgp 10
network 192.168.12.0
network 192.168.13.0
neighbor 192.168.13.3 remote-as 10
router bgp 10
network 192.168.13.0
network 192.168.24.0
neighbor 192.168.13.1 remote-as 10Kaimiņattiecība iekš vienas autonomās sistēmas — AS 10. Pēc datu ievades maršrutētājā, piemēram, uz Router1, šis maršrutētājs mēģina izveidot kaimiņattiecības ar maršrutētāju Router3. Sākotnējais stāvoklis, kad nekas nenotiek, tiek saukts par Idle. Kad BGP tiks iestatīts uz Router1, tas sāks klausīties TCP portā 179 — pārslēgsies uz stāvokli Pieslēgties, un kad tiks mēģināts atvērt sesiju ar Router3, tas pāries uz stāvokli Aktīvs.
Pēc tam, kad sesija tiks izveidota starp Router1 un Router3, tiks notikusi Open ziņojumu apmaiņa. Kad šo ziņojumu nosūtīs Router1, šis stāvoklis tiks saukts par Open Sent. Un, kad tiks saņemts Open ziņojums no Router3, tas pāries uz stāvokli Open Confirm. Apskatīsim detalizētāk Open ziņojumu:
Šajā ziņojumā tiek nosūtīta informācija par pašu BGP protokolu, ko izmanto maršrutētājs. Apmainoties ar Open ziņojumiem, Router1 un Router3 savstarpēji ziņo informāciju par saviem iestatījumiem. Tiek nosūtīti šādi parametri:
- Versija: tas iekļauj BGP versiju, kuru izmanto maršrutētājs. Pašreizējā BGP versija ir versija 4, kas aprakstīta RFC 4271. Divi BGP maršrutētāji centīsies vienoties par saderīgu versiju; ja pastāv neatbilstība, tad BGP sesija netiks izveidota.
- Mans AS: tas iekļauj BGP maršrutētāja AS numuru; maršrutētājiem būs jāvienojas par AS numuru(-iem), un tas arī nosaka, vai tie darbosies iBGP vai eBGP.
- Hold Time: ja BGP no otras puses nesaņem nekādus keepalive vai atjaunināšanas ziņojumus hold time ilgumā, tad tas deklarēs otro pusi par ‘mirušu’ un iznīcinās BGP sesiju. Noklusējuma hold time ir iestatīts uz 180 sekundēm Cisco IOS maršrutētājos, keepalive ziņojums tiek nosūtīts ik pēc 60 sekundēm. Abiem maršrutētājiem ir jāvienojas par hold time, citādi BGP sesija netiks izveidota.
- BGP Identifier: tas ir vietējais BGP maršrutētāja ID, kas tiek vēlēts tieši tāpat kā OSPF:
- Izmanto maršrutētāja ID, kas tika konfigurēts manuāli ar bgp router-id komandu.
- Izmanto augstāko IP adresi uz loopback interfeisa.
- Izmanto augstāko IP adresi uz fiziskā interfeisa.
- Papildus parametri: šeit jūs atradīsiet dažas opcijas BGP maršrutētājam. Šī lauka pievienošana ļauj pievienot jaunās funkcijas BGP, neizmantojot jaunu versiju. Šeit varat atrast sekojošo:
- atbalstu MP-BGP (Multi Protocol BGP).
- atbalstu maršruta atsvaidzināšanai.
- atbalstu 4-octet AS numuriem.
Lai izveidotu kaimiņattiecības, ir jāizpilda šādi nosacījumi:
- Versijas numurs. Pašreizējā versija ir 4.
- AS numuram jāatbilst tam, ko jūs esat iestatījis neighbor 192.168.13.3 remote-as 10.
- Maršrutētāja ID nedrīkst būt vienāds ar kaimiņu.
Ja kāds no parametriem neatbilst šiem nosacījumiem, maršrutētājs nosūtīs Notification ziņojumu ar kļūdas informāciju. Pēc Open ziņojumu nosūtīšanas un saņemšanas kaimiņattiecības stāvoklis pāriet uz ESTABLISHED. Pēc tam maršrutētāji var apmainīties ar maršrutēšanas informāciju, to darot ar Atjaunināt ziņojumiem. Šāds Update ziņojums tiek nosūtīts no Router1 uz Router3:
Šeit norāda tīklus, par kuriem informē Router1, un ceļu atribūti, kas ir līdzīgi metrikām. Par ceļu atribūtiem runāsim detalizētāk. Arī TCP sesijas ietvaros tiek nosūtīti Keepalive ziņojumi. Tie tiek nosūtīti, pēc noklusējuma, katras 60 sekundes. Tas ir Keepalive taimeris. Ja Hold taimerī netiks saņemts Keepalive ziņojums, tas nozīmēs savienojuma zudumu ar kaimiņu. Pēc noklusējuma tas ir 180 sekundes.
Noderīga tabula:
Izskatās, ka esam sapratuši, kā maršrutētāji viens otram nosūta informāciju, tagad mēģināsim saprast BGP protokola darbības loģiku.
Lai paziņotu kādu maršrutu BGP tabulā, kā IGP protokolos, tiek izmantota komanda network, bet darba loģika atšķiras. Ja IGP, pēc maršruta norādīšanas komandas network ietvaros, pārbauda, kuri interfeisi pieder šai apakšnetei un iekļauj tos savā tabulā, tad komanda network BGP skatās maršrutēšanas tabulā un meklē precīzu atbilstību maršrutam komandas network iekšienē. Atrodot šādus maršrutus, tie nonāks BGP tabulā.
Meklējiet maršrutu maršrutētāja pašreizējā IP maršrutēšanas tabulā, kas precīzi atbilst komandas network parametriem; ja IP maršruts pastāv, ievietojiet atbilstošo NLRI vietējā BGP tabulā.
Tagad pacelsim BGP visos atlikušajos un redzēsim, kā notiek maršruta izvēle vienā AS. Pēc tam, kad BGP maršrutētājs saņems maršrutus no kaimiņa, sākas optimālā maršruta izvēle. Šeit jāizprot, kāda veida kaimiņi var būt — iekšējie un ārējie. Maršrutētājs konfigurācijā saprot, vai konfigurētais kaimiņš ir iekšējs vai ārējs? Ja komandā:
neighbor 192.168.13.3 remote-as 10 Kā parametrs remote-as norādīts AS, kas ir konfigurēts pašā maršrutētājā komandas router bgp 10 ietvaros. Maršruti, kas saņemti no iekšējā AS, tiek uzskatīti par iekšējiem, bet maršruti no ārējā attiecīgi par ārējiem. Un attiecībā uz katru darbojas atšķirīga loģika saņemšanai un nosūtīšanai. Apskatīsim šādu topoloģiju:
Uz katra maršrutētāja ir konfigurēts loopback interfeiss ar IP: x.x.x.x 255.255.255.0 — kur x ir maršrutētāja numurs. Uz Router9 mums ir loopback interfeiss ar adresi — 9.9.9.9 255.255.255.0. To mēs reklamēsim pa BGP un paskatīsimies, kā tas izplatās. Šis maršruts tiks nodots Router8 un Router12. No Router8 šis maršruts nonāks Router6, bet uz Router5 maršrutēšanas tabulā tā nebūs. Arī uz Router12 šis maršruts nonāks tabulā, bet uz Router11 tā arī nebūs. Mēģināsim to izprast. Apskatīsim, kādi dati un parametri tiek nosūtīti no Router9 tās kaimiņiem, ziņojot par šo maršrutu. Pakete zemāk tiks nosūtīta no Router9 uz Router8.
Informācija par maršrutu sastāv no ceļa atribūtiem (Path attributes).
Ceļa atribūti ir sadalīti 4 kategorijās:
- Well-known mandatory — visi maršrutētāji, kas darbojas ar BGP protokolu, ir jāspēj atpazīt šos atribūtus. Tie jāiekļauj visās atjaunināšanās (update).
- Well-known discretionary — visi maršrutētāji, kas darbojas ar BGP protokolu, ir jāspēj atpazīt šos atribūtus. Tie var būt atjaunināšanās (update), bet to klātbūtne nav obligāta.
- Optional transitive — tos var neatzīt visās BGP implementācijās. Ja maršrutētājs nav atpazinis atribūtu, tas marķē atjauninājumu kā daļēju (partial) un nosūta to tālāk kaimiņiem, saglabājot neatzīto atribūtu.
- Optional non-transitive — tos var neatzīt visās BGP implementācijās. Ja maršrutētājs nav atpazinis atribūtu, tad atribūts tiek ignorēts un nosūtot kaimiņiem tiek noraidīts.
BGP atribūtu piemēri:
- Well-known mandatory:
- Autonomous system path
- Next-hop
- Origin
- Well-known discretionary:
- Local preference
- Atomic aggregate
- Optional transitive:
- Aggregator
- Communities
- Optional non-transitive:
- Multi-exit discriminator (MED)
- Originator ID
- Cluster list
Šajā gadījumā mūs pagaidām interesē Origin, Next-hop, AS Path. Tā kā maršruts tiek nodots starp Router8 un Router9, t.i., iekšējā AS, tas tiek uzskatīts par iekšēju, un mēs pievērsīsim uzmanību Origin.
Atribūts Origin — norāda, kādā veidā maršruts tika iegūts atjauninājumā. Iespējamās atribūta vērtības:
- 0 — IGP: NLRI iegūts iekšēji sākotnējā autonomajā sistēmā;
- 1 — EGP: NLRI apguva, izmantojot Exterior Gateway Protocol (EGP). Tas ir BGP priekšgājējs, bet vairs netiek izmantots.
- 2 — Nepilnīgs: NLRI tika mācīta kādā citā veidā.
Mūsu gadījumā, kā redzams no paketes, vērtība ir 0. Kad šis maršruts tiks nodots Router12, tad šim kodam būs vērtība — 1.
Tālāk — Next-hop. Next-hop atribūts.
- Tas ir eBGP maršrutētāja IP adrese, caur kuru tiek nodots ceļš uz galamērķa tīklu.
- Atribūts mainās, kad prefikss tiek nodots citai AS.
Savukārt iBGP gadījumā, t.i., vienas AS iekšienē, Next-hop būs tas, kurš uzzināja vai paziņoja par šo maršrutu. Mūsu gadījumā tas būs 192.168.89.9. Bet, kad šo maršrutu nosūtīs no Router8 uz Router6, Router8 to mainīs un aizvietos ar savu. Next-hop būs — 192.168.68.8. Tas mūs noved pie diviem noteikumiem:
- Ja maršrutētājs nodod maršrutu savam iekšējam kaimiņam, tad tas nemaina Next-hop parametru.
- Ja maršrutētājs nodod maršrutu savam ārējam kaimiņam, tad tas maina Next-hop uz IP adresi no interfeisa, caur kuru maršrutētājs to nosūta.
Tas mūs noved pie pirmās problēmas — kāpēc maršruts nebūs maršrutēšanas tabulā Router5 un Router11. Apskatīsim to detalizētāk. Tātad Router6 ieguva informāciju par maršrutu 9.9.9.0/24 un veiksmīgi pievienoja to maršrutēšanas tabulai:
Router6#show ip route bgp
Koda: L - lokāls, C - savienots, S - statisks, R - RIP, M - mobilais, B - BGP
D - EIGRP, EX - EIGRP ārējais, O - OSPF, IA - OSPF iekšējā zona
N1 - OSPF NSSA ārējais 1. tips, N2 - OSPF NSSA ārējais 2. tips
E1 - OSPF ārējais 1. tips, E2 - OSPF ārējais 2. tips
i - IS-IS, su - IS-IS kopsavilkums, L1 - IS-IS līmenis-1, L2 - IS-IS līmenis-2
ia - IS-IS iekšējā zona, * - kandidātu noklusējums, U - lietotāja statiskais ceļš
o - ODR, P - periodiski lejupielādēts statiskais ceļš, H - NHRP, l - LISP
a - lietojumprogrammas ceļš
+ - replikēts ceļš, % - nākamā lēciena pārsteigums, p - pārsteigumi no PfR
Pēdējā patvēruma vārti nav iestatīti
9.0.0.0/24 ir apakšnetēts, 1 apakšneti
B 9.9.9.0 [20/0] caur 192.168.68.8, 00:38:25<source>
Tagad Router6 ir nodēvējis maršrutu Router5 un pirmajā Next-hop noteikumā to nemainīja. Tas nozīmē, ka Router5 jāpapildina <b>9.9.9.0 [20/0] caur 192.168.68.8</b> , taču tam nav maršruta līdz 192.168.68.8 un tāpēc šis maršruts tiks pievienots, lai gan informācija par šo maršrutu tiks saglabāta BGP tabulā:
<source><b>Router5#show ip bgp
BGP tabulas versija ir 1, lokālā maršrutētāja ID ir 5.5.5.5
Stāvokļa kodi: s apslāpēts, d slāpēts, h vēsture, * derīgs, > labākais, i - iekšējs,
r RIB-kļūda, S novecojis, m daudzceļa, b rezerves-ceļš, f RT-Filtrs,
x labākais-ārējais, a papildu-ceļš, c RIB-saspiests,
Izcelsmes kodi: i - IGP, e - EGP, ? - nepilnīgs
RPKI validācijas kodi: V derīgs, I nederīgs, N neatrasts
Tīkls Nākamais lēciens Metriķis LocPrf Svars Ceļš
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>Tā pati situācija notiks arī starp Router11-Router12. Lai izvairītos no šādas situācijas, jāiestata, lai Router6 vai Router12, nododot maršrutu saviem iekšējiem kaimiņiem, iekļautu kā Next-hop savu IP adresi. To var izdarīt, izmantojot komandu:
neighbor 192.168.56.5 next-hop-selfPēc šīs komandas Router6 nosūtīs Update ziņojumu, kurā maršrutiem kā Next-hop tiks norādīta Gi0/0 interfeisa IP adrese Router6 — 192.168.56.6, pēc tam šis maršruts jau nokļūs maršrutēšanas tabulā.
Turpināsim un pārbaudīsim, vai šis maršruts parādīsies Router7 un Router10. Maršrutēšanas tabulā tas nebūs, un mēs varētu domāt, ka problēma ir tāda pati kā pirmajā ar Next-hop parametru, bet, ja mēs paskatīsimies uz komandas show ip bgp izvadi, mēs redzēsim, ka maršruts pat netika saņemts pat ar nepareizu Next-hop, kas nozīmē, ka maršruts pat netika nodots. Tas mūs noved pie vēl viena noteikuma:
Maršruti, kas iegūti no iekšējiem kaimiņiem, netiek nodoti citiem iekšējiem kaimiņiem.
Tā kā Router5 saņēma maršrutu no Router6, tas netiks nodots citam savam iekšējam kaimiņam. Lai nodotu maršrutu, ir nepieciešams konfigurēt funkciju , vai arī konfigurēt pilnībā savstarpējās kaimiņattiecības (Full Mesh), t.i., katrs Router5-7 būs kaimiņš ar katru. Šajā gadījumā mēs izmantosim maršruta atspoguļotāju. Router5 ir jāizmanto šī komanda:
neighbor 192.168.57.7 route-reflector-clientMaršruta atspoguļotājs maina BGP uzvedību maršruta nodošanā iekšējam kaimiņam. Ja iekšējais kaimiņš ir norādīts kā route-reflector-client, tad šiem klientiem tiks paziņoti iekšējie maršruti.
Maršruts neparādījās uz Router7? Neaizmirstam arī par Next-hop. Pēc šīm manipulācijām maršrutam jāparādās arī uz Router7, bet tas nenotiek. Tas mūs noved pie vēl viena noteikuma:
Next-hop noteikums darbojas tikai ārējiem maršrutiem. Iekšējiem maršrutiem next-hop atribūta nomaiņa nenotiek.
Un mēs iegūstam situāciju, kurā nepieciešams izveidot vidi, izmantojot statisku maršrutēšanu vai IGP protokolus, lai informētu maršrutētājus par visiem maršrutiem iekšā AS. Uzrakstīsim statiskos maršrutus uz Router6 un Router7, un pēc tam iegūsim nepieciešamo maršrutu maršrutētāja tabulā. AS 678 mēs rīkosimies nedaudz savādāk — uzrakstīsim statiskos maršrutus 192.168.112.0/24 uz Router10 un 192.168.110.0/24 uz Router12. Tālāk izveidosim kaimiņattiecības starp Router10 un Router12. Arī konfigurēsim uz Router12, lai tas nosūtītu savu next-hop Router10:
neighbor 192.168.110.10 next-hop-selfRezultāts būs tāds, ka Router10 saņems maršrutu 9.9.9.0/24, to saņems gan no Router7, gan no Router12. Apskatīsim, kuru izvēli veiks Router10:
Router10#show ip bgp
BGP tabulas versija ir 3, vietējā maršrutētāja ID ir 6.6.6.6
Statusa kodi: s apspiests, d noslāpēts, h vēsture, * derīgs, > labākais, i - iekšējais,
r RIB-kļūda, S novecojis, m vairāku ceļu, b rezerves ceļš, f RT-Filtrs,
x labākais-ārējais, a papildu-ceļš, c RIB-saspiests,
Izcelsmes kodi: i - IGP, e - EGP, ? - nepilnīgs
RPKI validācijas kodi: V derīgs, I nederīgs, N Nav atrasts
Tīkls Next Hop Metriķis LocPrf Svars Ceļš
* >i 9.9.9.0/24 192.168.112.12 0 100 0 45 i
192.168.107.7 0 123 45 i Kā redzam, ir divi maršruti, un bultiņa (>) norāda, ka izvēlēts maršruts caur 192.168.112.12.
Apskatīsim, kā notiek maršruta izvēles process:
- Pirmkārt, saņemot maršrutu, tiek pārbaudīta tā Next-hop pieejamība. Tieši tāpēc, kad mēs saņēmām maršrutu uz Router5 bez Next-hop-self konfigurācijas, šis maršruts tālāk netika nodots apstrādei.
- Tālāk nāk parametrs Weight. Šis parametrs nav ceļa atribūts (PA) un netiek pārsūtīts BGP ziņojumos. Tas tiek konfigurēts lokāli katrā maršrutētājā un tiek izmantots tikai maršruta izvēles manipulēšanai pašā maršrutētājā. Apskatīsim piemēru. Nedaudz augstāk redzams, ka Router10 izvēlējās maršrutu uz 9.9.9.0/24 caur Router12 (192.168.112.12). Lai mainītu Weight parametru, var izmantot route-map, lai noteiktu to noteiktiem maršrutiem, vai piešķirt to kaimiņam ar komandu:
neighbor 192.168.107.7 weight 200Tagad visiem maršrutiem no šī kaimiņa būs šāds svars. Apskatīsim, kā mainīsies maršruta izvēle pēc šīs manipulācijas:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Konfigurēts no konsoles ar konsoli BGP tabulas versija ir 2, vietējā maršrutētāja ID ir 6.6.6.6 Statusa kodi: s nomākts, d peldošs, h vēsture, * derīgs, > labākais, i - iekšējs, r RIB-kļūda, S novecojis, m daudzceļš, b rezerves-ceļš, f RT-Filtrs, x labākais-ārējais, a papildu-ceļš, c RIB-saspiests, Origin kodi: i - IGP, e - EGP, ? - nepilnīgs RPKI validācijas kodi: V derīgs, I nederīgs, N Nav atrasts Tīkls Nākamais solis Metrika LocPrf Weight Ceļš * > 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iKā redzat, tagad maršruts tiek izvēlēts caur Router7, bet tam nebūs nekādas ietekmes uz pārējiem maršrutētājiem.
- Trešajā pozīcijā mums ir — Local Preference. Šis parametrs ir Well-known discretionary atribūts, kas nozīmē, ka tā klātbūtne nav obligāta. Šis parametrs ir spēkā tikai vienā AS un ietekmē ceļa izvēli tikai iekšējiem kaimiņiem. Tieši tāpēc to nosūta tikai Update ziņojumos, kas paredzēti iekšējam kaimiņam. Update ziņojumos ārējiem kaimiņiem tas nav pieejams. Tāpēc tas tika klasificēts kā Well-known discretionary. Mēģināsim to piemērot Router5. Uz Router5 mums ir jābūt diviem maršrutiem uz 9.9.9.0/24 — viens caur Router6 un otrs caur Router7.
Apskatīsim:
Router5#show bgp BGP tabulas versija ir 2, vietējā maršrutētāja ID ir 5.5.5.5 Statusa kodi: s nomākts, d peldošs, h vēsture, * derīgs, > labākais, i - iekšējs, r RIB-kļūda, S novecojis, m daudzceļš, b rezerves-ceļš, f RT-Filtrs, x labākais-ārējais, a papildu-ceļš, c RIB-saspiests, Origin kodi: i - IGP, e - EGP, ? - nepilnīgs RPKI validācijas kodi: V derīgs, I nederīgs, N Nav atrasts Tīkls Nākamais solis Metrika LocPrf Weight Ceļš * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 iBet kā redzam, viens maršruts ir caur Router6. Bet kur ir maršruts caur Router7? Varbūt arī uz Router7 tā nav? Apskatīsim:
Router#show bgp BGP tabulas versija ir 10, vietējā maršrutizatora ID ir 7.7.7.7 Statusa kodi: s apspiests, d dampingots, h vēsture, * derīgs, > labākais, i - iekšējais, r RIB-kļūda, S Novecojis, m multipath, b rezerves ceļš, f RT-Filtrs, x labākais-ārējais, a papildu-ceļš, c RIB-saspiests, Izcelsmes kodi: i - IGP, e - EGP, ? - nepilnīgs RPKI validācijas kodi: V derīgs, I nederīgs, N Netika atrasts Tīkla adrese Nākamais solis Metriķis LocPrf Svars Ceļš *> i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 192.168.107.10 0 678 45 iDīvaini, šķiet, ka viss ir kārtībā. Kāpēc tad tas netiek pārsūtīts uz Router5? Viss slēpjas tajā, ka BGP ir likums:
Maršrutizators nosūta tikai tos maršrutus, kurus izmanto pats.
Router7 izmanto maršrutu caur Router5, tāpēc maršruts caur Router10 netiks pārsūtīts. Atgriezīsimies pie Local Preference. Uzstādīsim Local Preference uz Router7 un paskatīsimies, kā reaģēs Router5:
route-map BGP atļaut 10 match ip adrese 10 set local-preference 250 access-list 10 atļaut jebkuru router bgp 123 neighbor 192.168.107.10 route-map BGP in</b>Tātad, mēs izveidojām route-map, kas iekļauj visus maršrutus, un teicām Router7, lai saņemot to maina parametru Local Preference uz 250, par noklusējumu tas ir 100. Skatām, kas notika uz Router5:
Router5#show bgp BGP tabulas versija ir 8, vietējā maršrutizatora ID ir 5.5.5.5 Statusa kodi: s apspiests, d dampingots, h vēsture, * derīgs, > labākais, i - iekšējais, r RIB-kļūda, S Novecojis, m multipath, b rezerves ceļš, f RT-Filtrs, x labākais-ārējais, a papildu-ceļš, c RIB-saspiests, Izcelsmes kodi: i - IGP, e - EGP, ? - nepilnīgs RPKI validācijas kodi: V derīgs, I nederīgs, N Netika atrasts Tīkla adrese Nākamais solis Metriķis LocPrf Svars Ceļš *> i 9.9.9.0/24 192.168.57.7 0 250 0 678 45 iKā mēs redzam, tagad Router5 dod priekšroku maršrutam caur Router7. Tāds pats attēls būs arī uz Router6, lai arī tam izdevīgāk ir izvēlēties maršrutu caur Router8. Jāpievieno arī tas, ka šī parametra maiņa prasa kaimiņu restartu, lai izmaiņas stātajos spēkā. Lasīt . Ar Local Preference esam sapratuši. Pārejam pie nākamā parametra.
- Maršruta priekšrocība ar parametru Next-hop 0.0.0.0, tas ir, vietējie vai agregētie maršruti. Šiem maršrutiem automātiski pēc komandas network ievadīšanas tiek piešķirts Weight parametrs, kas ir maksimālais — 32678:
Router#show bgp BGP tabulas versija ir 2, vietējā maršrutizatora ID ir 9.9.9.9 Statusa kodi: s apspiests, d dampingots, h vēsture, * derīgs, > labākais, i - iekšējais, r RIB-kļūda, S Novecojis, m multipath, b rezerves ceļš, f RT-Filtrs, x labākais-ārējais, a papildu-ceļš, c RIB-saspiests, Izcelsmes kodi: i - IGP, e - EGP, ? - nepilnīgs RPKI validācijas kodi: V derīgs, I nederīgs, N Netika atrasts Tīkla adrese Nākamais solis Metriķis LocPrf Svars Ceļš *> 9.9.9.0/24 0.0.0.0 0 32768 i - Īsākais ceļš caur AS. Tiek izvēlēts vissīkākais parametra AS_Path. Jo mazāk AS tiek izmantots maršrutā, jo labāks tas ir. Apskatīsim maršrutu uz 9.9.9.0/24 Router10:
Router10#show bgp BGP tabulas versija ir 2, vietējais maršrutētāja ID ir 6.6.6.6 Statusa kodi: s – nomākts, d – mehānisks, h – vēsture, * – derīgs, > – labākais, i – iekšējs, r RIB-kļūda, S novecojis, m daudzceļš, b rezerves ceļš, f RT-Filtrs, x labākais-ārējais, a papildu-ceļš, c RIB-saspiests, Izcelsmes kodi: i – IGP, e – EGP, ? – nepilnīgs RPKI validācijas kodi: V derīgs, I nederīgs, N neatrasts Tīkls Nākamais Lēciens Metri LocPrf Svars Ceļš * 9.9.9.0/24 192.168.107.7 0 123 45 i * >i 192.168.112.12 0 100 0 45 iKā redzat, Router10 izvēlējās ceļu caur 192.168.112.12, jo šim ceļam parametrs AS_Path satur tikai 45, savukārt citā gadījumā 123 un 45. Tas ir intuitīvi skaidrs.
- Nākošais parameters ir Izcelsme. IGP (maršruts iegūts ar BGP palīdzību) ir labāks nekā EGP (maršruts iegūts ar BGP priekšteci, kas pašlaik netiek izmantots), bet EGP ir labāks nekā Nepilnīgs? (iegūts kādā citā veidā, piemēram, redistribūcijas ceļā).
- Nākošais parameters ir MED. Mums bija Wieght, kas darbojās tikai lokāli uz maršrutētāja. Bija Local Preference, kas darbojās tikai viena autonomā sistēmā. Kā jau viegli var nojaust, MED ir parametrs, kas tiks pārsūtīts starp autonomām sistēmām. Ļoti labs. par šo parametru.
Vairāk atribūtu netiks izmantoti, bet ja diviem ceļiem tie ir vienādi, tiek izmantoti šādi noteikumi:
- Izvēlēt ceļu caur tuvāko IGP kaimiņu.
- Izvēlēt visvecāko maršrutu eBGP ceļam.
- Izvēlēt ceļu caur kaimiņu ar mazāko BGP maršrutētāja ID.
- Izvēlēt ceļu caur kaimiņu ar mazāko IP adresi.
Tagad aplūkosim BGP konverģences jautājumu.
Paskatīsimies, kas notiks, ja pieņemsim, ka Router6 zaudē maršrutu 9.9.9.0/24 caur Router9. Atvienosim interfeisu Gi0/1 uz Router6, kas tūlīt sapratīs, ka BGP sesija ar Router8 ir pārtraukta un kaimiņš ir pazudis, tādējādi arī maršruts, ko no tā ir iegūts, vairs nav derīgs. Router6 nekavējoties nosūta Update ziņojumus, kuros norāda tīklu 9.9.9.0/24 laukā Withdrawn Routes. Tiklīdz Router5 saņems šādu ziņojumu, tas nosūtīs to uz Router7. Bet, tā kā Router7 ir maršruts caur Router10, tad atbildot nekavējoties nosūtīs Update ar jauno maršrutu. Ja kaimiņa kritumu nevar noteikt pēc interfeisa stāvokļa, tad būs jāpagaida, kad darbojas Hold Timer.
Konfederācija.
Ja, ja atceraties, mēs runājām par to, ka bieži nākas izmantot pilnīgi savienotu topoloģiju. Ar lielu maršrutētāju skaitu vienā AS tas var radīt lielas problēmas. Lai to novērstu, nepieciešams izmantot konfederācijas. Viena AS tiek sadalīta vairākās apakš-AS, kas ļauj tām darboties bez nepieciešamības pēc pilnīgi savienotas topoloģijas.
Šeit ir saite uz šo , bet konfigurācija GNS3.
Piemēram, izmantojot šādu topoloģiju, mums būtu jāizveido savienojums starp visiem maršrutētājiem AS 2345, bet, lietojot konfederāciju, mēs varam izveidot kaimiņattiecības tikai starp maršrutētājiem, kas ir tieši savienoti viens ar otru. Par to detalizēti parunāsim. Ja mums būtu tikai AS 2345, tad laForge saņemtu maršrutu no Picard , viņš stāstītu par to saviem maršrutētājiem Data un Worf, bet viņi nestāstītu par to maršrutētājam Crusher . Arī maršruti, kurus izplata pats maršrutētājs laForge, netiktu nodoti Crusher ne Worf-am, ne Data.
Būtu jāsagatavo Route-Reflector vai pilnīgi savienoti kaimiņattiecības. Sadalot vienu AS 2345 četrās apakš-AS (2,3,4,5) katram maršrutētājam, mēs beigās iegūstam citu darba loģiku. Viss ir lieliski aprakstīts .
Avoti:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Vietne
- Vietne .
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish