6 VLSM i CIDR


Dół formularza

CCNA Exploration - Protokoły i koncepcje routingu

6 VLSM i CIDR

6.0 Wprowadzenie do rozdziału

6.0.1 Wprowadzenie do rozdziału

Strona 1:

Przed 1981 rokiem w adresach IP tylko osiem pierwszych bitów reprezentowało sieć, co ograniczało liczbę sieci w Internecie, funkcjonującym wówczas pod nazwą ARPANET, do 256. I wcześnie stało się jasne, że w ten sposób szybko zabraknie przestrzeni adresowej.

W opublikowanym w 1981 roku dokumencie RFC 791 zmodyfikowano 32-bitowy adres IPv4, umożliwiając używanie trzech różnych klas, czyli rozmiarów sieci: klasa A, klasa B, klasa C. Adresy klasy A, które używały ośmiu bitów, na część adresu dotyczącą sieci, adresy klasy B, które używały 16 bitów, na część adresu dotyczącą sieci, adresy klasy C, które używały 24 bitów. Format ten upowszechnił się pod nazwą klasowego adresowania IP (ang. classful IP addressing).

Przez pewien czas adresowanie klasowe rozwiązywało problem z ograniczeniem do 256 sieci. Dziesięć lat później stało się jasne, że przestrzeń adresów IP szybko się kurczy. W odpowiedzi organizacja IETF (Internet Engineering Task Force) wprowadziła bezklasowy routing między domenami (CIDR), w którym do zachowywania przestrzeni adresowej wykorzystano maski podsieci o zmiennej długości (VLSM).

Dzięki wprowadzeniu CIDR i VLSM dostawcy Internetu (ISP) mogą przydzielać różne części jednej sieci klasowej różnym klientom. Równocześnie z tym przypisywaniem nieciągłych adresów (ang. discontiguous address assignment) przez ISP powstawały bezklasowe protokołów routingu. Dla porównania klasowe protokoły routingu zawsze podsumowują na granicy klasy, a w aktualizacjach routingu nie wysyłają maski podsieci. Bezklasowe protokoły routingu wysyłają w aktualizacjach routingu maski podsieci i nie muszą wykonywać podsumowania. Bezklasowe protokoły routingu omówione na tym kursie to RIPv2, EIGRP oraz OSPF.

Po wprowadzeniu VLSM i CIDR, administratorzy musieli zdobywać dodatkowe umiejętności w zakresie tworzenia podsieci. VLSM to po prostu dzielenie podsieci na kolejne podsieci. Podsieci mogą być dzielone na kolejne i tak dalej - o tym właśnie opowiada ten rozdział. Oprócz tworzenia podsieci możliwe stało się podsumowywanie dużego zbioru sieci klaso-wych do trasy agregowanej, czyli supersieci (ang. supernet). Rozdział ten zawiera także powtórkę z podsumowywania tras.

0x01 graphic

6.1 Adresowanie klasowe i bezklasowe

6.1.1 Klasowe adresowanie IP

Strona 1:

Kiedy w 1969 roku powołano do życia sieć ARPANET, nikt nie przewidywał przyszłości tego skromnego projektu badawczego. W roku 1989 sieć ARPANET została przekształcona w to, co nazywamy dzisiaj Internetem. W ciągu kolejnego dziesięciolecia liczba hostów w Internecie zwiększyła się wykładniczo od 159 tysięcy w październiku 1989 roku do ponad 72 milionów pod koniec tysiąclecia. W styczniu 2007 roku w Internecie było ponad 433 miliony hostów.

Bez wprowadzenia w 1993 roku notacji VLSM i CIDR (RFC 1519), translacji adresów sieciowych NAT (Network Address Translation) w 1994 roku (RFC 1631) i adresowania prywatnego (ang. private addressing) w 1996 roku (RFC 1918), 32-bitowa przestrzeń adresowa IPv4 byłaby już wyczerpana.


Strona 2:

Bity wyższego rzędu

