03.03. IP maršrutēšana

Pēdējais mainījis Administrator 2011-06-06 17:16

03.03. IP maršrutēšana

No mītnes viedokļa raugoties, IP maršrutēšana ir vienkārša. Ja #term("galamērķis", "destination") ir tieši piesaistīts mītnei (piemēram, ar #term("punkta-punkta", "point-to-point") #term("datu posmu", "link_1")) vai arī ir dalītā tīklā (piemēram, Ethernet'ā vai #term("marķieru aplī", "token_ring")), tad IP datagrammu sūta tiešu uz galapunktu. Citādi mītne sūta datagrammu uz noklusēto maršrutētāju (#term("vārteju","gateway")) kas nodrošina datagrammas nosūtīšanu uz galapunktu. Šis vienkāršais algoritms ir derīgs vairumam mītņu konfigurāciju.

Šajā nodaļā un 9.nodaļā mēs apskatīsim vispārīgāku gadījumu, kur IP slāni var konfigurēt, lai tas strādātu ne tikai kā mītnes dators, bet arī kā maršrutētājs. Vairums daudzlietotāju sistēmu, ieskaitot gandrīz jebkuru UNIX'a sistēmu, var konfigurēt kā maršrutētājus. Mēs varam norādīt vienotu maršrutēšanas algoritmu, ko var lietot gan mītnes, gan maršrutētāji. Principiālā atšķirība ir tā, ka mītne parasti nepārsūta datagrammas no viena interfeisa uz citu, turpretī maršrutētājs #term("pārsūta", "forward"). Mītne, kas satur #term("iegultu", "embedded") maršrutētāju, nekad nepārsūta datagrammu, kamēr vien to speciāli nekonfigurē to darīt. Par šo konfigurēšanu vairāk sk. 09.04.nodaļā.

Mūsu vispārīgajā algoritmā IP var saņemt datagrammu no TCP, UDP, ICMP vai IGMP (t.i. lokāli ģenerētu datagrammu) ko nosūtīt, vai arī tādu, kas saņemta no tīkla interfeisa (pārsūtāmu datagrammu). IP slāņa atmiņā ir maršrutēšanas tabula, ko tas pārlūko ikreiz, kad saņem kādu datagrammu. Ja datagramma tiek saņemta no tīkla interfeisa, IP vispirms pārbauda vai galapunkta IP adrese ir viena no mūsu pašu IP adresēm vai IP apraides adresēm. Ja tā ir, tad šo datagrammu piegādā protokola modulim, kuru norāda protokola lauks IP sākumposmā. Ja datagramma nav domāta šim IP slānim, tad izpildās viens no sekojošiem gadījumiem:

  1. ja IP slānis ir konfigurēts kā maršrutētājs, tad paketi pārsūta (t.i. apstrādā izejošo paketi tā, kā aprakstīts turmpāk);
  2. ja mītne nav maršrutētājs, svešo datagrammu klusām izdzēš.
Katrs ieraksts maršrutēšanas tabulā satur šādu informāciju:
  • Galamērķa IP adrese. Tā var būt vai nu pilna #term("mītnes adrese", "host_address") vai #term("tīkla adrese", "network_address"), kā to norāda karodziņa lauks (sk. zemāk) šim ierakstam. Mītnes adreses gadījumā ir norādīts nenulles mītnes ID (#picref("f_1_5.gif","1.5.attēls")), kas identificē vienu mītni, savukārt tīkla adreses gadījumā mītnes ID=0 un tā identificē visas mītnes dotajā tīklā (piemēram, Ethernet'ā, marķieru aplī).
  • IP adrese nākamā #term("lēkuma", "hop") maršrutētājam vai IP adrese tieši pievienotam tīklam. Nākamā lēkuma maršrutētājs ir sasniedzams ar tiešu tīkla savienojumu, kuram varam sūtīt datagrammas tālākai nosūtīšanai. Nākošā lēkuma maršrutētājs nav datagrammas galamērķis, bet tas saņem datagrammas un pārsūta tās galamērķim.
  • Karodziņi. Viens karodziņš norāda vai galamērķa IP adrese ir tīkla adrese vai mītnes adrese. Otrs karodziņš norāda, vai nākošā lēkuma maršrutētāja lauks tiešām ir nākamā lēkuma maršrutētājs vai arī tieši pievienota #term("saskarne", "interface"). (Katru no šiem karodziņiem aprakstīsim 09.02.nodaļā).
  • Norādi, kurš no tīkla interfeisiem nodarbosies ar datagrammas pārsūtīšanu augšminētajā kārtībā.
