Szabványos eljárások alhálózatok ip

Internet szabvány Alhálózatok eljárási

Standard eljárás megszervezése IP alhálózatok

Ez a dokumentum a szabványos protokoll az ARPA-internetes közösség. Amikor alhálózatok erősen ajánlott, hogy kövesse az itt leírt eljárások.

A dokumentum szabadon terjeszthető.

Ez a dokumentum alapul RFC-917 [1]. egy csomó ember, hogy vegyenek részt a fejlesztés a szabvány az itt leírt, és különösen szeretnénk elismerni a jelentős hozzájárulást J. Noel Chiappa, Chris Kent, és Tim Mann. Jelentős mértékben hozzájárul a fejlesztés a szabvány is készítettünk Zaw-Sing Su, Mike Karels és a munkacsoport GADS (Gateway Algoritmusok és adatszerkezetek Task Force).

A három szintű hierarchia hasznos a nagy szervezetek (például egyetemek vagy vállalatok, amelyek a hálózatok több épületből), ahol több LAN is szerepel a „helyi”. Ilyen esetekben célszerű kezelni az egyes LAN-alhálózati.

Számos oka van annak, amiért egy IP-hálózaton is használható több fizikai hálózatok:

Különböző topológiák - gyakran (különösen a kutatási szervezetek) több különböző típusú LAN (például Ethernet, és a hálózat gyűrű topológia 3) lehet használni a hálózatban.

Rejlő technológia határait - a legtöbb LAN topológia jellemzi bizonyos korlátai (elektromos paraméterek száma házigazdák a LAN, a vezeték teljes hossza). Használata alhálózatok lehetővé teszi, hogy egyszerűen leküzdeni ezeket a korlátozásokat (különösen korlátozó kábel hossza).

Telítettség hálózat - helyi hálózatok lehetnek olyan helyzetek, amikor egy kis csoportja a hosts hatékonyan sajátíthatja sávszélesség hálózati környezetben. Az általános megoldás az ilyen problémák a hálózati szegmentáció (hasító darabokra) a szervezet külön kábelezés.

A csatornák használatával „pont-pont” - néha „LAN” (például egyetemi campus hálózat) van osztva több részre (például egyetlen épületek LAN) köti össze a nagy teljesítményű „pont-pont”.

2 Információ ebben a szakasz részben elveszítették jelentősége ma alhálózatok gyakran diktálja nagyon különböző okok miatt. Amikor fordítására teljesen megőrizte az eredeti szöveget. Kb. Trans.

3 FDDI, Token Ring. Kb. Trans.

4 Lásd. Megjegyzés 1. megjegyzés. Trans.

Translation RFC 950

LAN elérhető. Ez a változat az úgynevezett explicit alhálózatok (explicit alhálózat).

Minden lehetőség megvan a maga előnyei és hátrányai. Az első kiviteli nincs szükség hozzáadása vagy módosítása protokollokat, de vezet elterjedése Internet routing táblák. Információ a belső szerkezete a hálózat elosztott mindenütt, bár nagyon kevés ember akar, és a legtöbb esetben nem használják. Bizonyos megvalósítási átjáró lehet a probléma a helyhiány az útválasztási táblázat, így ez a lehetőség a legjobb, hogy nem használja 5.

A harmadik opció az, hogy kifejezetten támogatja alhálózat. Ő is megvannak a hátrányai - különösen módosítani kell az IP-protokoll, amely maga után vonja a meglévők módosítása IP implementációk (ha azt tervezi, hogy használja őket alhálózatok). Ugyanakkor a szükséges változások viszonylag csekély, és a 6. lesz hatékonyan kezelni, ha teszik a probléma mellett, ez a lehetőség nem igényel semmilyen változás, biztosítva a kompatibilitást a meglévő állomások és hálózatok, amelyek nem oszthatók alhálózat.