Adresy IPv4 były początkowo przydzielane na podstawie klasy. W początkowej specyfikacji IPv4 (RFC 791), wydanej w 1981 roku autorzy utworzyli klasy, aby powstały trzy różne rozmiary sieci dla dużych, średnich i małych organizacji. W efekcie adresy klasy A, B i C zostały zdefiniowane za pomocą specyficznego formatu dotyczącego najbardziej znaczących bitów (ang. high-order bits). Najbardziej znaczące bity to te położone najbardziej na lewo w 32-bitowym adresie.

Jak pokazano na ilustracji:

Pozostałe adresy zostały zarezerwowane na komunikaty grupowe i przyszłe zastosowania. Adresy grupowe zaczynają się od trzech 1 i jednego bitu 0. Adresy grupowe są używane do identyfikowania grupy hostów. W ten sposób zredukowano przetwarzanie pakietów przez hosty, zwłaszcza na nośnikach rozgłoszeniowych. Na tym kursie wyjaśniono, że protokoły routingu RIPv2, EIGRP i OSPF używają wyznaczonych adresów grupowych.

Adresy IP, które rozpoczynają się czterema bitami 1, są zarezerwowane na przyszłe zastosowania.


Strona 3:

Struktura klasowego adresowania IPv4

Bity sieci i bity hosta określono w dokumencie RFC 790 (wydanym wraz z RFC 791). Określone w nim sieci klasy A używały pierwszego oktetu do przypisania sieci, co przekładało się na klasową maskę podsieci w postaci 255.0.0.0. Ponieważ w pierwszym oktecie było tylko siedem bitów znaczących (pamiętajmy, że pierwszy bit ma zawsze wartość 0), dawało to w sumie 2^7, czyli 128 sieci.

Dzięki 24 bitom w części hosta każdy adres klasy A mógł potencjalnie pomieścić ponad 16 milionów adresów indywidualnych hostów. Przed wprowadzeniem CIDR i VLSM organizacjom przydzielano cały adres sieci klasowej. Co jedna organizacja miała zrobić z 16 milionami adresów? To pytanie wyraźnie pokazuje rażące marnotrawienie przestrzeni adresowej, które miało miejsce w pierwszych dniach Internetu, kiedy firmom przyznawano adresy klasy A. Niektóre firmy i organizacje rządowe nadal mają adresy klasy A. Na przykład General Electrics ma 3.0.0.0/8, Apple Computer - 17.0.0.0/8, a poczta USA - 56.0.0.0/8. (Na końcu tego podrozdziału znajduje się łącze "Internet Protocol v4 Address Space" do spisu wszystkich przydziałów IANA.)

Klasa B nie była o wiele lepsza. Dokument RFC 790 przewidywał przeznaczenie dwóch pierwszych oktetów na sieć. Przy dwóch pierwszych bitach ustawionych już na 1 i 0, w dwóch pierwszych oktetach pozostawało 14 bitów na przypisywanie sieci, co dawało w sumie 16 384 adresów sieciowych klasy B. Ponieważ każdy adres klasy B zawierał w części hosta 16 bitów, dawało to kontrolę nad 65 534 adresami. (Jak pamiętamy, dwa z nich zostały zarezerwowane jako adres sieci i rozgłoszeniowy.) Tylko największe organizacje i rządy mogły przewidywać, że kiedykolwiek zostanie wykorzystanych 65 tysięcy adresów. Podobnie jak w przypadku klasy A, przestrzeń adresowa klasy B

marnowała się.

Co gorsza, adresy klasy C często były niewystarczające! W dokumencie RFC 790 na część adresu dotyczącą sieci przewidziano trzy pierwsze oktety. Przy trzech pierwszych bitach ustawionych na 1, 1 i 0 pozostało tylko 21 bitów na przypisanie sieci dla ponad dwóch milionów sieci klasy C. Ale każda sieć klasy C miała tylko 8 bitów w części hosta, co oznaczało 254 możliwe adresy hostów.


6.1.2 Klasowy protokół routingu

Strona 1:

Przykład klasowych aktualizacji routingu