IP maršrutēšanu veic #term("lēkumu pa lēkumam", "hop_by_hop"). Kā var redzēt no maršrutēšanas tabulā glabātās informācijas, IP nezina pilnu ceļu uz jebkuru galamērķi (izņemot, protams, galamērķus, kuri tieši savienoti ar sūtītāju). Viss, ko nodrošina IP maršrutēšana, tā ir #term("nākamā lēkuma maršrutētāja", "next_hop_router") IP adrese, uz kurieni sūtīt datagrammu. Pieņemam, ka nākamā lēkuma maršrutētājs ir kaut kādā nozīmē "tuvāks" galamērķim, un arī ka nākamā lēkuma maršrutētājs ir tieši savienots ar sūtītāju.

IP maršrutēšana veic sekojošas darbības:

  1. Meklē maršrutēšanas tabulā ierakstu, kurš atbilst pilnai galamērķa IP adresei (t.i. sakrīt tīkla ID un mītnes ID). Ja tādu ierakstu atrod, tad sūta paketi uz norādīto nākamā lēkuma maršrutētāju vai uz tieši pievienotu saskarni (atkarībā no karodziņu lauka vērtības). Punkta-punkta datu posmus šeit var atrast, jo otrs datu posma gals ir otras mītnes pilna IP adrese.
  2. Meklē maršrutēšanas tabulā ierakstu, kurš atbilst tikai galamērķa tīkla ID. Ja to atrod, tad nosūta paketi uz norādīto nākamā lēkuma maršrutētāju vai uz tieši pievienoto saskarni (atkarībā no karodziņu lauka vērtības). Visas mītnes galamērķa tīklā var apstrādāt ar šo vienu maršrutēšanas tabulas ierakstu. Piemēram, visas mītnes vietējā Ethernet'ā tiek apstrādātas ar šāda tipa maršrutēšanas tabulas ierakstu. Tīkla pārbaudei ir jāņem vērā iespējamā apakštīkla maska, ko mēs aprakstām nākamajā nodaļā.
  3. Meklē maršrutēšanas tabulā ierakstu ar apzīmējumu "default" (noklusētais ieraksts). Ja tādu atrod, nosūta paketi uz šajā ierakstā norādīto nākamā lēkuma maršrutētāju.
Ja neviens no šiem soļiem nenostrādā, datagramma ir #term("nepiegādājama", "undeliverable"). Ja uz konkrētās mītnes ģenerējas nepiegādājama datagramma, tās avotam parasti nosūta kļūdu - #term("nesasniedzama mītne", "host_unreachable") vai #term("nesasniedzams tīkls", "network_unreachable").

Pilnu atbilstošās mītnes adresi meklē pirms atbilstošā tīkla ID. Tikai tad, ja abas pārbaudes neizdodas, izmanto noklusēto #term("maršrutu", "route"). Noklusētie maršruti kopā ar ICMP pārsūtīšanas ziņojumu, ko izsūta nākamā lēkuma maršrutētājs (ja mēs izvēlamies aplamu noklusēto maršrutu konkrētai datagrammai) ir tās pamatiezīmes, kas IP maršrutēšanas efektivitāti; pie tām atgriezīsimies 09.nodaļā.

Iespēja norādīt maršrutu uz visu tīklu (nevis maršrutu uz katru atsevišķo mītni) ir cita pamatīpašība IP maršrutēšanai. Tas atļauj maršrutētajiem Internetā, piemēram, izmantot maršrutēšanas tabulu ar dažiem tūkstošiem ierakstu nevis tabulu ar vairāk nekā miljonu ierakstu [t.i. atbilstoši visu datoru skaitam Internetā 90-to gadu sākumā K.A.]

Piemēri

Vispirms aplūkosim vienkāršu piemēru: mūsu mītnei bsdi jāsūta datagramma uz mītni sun. Abas mītnes atrodas tanī pašā Ethernet'ā (sk. #picref("f_COVER_1.gif", "attēlu uz iekšējā vāka")). 3.9.attēlā parādīta šīs datagrammas piegāde.

Kad IP slānis saņem datagrammu no kāda no augšējiem līmeņiem, tas meklē maršrutēšanas tabulu un konstatē, ka #term("galamērķa", "destination") IP adrese (140.252.13.33) ir tieši pieslēgtajā tīklā (Ethernet'ā 140.252.13.0). Atbilstošā tīkla adresi atrod maršrutēšanas tabulā. (Nākamajā nodaļā redzēsim, ka tīkla adreses apakštīklošanās dēļ šī Etherneta adrese patiesībā ir 140.252.13.32, bet tas neiespaido šo pārspriedumu par maršrutēšanu.) Datagrammu padod Ethernet'a iekārtas dzinim un to nosūta kā Ethernet'a kadru (#picref("f_2_1.gif","2.1.attēls")). Galamērķa adrese šai IP datagrammai ir sun'a IP adrese (140.252.13.33) un galamērķa adrese #term("datu posma slāņa", "data_link_layer") sākumposmā ir 48-bitu Ethernet'a adrese sun'a Ethernet'a saskarnei. Šo 48-bitu Ethernet'a adresi iegūst, izmantojot ARP, kā aprakstīts nākošajā nodaļā.