Kiválasztása után egy adott kiviteli alakban, hogy a hosts kell használni a közegben, anélkül alhálózatok esnek egyik alhálózatok (lásd. RFC-917 [1]). Ez a megoldás hasznos lehet olyan esetekben, amikor nincs lehetőség kifejezetten támogatja alhálózat vagy előírják a fokozatos átmenet.

2. Szabványok alhálózatok

Tegyük fel, hogy egy olyan szervezet, amelynek IP-hálózaton egy nyilvántartási száma és azt tervezi, hogy megoszthatta alhálózatokra történő. Hogy ilyen esetekben meg kell tennie?

2. A területen fix hosszúságú. A számozás alhálózat használ rögzített számú bitet (például 8).

4. A mező a fix hosszúságú önálló kódoló (Self-kódoló rögzített szélességű mező). Alhálózatok használt számozás egy előre meghatározott bitszám.

5. maszkolás bit. bitmask azonosítására használt hálózati bitek számát (címmaszkot).

A kidolgozása és megvalósítása standard paraméterek alhálózatok önálló kódoló kódolási rendszert kell rögzített és változatlan marad az egész interneten.

6 Jelenleg ez a probléma már megoldódott. Kb. Trans.

Tól számkiosztó dokumentum [9] 7:

Hasznos, hogy ezt az értelmezést, és az esetek használatát alhálózat. Ennek megfelelően az érték az összes nullát vagy egyest, nem kell használni a számozás a valós (fizikai) alhálózati. A fenti példában, 6-bites alhálózati szám mező lehetővé teszi a számok használatát 1-62 (0 és 63 alkalmazunk overhead) 8.

2.2. Változás programok a házigazdák, hogy támogassa alhálózatok

A legtöbb implementáció IP van egy kód, amely kezeli a kimenő adatcsomagok, és úgy dönt, hogy minden egyes datagram a fogadó hálózat, vagy elküldené a gateway (router).

Általában ez a darab a kód működik, mint ez:

IF ip_net_number (dg. Ip_dest) = ip_net_number (my_ip_addr) THEN

(Tálalás összeköttetéscsoportról, a kód bonyolultabbá válik, de az összefüggésben ezt a dokumentumot, nem számít).

Támogatására alhálózatok akarja menteni egy vagy több 32 bites érték, az úgynevezett maszkokat. Ebben bitmask set (1) bittel mezőinek megfelelő IP-hálózati számot és a kiegészítő biteket alhálózati mezőben.

A megfelelő kód így fog kinézni:

IF bitwise_and (dg.ip_dest, my_ip_mask) = bitwise_and (my_ip_addr, my_ip_mask) THEN

send_dg_locally (dg, gateway_to (bitwise_and (dg.ip_dest, my_ip_mask)))

Rész kifejezések körülmények között lehet előre kiszámítani (ismert).

Lehet, hogy módosítania kell gateway_to funkciót úgy, hogy figyelembe veszi az alhálózati bitek számát, amikor összehasonlítást tenni.

Támogatására házigazdák több (hálózati interfészek - ca. Perevi ..) kód, amely lehet változtatni, hogy az értékek és my_ip_addr my_ip_mask tartjuk minden felületen. Vizsgálati feltételek kell végezni minden egyes felület ilyen házigazdák.

8 Megjegyzendő, hogy ezek a korlátozások nem vonatkoznak a hálózatok, amelyek nem oszthatók alhálózat.

Translation RFC 950

A hardver információ tartalmazza a rendelkezésére álló információk a gazda nélküli hálózati kapcsolat (izolált) - ez az információ szerepel a programkód (befordított) vagy (lehetőleg) tárolt lemez fájl. Azonban egyik ilyen lehetőség nem alkalmas az esetben lemeznélküli munkaállomások letöltött LAN-on keresztül.