Używanie klasowych adresów IP oznaczało, że maskę podsieci adresu sieciowego można było ustalić na podstawie wartości pierwszego oktetu czy też, precyzyjniej ujmując, trzech pierwszych bitów adresu. Protokoły routingu takie jak RIPv1 musiały jedynie ogłaszać adres sieciowy znanych tras i nie musiały umieszczać maski podsieci w aktualizacji routingu. A to dlatego, że router odbierający aktualizację routingu mógł ustalić maskę podsieci, po prostu badając wartość pierwszego oktetu w adresie sieciowym albo stosując maskę swojego interfejsu odbierającego. Maska podsieci była bezpośrednio związana z adresem sieciowym.

Kliknij Aktualizację R1 do R2 na ilustracji.

W przykładzie, router R1 wie, że podsieć 172.16.1.0 należy do tej samej dużej sieci klasowej co interfejs wyjściowy. Dlatego też wysyła do routera R2 aktualizację RIP zawierającą podsieć 172.16.1.0. Kiedy R2 odbiera aktualizację, stosuje maskę podsieci interfejsu odbierającego (/24), ponieważ aktualizacja należy do tej samej dużej sieci co ten interfejs. Router R2 umieszcza w swojej tablicy routingu sieć 172.16.1.0 z maską /24.

Kliknij Aktualizację R2 do R3 na ilustracji.

Jednak wysyłając aktualizacje do routera R3, router R2 podsumowuje podsieci 172.16.1.0/24, 172.16.2.0/24 i 172.16.3.0/24 do jednej dużej sieci klasowej 172.16.0.0. Ponieważ router R3 nie posiada informacji o podsieciach będących częścią adresu 172.16.0.0, zastosuje on domyślną 16 bitową maskę sieci klasy B (/16).


6.1.3 Bezklasowe adresowanie IP

Strona 1:

Przechodzenie na adresowanie bezklasowe

W 1992 roku, członkowie IETF mieli poważne obawy związane z wykładniczym rozrostem Internetu i ograniczoną skalowalnością internetowych tablic routingu. Przejmowali się również ostatecznym wyczerpaniem 32-bitowej przestrzeni adresowej IPv4. Wykorzystanie przestrzeni adresowej klasy B postępowało w takim tempie, że w ciągu dwóch lat miało zabraknąć dostępnych adresów klasy B (RFC 1519). Przyczyną tak szybkiego wykorzystywania przestrzeni adresowej było to, że każda organizacja, która zażądała i uzyskała zgodę na adres IP otrzymywała cały adres sieci klasowej - albo klasy B z 65 534 adresami hostów, albo klasy C z 254 adresami hostów. Jedną z fundamentalnych przyczyn tego problemu był brak elastyczności. Nie istniała żadna klasa dla średnich organizacji, które potrzebowały kilku tysięcy, ale nie aż 65 tysięcy adresów IP.

W 1993 roku organizacja IETF wprowadziła bezklasowy routing między domenami (CIDR) (RFC 1517). CIDR umożliwiał:

Dla routerów wykorzystujących CIDR klasa adresu nie ma znaczenia. Część adresu przeznaczona na sieć jest ustalana na podstawie maski podsieci, zwanej również prefiksem sieci (ang. network prefix), albo długością prefiksu (/8, /19 i tak dalej). Adresu sieci nie ustala się już na podstawie klasy adresu.

Dostawcy ISP mogą teraz efektywniej alokować przestrzeń adresową, używając do-wolnej długości prefiksu od /8 w górę (/8, /9, /10 i tak dalej). Nie są już ograniczeni do masek podsieci /8, /16 i /24. Bloki adresów IP można przypisywać do sieci na podstawie wymagań klienta w przedziale od kilku do setek czy nawet tysięcy hostów.


Strona 2:

CIDR i podsumowanie tras

CIDR używa masek podsieci o zmiennej długości (VLSM), aby alokować adresy IP do podsieci zgodnie z indywidualnymi potrzebami, a nie klasą. Dzięki temu typowi alokacji, granica między hostem a siecią może występować w dowolnym bicie adresu. Sieci można dzielić na coraz mniejsze podsieci.

Tak jak na początku lat 90. Internet rósł wykładniczo, tak samo rosły rozmiary tablic routingu tworzone przez internetowe routery zgodnie z zasadami klasowego adresowania IP. CIDR umożliwiał agregację prefiksów, którą znamy już jako podsumowanie tras. Jak pamiętamy z rozdziału 2 „Routing statyczny”, dla wielu sieci można utworzyć jedną trasę statyczną. Internetowe tablice routingu mogły od tego momentu korzystać z tego samego typu agregacji tras. Możliwość sumaryzowania tras przyczyniła się do redukcji rozmiarów internetowych tablic routingu.