#pic("f_3_3.gif", "400")
3.3.attēls: IP datagrammas piegāde no bsdi uz sun

Aplūkosim citu piemēru: bsdi ir datagramma, ko sūtīt mītnei ftp.uu.net, kuras IP adrese ir 192.48.96.9. 3.4.attēls parāda datagrammas maršrutu cauri pirmajiem trim maršrutētājiem. Pirmkārt, bsdi pārmeklē savu maršrutēšanas tabulu, bet neatrod atbilstošu mītni vai atbilstošu tīkla ierakstu. Tādēļ bsdi izmanto noklusēto ierakstu, kas liek tam sūtīt datagrammu uz sun - nākošā lēkuma maršrutētāju. Kad datagramma pārceļo no bsdi uz sun, galamērķa IP adrese joprojām ir beigu mērķis (192.48.96.9) bet datu posma adrese ir 48-bitu Ethernet'a adrese atbilstoši sun'a Ethernet'a saskarnei. Salīdziniet šo datagrammu ar 3.3.attēlu, kur galamērķa IP adrese un galamērķa datu posma adrese norāda uz vienu un to pašu mītni (sun'u).

#pic("f_3_3.gif", "400")
~~3.4.attēls: Sākotnējais maršruts datagrammai no bsdi uz ftp.uu.net (192.48.96.9).

Kad sun's saņem datagrammu, tas saprot, ka datagrammas galamērķa IP adrese nav neviena no šī datora paša adresēm, un sun's ir konfigurēts darboties kā maršrutētājs, tādēļ tas pārsūta datagrammu. Maršrutēšanas tabulu šoreiz pārmeklē uz sun'a un atkal izmanto noklusēto ierakstu. Noklusētais ieraksts uz sun'a teic, ka datagrammas jāsūta uz nākamā #term("lēkuma", "hop") maršrutētāju netb, kura IP adrese ir 140.252.1.183. Datagrammu nosūta pa pukta-punkta SLIP datu posmu, izmantojot minimālo iekapsulēšanu, kā parādīts #picref("f_2_2.gif", "2.2.attēlā"). Šeit neparādām #term("datuposma", "data_link") slāņa sākumposmu, kā to darām Ethernet'u gadījumā, jo tāda SLIP'a datuposmam nav.

Kad netb saņem datagrammu, tā atkal izpilda tos pašus soļus, ko nupat uz sun'a: datagramma nav domāta vienai no šī datora paša IP adresēm un netb ir konfigurēts kā maršrutētājs, tādēļ datagrammu pārsūta. Izmanto noklusēto maršrutēšanas tabulas ierakstu, nosūtot datagrammu uz nākamā lēkuma maršrutēšanas vārteju (140.252.1.4). Dators netb izmanto ARP Ethernet'ā 140.252.1, lai iegūtu 48-bitu Ethernet'a adresi atbilstošu 140.252.1.4, un šī Ethernet'a adrese ir galamērķa adrese datuposma protokola ievadposmā.

gateway iet cauri tiem pašiem soļiem, ko arī iepriekšējie divi maršrutētāji, un tā noklusētais maršrutēšanas tabulas ieraksts norāda 140.252.104.2 kā nākamā lēkuma maršrutētāju. (Pārbaudīsim, ka šis ir nākamā lēkuma maršrutētājs, izmantojot traceroute - sk. #picref("f_8_4.gif", "8.4.attēlu").)

Daži būtiski novērojumi saistībā ar šo piemēru:

  1. Visas mītnes un maršrutētāji šajā piemērā izmantoja noklusēto maršrutu. Tiešām, vairums mītņu un daži maršrutētāji var izmantot noklusēto maršrutu visam, kam galamērķis neatrodas viņu lokālajos tīklos.
  2. Galamērķa IP adrese datagrammā nekad nemainās (08.05.nodaļā? redzēsim, ka tā var nebūt taisnība tad, ja lieto #term("maršrutēšanu no avota", "source_routing"), ko lieto reti). Visi maršrutēšanas lēmumi tiek pieņemti balstoties uz galapunkta adresi.
  3. Katram #term("datu posmam", "link_1") izmanto citu datu posma sākumposmu, un datuposma piegādes adrese (ja tā vispār norādīta) vienmēr ietver nākamā lēkuma datuposma adresi. Mūsu piemērā abi Ethernet'i #term("iekapsulēja", "encapsulate") datu posma sākumposmu, kurš satur nākamā lēkuma Ethernet'a adresi, bet SLIP'a datuposms to neiekapsulēja. Ethnernet'a adreses parasti iegūst ar ARP.
9.nodaļā aplūkosim IP maršrutēšanu atkal - pēc tam, kad būsim aprakstījuši ICMP. Analizēsim arī dažas maršrutēšanas tabulas un kā tās izmanto maršrutēšanas lēmumu pieņemšanā.
Tagi:
Izveidojis Kalvis Apsītis 2008-04-07 17:24
    
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 6.4 - Documentation