ICMP -. Címmaszk Request (maszk kérésre) és címmaszk válasz (a válasz a kérésre maszk), egy hasonló üzenetet Information Request (információkérés) és az Információs Válasz (kérésére tájékoztatást ezen üzenet típusok leírása a következő (Annex I. üzenetek ICMP Cím maszk).

Mivel minden egyes LAN címmaszk válasz üzenet tartalmazhat csak egy értéket, akkor nem szükséges, hogy ellenőrizze a kérés teljesítése választ. Még ha kapott válasz több átjárót, az adatokat minden kommunikációs ugyanaz lesz. Azt feltételezik, hogy hosts újraindul ritkán, így a több broadcast üzenetek, hogy meghatározzák a maszk elég kicsi.

Ha a gazda van kötve több LAN, meg tudja határozni a maszkot az egyes al hálózathoz.

Lehet olyan helyzet, amikor a gazda nem tudja meghatározni a maszkot, többszöri kísérlet után sem. Ez akkor fordulhat elő három esetben:

1. A helyi hálózati különítjük el minden más hálózatra.

3. Minden átjárók LAN (ideiglenesen) elromlott (le).

Összefoglalva, azt látjuk, hogy a gép nem köteles felhasználni az ICMP protokoll határozza meg a maszk - Host paramétereket lehet tárolni nem-felejtő memória.

Melléklet I. üzenetek ICMP Address Mask

Címmaszk kérése és címmaszk válasz

AM1 lekérdezések; ICMP AM2 válaszokat.

0 - lekérdezések;

0 - visszajelzést.

Ellenőrző összeg (ellenőrző)

Az ellenőrző összeg a 16-bites egy komplemens mezőket az ICMP üzenet kezdve az ICMP típus. Kiszámításakor az ellenőrző mező értékét feltételezzük, hogy 0-ellenőrző algoritmust az ellenőrző a jövőben ez megváltoztatható.

Azonosítók kimutatására használják közötti levelezés kéréseket és válaszokat. Ez a mező egy értéke nulla.

Sorszám (sorszám)

A sorszám AJ meghatározó közötti levelezés kérés és válasz. Field lehet nullára.

32 bites maszk értékét.

AM1 típusú csomagok is kapott egy átjáró vagy a házigazdák, és a csomag típusát AM2 - átjárók vagy hosts átjáróként.

Függelék II. példák

1. osztályú hálózat

III. szójegyzék

Hub, összekötő két vagy több hálózat, nem tesz különbséget az adminisztratív (logikai), de amelyek különböző fizikai alhálózatok és automatikusan továbbítja adatcsomagok hálózatok közötti, ha szükséges. Más szolgáltatók létezésének a híd csak nem tudom. Néha használják utal 9 hidak távú program repeater (repeater szoftver).

Gateway - az átjáró (útválasztó)

A csomópont összekötő két vagy több közigazgatási (logikusan) különböző hálózatokat és / vagy alhálózati és előre datagramokat közöttük.

Host Field - fogadó területén

A több, egymással összekapcsolt IP hálózatokban.

Egy IP-hálózat, amely lehet egyetlen egység vagy állhat több alhálózat.

Hálózati szám - hálózati szám

9. Jelenleg a kifejezés elavult, és szinte soha nem használt. Kb. Trans.

Alhálózati Field - alhálózati területén

Alhálózati száma - alhálózati számot

Azonosító szám az alhálózati egy hálózaton belül.

Függelék IV. dedikált szoba

Mivel a paramétereket használt protokollok támogatása alhálózatok, hogy kiemelt jelentőségét hangsúlyozta. Ezeket az értékeket használjuk csak ICMP protokoll [5].

ICMP üzenet típusa (típusú üzenetek)

magyar fordítás

BiLiM Systems Ltd.

194.354, K-354, P / 153 szervek. (812) 449-0770 [email protected]

A papír 13 részben felülvizsgált később RFC 1395, RFC 1497, RFC 1532-ben az RFC 1542-kb. Trans.