Na rysunku widzimy, że ISP 1 ma czterech klientów, a każdy z nich posiada inny rozmiar przestrzeni adresowej IP. Jednak całą przestrzeń adresową klientów można podsumować w jedno ogłoszenie wysyłane do ISP 2. Sumaryczna, czyli zagregowana, trasa 192.168.0.0/20 zawiera wszystkie sieci należące do klientów A, B, C i D. Trasa tego typu jest nazywana supersiecią. Supersieć podsumowuje wiele adresów sieciowych z maską mniejszą niż maska sieciowa.

Propagowanie VLSM i supersieci wymaga bezklasowego protokołu routingu, ponieważ maski podsieci nie można już ustalić na podstawie wartości pierwszego oktetu. Maska podsieci musi być teraz dołączona do adresu sieciowego. Bezklasowe protokoły routingu wysyłają w aktualizacjach routingu adres sieciowy wraz z maską podsieci.

0x01 graphic

6.1.4 Bezklasowy protokół routingu

Strona 1:

Do bezklasowych protokołów routingu należą RIPv2, EIGRP, OSPF, IS-IS oraz BGP. Protokoły te w swoich aktualizacjach tras oprócz adresów sieciowych umieszczają również maskę podsieci. Bezklasowe protokoły routingu są koniecznością, kiedy maski nie można ustalić na podstawie wartości pierwszego oktetu.

Na przykład sieci 172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16 i 172.19.0.0/16 można podsumować jako 172.16.0.0/14, czyli supersieć.

Jeśli router R2 wyśle trasę sumaryczną 172.16.0.0 bez maski /14, R3 wie tylko, że należy zastosować domyślną maskę klasową /16. W scenariuszu z klasowym protokołem routingu R3 nie wie o istnieniu sieci 172.17.0.0/16, 172.18.0.0/16 i 172.19.0.0/16..

Uwaga: Używając klasowego protokołu routingu, router R2 może wysłać te pojedyncze sieci bez podsumowania, ale wówczas traci się zalety podsumowania.

Klasowe protokoły routingu nie mogą wysyłać informacji o supersieci, ponieważ router odbierający zastosuje domyślną maskę klasową do adresu sieciowego w aktualizacji routingu. Gdyby w tej przykładowej topologii był klasowy protokół routingu, router R3 zainstalowałby w tablicy routingu jedynie 172.16.0.0/16.

Uwaga: Kiedy w tablicy routingu znajdzie się supersieć, na przykład jako trasa statyczna, klasowy protokół routingu nie będzie umieszczał tej trasy w swoich aktualizacjach routingu.

W przypadku używania bezklasowego protokołu routingu router R2 ogłosi routerowi R3 sieć 172.16.0.0 wraz z maską /14. Router R3 będzie wówczas potrafił zainstalować w swojej tablicy routingu supersieć 172.16.0.0/14, co da mu możliwość dotarcia do sieci 172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16 i 172.19.0.0/16.

6.2 VLSM

6.2.1 VLSM w działaniu

Strona 1:

W poprzednim kursie opisano, w jaki sposób technika Variable Length Subnet Masking (VLSM) pozwala używać różnych masek dla każdej podsieci. Po podziale adresu sieciowego na podsieci te ostatnie można podzielić na kolejne podsieci. Jak pamiętamy, VLSM to po prostu dzielenie podsieci na kolejne podsieci. VLSM można uznać za podpodsieci.

Na ilustracji widzimy sieć 10.0.0.0/8, która została podzielona na podsieci za pomocą maski podsieci /16, co daje możliwość utworzenia 256 sieci.

10.0.0.0/16
10.1.0.0/16
10.2.0.0/16
.
.
.
10.255.0.0/16

Każdą z tych podsieci /16 można podzielić na jeszcze mniejsze sieci. Na przykład na ilustracji podsieć 10.1.0.0/16 została podzielona na podsieci za pomocą maski /24.

10.1.1.0/24
10.1.2.0/24
10.1.3.0/24
.
.
.
10.1.255.0/24

Podsieć 10.2.0.0/16 została podzielona na kolejne podsieci z maską /24 Podsieć 10.3.0.0/16 została podzielona z maską /28, a podsieć 10.4.0.0/16 z maską /20.

Adresy indywidualnych hostów są przydzielane z adresów podpodsieci. Na przykład na rysunku widzimy, że podsieć 10.1.0.0/16 została podzielona na podsieci /24. Adres 10.1.4.10 staje się tym samym członkiem bardziej konkretnej podsieci 10.1.4.0/24.


6.2.2 VLSM a adresy IP

Strona 1:

Podsieci VLSM można też przedstawić, wypisując na liście każdą podsieć i jej podsieci. Na ilustracji początkową przestrzenią adresową jest sieć 10.0.0.0/8. W pierwszej rundzie tworzenia podsieci sieć 10.0.0.0/8 została podzielona na podsieci z maską /16. Wiemy już, że pożyczenie ośmiu bitów (od /8 do /16) tworzy 256 podsieci. W routingu klasowym jest to właśnie granica możliwości. Można wybrać tylko jedną maskę dla wszystkich podsieci. Używając VLSM i routingu bezklasowego, mamy znacznie większą swobodę tworzenia dodatkowych adresów sieciowych i używania wymaganej w danej sytuacji maski.

Kliknij 10.1.0.0/16 na ilustracji.

Dla podsieci 10.1.0.0/16 pożyczamy osiem bitów więcej, aby utworzyć 256 podsieci z maską /24. Maska ta pozwala utworzyć 254 adresy hostów na podsieć. Podsieci od 10.1.0.0/24 do 10.1.255.0/24 są podsieciami podsieci 10.1.0.0/16.

Kliknij 10.2.0.0/16 na ilustracji

Podsieć 10.2.0.0/16 została również podzielona na podsieci z maską /24. Podsieci od 10.2.0.0/24 do 10.2.255.0/24 są podsieciami podsieci 10.2.0.0/16.

Kliknij 10.3.0.0/16 na ilustracji

Podsieć 10.3.0.0/16 została podzielona na kolejne podsieci z maską /28. Ta maska umożliwia przyznanie 14 adresów hostów w każdej podsieci. Pożyczonych zostaje 12 bitów, co daje 4096 sieci od 10.3.0.0/28 do 10.3.255.240/28.

Kliknij 10.4.0.0/16 na ilustracji

Podsieć 10.4.0.0/16 zostaje podzielona na kolejne podsieci z maską /20. Ta maska pozwala przydzielić 4094 adresy hostów na podsieć. Pożyczone są cztery bity, co tworzy 16 podsieci od 10.4.0.0/20 do 10.4.240.0/20. Te podsieci /20 są na tyle duże, że można podzielić je na jeszcze mniejsze podsieci.

6.3 CIDR

6.3.1 Podsumowanie tras

Strona 1:

Jak już wiemy, podsumowanie tras, zwane również agregacją tras, jest procesem ogłaszania ciągłego (ang. contiguous) zbioru adresów jako pojedynczego adresu z mniej konkretną, krótszą maską podsieci. Pamiętajmy, że CIDR to forma podsumowania tras, stanowiąca synonim tworzenia supersieci (ang. supernetting).

Wiemy już, jak podsumowanie tras wykonują klasowe protokoły routingu takie jak RIPv1. RIPv1 podsumowuje podsieci do pojedynczego adresu dużej sieci klasowej, kiedy wysyła aktualizację RIP1 z interfejsu należącego do innej dużej sieci. Na przykład RIPv1 podsumowuje podsieci 10.0.0.0/24 (od 10.0.0.0/24 do 10.255.255.0/24) do adresu 10.0.0.0/8.

CIDR ignoruje granice klas i pozwala na podsumowanie z maskami, które są mniejsze od domyślnej maski klasowej. Podsumowanie tego typu pozwala zredukować liczbę wpisów w aktualizacjach routingu i liczbę wpisów w lokalnych tablicach routingu. Zmniejsza również wykorzystanie pasma na wymianę aktualizacji routingu, co w efekcie daje szybsze przeszukiwanie tablicy routingu.

Na ilustracji widzimy jedną trasę statyczną z adresem 172.16.0.0 i maską 255.248.0.0 podsumowującą wszystkie sieci klasowe od 172.16.0.0/16 do 172.23.0.0/16. Mimo że na ilustracji nie widzimy sieci 172.22.0.0/16 i 172.23.0.0/16, one również są włączone do trasy sumarycznej. Zwróćmy uwagę, że maska /13 (255.248.0.0) jest mniejsza od domyślnej maski klasy /16 (255.255.0.0).

Uwaga: Należy zapamiętać, że supersieć to zawsze trasa sumaryczna, ale trasa sumaryczna nie zawsze jest supersiecią.

W tablicy routingu może się znajdować zarówno wpis odnoszący się do konkretnej trasy, jak i wpis dla trasy sumarycznej, obejmujący tę samą sieć. Załóżmy, że router X ma konkretną trasę do 172.22.0.0 przez interfejs Serial 0/0/1 i trasę sumaryczną 172.16.0.0/14 przez interfejs Serial 0/0/0. Pakiety z adresem IP 172.22.n.n pasują do obu wpisów tras. Te pakiety zostaną wysłane do 172.22.0.0 z interfejsu Serial 0/0/1, ponieważ nie ma bliższego dopasowania 16 bitów niż 14 bitów sumarycznej trasy 172.16.0.0/14.

0x01 graphic


6.3.2 Obliczanie podsumowania tras

Strona 1:

Obliczanie podsumowania tras i supersieci jest identyczne jak proces omówiony w rozdziale 2. Dlatego też poniższy przykład przedstawiono jako małą powtórkę.

Podsumowanie sieci do jednego adresu sieciowego można wykonać w trzech krokach. Załóżmy istnienie czterech poniższych sieci:

Kliknij Krok 1 na ilustracji.

W kroku pierwszym wypisz sieci w formacie dwójkowym. Na rysunku widzimy wszystkie cztery sieci w formacie binarnym.

Kliknij Krok 2 na ilustracji.

W kroku drugim policz położone najbardziej na lewo pasujące bity, aby ustalić maskę dla trasy sumarycznej. Na rysunku widzimy, że zgadza się pierwszych 14 bitów. I to jest właśnie prefiks, czyli maska podsieci, dla trasy sumarycznej /14, czyli 255.252.0.0.

Kliknij Krok 3 na ilustracji.

W kroku trzecim skopiuj pasujące bity i dodaj bity zerowe, aby ustalić sumaryczny adres sieciowy. Na rysunku widzimy, że pasujące bity z zerami na końcu dają w efekcie sieciowy adres 172.20.0.0. Cztery sieci: 172.20.0.0/16, 172.21.0.0/16, 172.22.0.0/16 i 172.23.0.0/16, można podsumować do jednego adresu sieciowego i prefiksu 172.20.0.0/14.

Ćwiczenia w kolejnej sekcji dostarczają okazji do przećwiczenia projektowania i rozwiązywania problemów ze schematami adresacji VLSM. Przećwiczysz również tworzenie i rozwiązywanie problemów związanych z podsumowaniem tras.

0x01 graphic

6.5 Podsumowanie

6.5.1 Podsumowanie i powtórzenie

Strona 1:

Podsumowanie

Bezklasowy routing między domenami (CIDR) wprowadzono w 1993 roku. Zastąpił składnię IP poprzedniej generacji, czyli sieci klasowe. CIDR umożliwił efektywniejsze wykorzystanie przestrzeni adresowej IPv4 i agregację prefiksów, co zostało nazwane podsumowaniem tras albo tworzeniem supersieci.

Po wprowadzeniu CIDR klasy adresów (klasa A, B i C) straciły znaczenia. Adres sieciowy nie jest już ustalany na podstawie wartości pierwszego oktetu, ale na podstawie długości prefiksu (maski podsieci). Przestrzeń adresową i liczbę hostów w sieci można określać za pomocą konkretnego prefiksu zależnie od liczby hostów wymaganych w tej sieci.

CIDR umożliwia tworzenie supersieci. Supersieć to grupa dużych adresów sieciowych zsumowanych jako jeden adres sieciowy z maską mniejszą niż domyślna maska klasy.

CIDR wykorzystuje maski podsieci o zmiennej długości (VLSM), aby alokować adresy IP dla podsieci zgodnie z wymaganiami, a nie na podstawie klasy. VLSM pozwala na dzielenie podsieci na kolejne podsieci, a tych na następne. Krótko mówiąc, VLSM to dzielenie podsieci na podsieci.

Propagowanie supersieci CIDR lub podsieci VLSM wymaga bezklasowego protokołu routingu. Bezklasowy protokół routingu w aktualizacjach routingu oprócz adresu sieciowego wysyła też maskę podsieci.

Trasę sumaryczną i maskę podsieci dla grupy sieci można ustalić w trzech prostych krokach. Pierwszy krok to wypisanie sieci w formacie dwójkowym. Drugi krok to policzenie w adresach pasujących bitów położonych najbardziej na lewo. W ten sposób otrzymujemy długość prefiksu, czyli maskę podsieci dla trasy sumarycznej. Trzeci krok polega na skopiowaniu pasujących bitów i dodaniu bitów zerowych do reszty adresu, aby ustalić sumaryczny adres sieciowy. Sumarycznego adresu sieciowego i maski podsieci można od tego momentu używać jako trasy sumarycznej dla tej grupy sieci. Trasy sumaryczne mogą być używane zarówno przez trasy statyczne, jak i bezklasowe protokoły routingu. Klasowe protokoły routingu potrafią sumaryzować trasy tylko do domyślnej maski klasy.

Bezklasowe protokoły routingu oraz ich możliwości obsługi supersieci CIDR, VLSM i sieci nieciągłych są omówione w kolejnych rozdziałach.


Strona 4:

Aby nauczyć się więcej

RFC 1519 Classless Inter-Domain Routing (CIDR)

RFC (Request For Comments) to seria dokumentów wysyłanych do IETF (Internet Engineering Task Force) w celu zaproponowania internetowego standardu albo przekazania nowych koncepcji, informacji, a czasami także żartów. RFC 1519 to dokument RFC opisujący Classless Inter-Domain Routing (CIDR).

Dokumenty RFC można znaleźć na kilku portalach, w tym na http://www.ietf.org. Aby dowiedzieć się więcej na temat wprowadzenia CIDR do internetowej społeczności, warto przeczytać całość albo fragmenty dokumentu RFC 1519.

Szkieletowe routery internetowe

W sekcji „Więcej informacji” rozdziału 3 „Wprowadzenie do protokołów routingu dynamicznego” wchodziliśmy na serwery tras, aby wyświetlać trasy BGP w Internecie. Jedną z takich stron jest www.traceroute.org.

Wejdź na jeden z serwerów tras i wydając polecenie show ip route, wyświetl prawdziwą tablicę routingu internetowego routera Zobacz, ile tras znajduje się na szkieletowym routerze internetowym. W marcu 2007 roku było ponad 200 tysięcy tras. Wiele z nich to trasy sumaryczne i supersieci. Aby zobaczyć jedną z tych supersieci, wydaj polecenie show ip route 207.62.187.0.

CAIDA

Interesującym serwisem jest CAIDA, Cooperative Association for Internet Data Analysis, www.caida.org. CAIDA „dostarcza narzędzia i analizy promujące inżynierię i utrzymanie potężnej, skalowalnej globalnej infrastruktury internetowej”. Jednym ze sponsorów CAIDA jest Cisco Systems. Mimo że większość tych informacji może być dla Czytelników niezrozumiała, wiele koncepcji i terminów już zostało omówionych w tej książce.

5



Wyszukiwarka

Podobne podstrony:
9 2 1 5 Packet Tracer ?signing and Implementing a VLSM?dressing Scheme Instruct
9 2 1 4 Lab ?signing and Implementing a VLSM?dressing Scheme
CIDR
Lab 6, 9.2.1.5 Packet Tracer - Designing and Implementing a VLSM Addressing Scheme Instruct
CIDR

więcej podobnych podstron