Kuten tuotannossa, henkilöstöä Ethernet-verkot päättää kaikesta. Ne toimivat säiliönä kaikille korkean tason paketeille, joten ymmärtääkseen toisiaan lähettäjän ja vastaanottajan on käytettävä samantyyppistä Ethernet-kehystä. Onneksi (tai valitettavasti) kehykset voivat olla vain neljässä eri muodossa, eivätkä myöskään kovin erilaisia ​​toisistaan. Lisäksi on olemassa vain kaksi peruskehysmuotoa (englanninkielisessä terminologiassa niitä kutsutaan "raakaiksi muodoiksi") - Ethernet_II ja Ethernet_802.3, ja ne eroavat vain yhden kentän tarkoituksesta.

Moderni tietokoneverkot ovat luonteeltaan heterogeenisiä, ja kolmannen kerroksen verkkoprotokollia käytetään usein erilaisia ​​tyyppejä Ethernet-kehykset. Näin ollen Novellin NetWare 3.x:n vanhemmissa versioissa oletusperusmuoto on Ethernet_802.3, ei IEEE-standardien tarjoama 802.2 tai SNAP, eikä kukaan muu käytä tätä muotoa. NetWare 4.x:n julkaisun myötä IPX/SPX-protokollat ​​käyttävät oletusarvoisesti standardinmukaisia ​​Ethernet_802.2-kehyksiä, ja kun IntranetWaresta suunnitellaan siirtymistä TCP/IP-protokolliin, tämä verkkokäyttöjärjestelmä toimii mahdollisesti oletuksena Ethernet_SNAP-kehysten kanssa, koska tämä on käytetty muoto uusimmat toteutukset TCP/IP. Yleisesti ottaen IPX/SPX-protokollapaketteja voidaan kuljettaa käyttäen minkä tahansa tyyppisiä kehyksiä, joten - ja koska Ethernet_802.3-tyyppiä käyttää yksinomaan Novell - tällä oppitunnilla tarkastellaan Ethernet-kehyksiä ensisijaisesti NetWare-verkkojen näkökulmasta. .

ETHERNET II

Vaikka kutsumme 802.3-standardia yleisesti nimellä Ethernet, tämä ei ole täysin oikein, koska jälkimmäinen nimi on Xeroxin, Intelin ja Digitalin tavaramerkki, joiden tekniikka toimi tämän erittäin suositun standardin prototyyppinä. Ethernet_II-muoto vastaa alkuperäistä Ethernet-kehysmuotoa ja sillä on seuraava muoto.

Kuten mikä tahansa kehys, Ethernet_II alkaa seitsemän tavun alustusosalla, joka koostuu vuorottelevista ykkösistä ja nollista, ja yhden tavun alkukehyksen erottimesta, jossa kaksi vähiten merkitsevää bittiä ovat 112 102:n sijaan, kuten muut johdanto- ja erotinbitit. . Tarkemmin sanottuna Ethernet_II:ssa johdantoa ei kuitenkaan ole jaettu itse johdanto-osaan ja alkukehyksen erottimeen - ja tämä on yksi eroista Ethernetin ja IEEE 802.3:n välillä, vaikkakin hyvin merkityksetön, voisi sanoa, scholastinen, varsinkin kun erittäin usein johdanto-osaa pidetään yleensä osana fyysistä mekanismia lähettävän ja vastaanottavan puolen synkronointia varten, ei osana kehystä (siksi emme kuvissa ilmoita johdanto-osaa ja alkuerotinta).

Itse kehyksen otsikko koostuu kuuden tavun kohdeosoitekentästä, kuusitavuisesta Source Address -kentästä ja kaksitavuisesta kehystyyppikentästä (katso kuva 1). Kun jokainen osoitetavu lähetetään, vähiten merkitsevät bitit (kauimpana oikealle) lähetetään ensin. Vastaanottajaosoitteessa ensimmäinen lähetetty bitti (tavun 0 bitti 0) ilmaisee osoitteen tyypin - normaali tai ryhmä. Siten kohdeosoitteen pariton ensimmäinen tavu tarkoittaa, että kehys on tarkoitettu asemaryhmälle. Eräs monilähetystyyppi on yleislähetys. Tässä tapauksessa kaikki vastaanottajan osoitteen bitit asetetaan arvoon 1.

Kuva 1.

Ethernet II- ja IEEE 802.3 -peruspaketteilla on sama rakenne. Niiden ero on 13. ja 14. tavun tarkoituksessa: protokollatyyppi- ja kehyksen pituuskentissä, vastaavasti. Jakaminen Eri kehysformaatit samassa Ethernet-segmentissä ovat mahdollisia, koska protokollatyypille on tunnusomaista numero, joka on suurempi kuin 0x05FE.

Alkuperäisen osoitekentän tulee kuitenkin sisältää tietyn lähettävän aseman osoite.

Tavallisten osoitteiden tapauksessa ensimmäiset kolme tavua tunnistavat verkkokortin valmistajan ja kolme viimeistä tavua ovat ainutlaatuinen numero erityinen lauta. Siten 3Comin tuottamien suosittujen verkkokorttien osoitteen kolme ensimmäistä tavua ilmaistaan ​​seuraavana numerona - 02608С heksadesimaalijärjestelmä kantaluku (jäljempänä käytämme merkintää 0x merkitsemään numeroita heksadesimaalimuodossa, eli 3Com-tunniste näyttää muotoa 0x02608C). Vastaanottajan osoitetta kutsutaan myös fyysiseksi tai MAC-osoitteeksi.

Yleisesti ottaen kohdeosoite identifioi välittömän vastaanottajan eikä lopullisen vastaanottajan, kuten Ethernet-verkon reitittimen. Lopullinen vastaanottaja tunnistetaan korkean tason protokollien avulla. TCP/IP:n tapauksessa tämä on aseman IP-osoite ja tämän aseman prosessin TCP- tai UDP-portti.

Protokollatyyppi-kenttä identifioi korkean tason protokollan, kuten IP, AppleTalk jne., jonka kehys on pakettisäiliö. Alla tarjoamme protokollatyypin kenttäarvot joillekin yleisille verkkoprotokollat:

Internet-protokolla (IP) - 0x0800; Address Resolution Protocol (ARP) - 0x0806; AppleTalk - 0x809B; Xerox Verkkojärjestelmä(XNS) - 0x0600; NetWare IPX/SPX - 0x8137.

Kehyksen seuraava kenttä palvelee itse asiassa hyödyllisen tiedon välittämistä (kehystasolla hyötykuormaa kutsutaan korkean tason protokollien palveluinformaatioksi, kuten paketin otsikko jne.).

Toisin kuin palvelukentillä, tietokentässä on vaihteleva pituus, ja se ei voi olla lyhyempi kuin 46 tavua ja pidempi kuin 1500 tavua. Siten kehyksen kokonaispituus ilman johdanto-osaa ja alkukehysten erotinta on 64 - 1518 tavua. Siinä tapauksessa, että lähetettävän tiedon todellinen määrä on alle 46 tavua (esimerkiksi pääteemulaatiossa lähetetään usein vain yksi näppäimistöltä syötetty merkki), tietokenttä täytetään minimikokoon paikkamerkillä. Täytetavu voidaan lisätä, vaikka siirrettävän tiedon määrä olisi yli 46 tavua. Novell ehdottaa, että jos tavuja on pariton määrä, verkkokortin ohjain lisää yhden lisää. Tämä tehdään, koska jotkut vanhemmat reitittimet eivät ymmärrä parittoman pituisia kehyksiä.

Kehyksen viimeinen kenttä on nelitavuinen FCS (Frame Check Sequence) -kenttä. Tämän kentän arvo lasketaan otsikon ja tietojen sisällöstä (mukaan lukien täyte, mutta ei johdanto-osaa ja erotinta) käyttämällä 32-bittistä syklistä redundanssikoodia (CRC-32) käyttämällä seuraavaa kaavaa (in binäärijärjestelmä merkintä):

tarkistussekvenssi = MOD(data/polynomi)

Ethernetissä generoiva polynomi on polynomi x 32 +x 26 +x 23 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +x+ 1. Tämä koodi voit havaita 99,999999977% kaikista virheistä jopa 64 tavua pituisissa viesteissä! Näin ollen todennäköisyys, että vastaanottoasema havaitsee vahingoittuneen kehyksen ehjänä, on käytännössä nolla.

Vastaanotettuaan kehyksen vastaanottoasema laskee tarkistussekvenssin uudelleen ja vertaa saatua tulosta FCS-kentän sisältöön. Jos ei täsmää, paketti katsotaan vioittuneeksi ja jätetään huomiotta.

BASIC 802.3 FRAME FORMAT

802.3-spesifikaation määrittelemä kehysmuoto on lähes identtinen edeltäjänsä kanssa, paitsi että protokollatyyppikentällä on kehyksen pituus. Ensi silmäyksellä tämä johtaa väistämättä sekaannukseen, kun Ethernet_II- ja Ethernet_802.3-kehykset lähetetään saman segmentin asemien välillä. Käytännössä näitä kehyksiä ei kuitenkaan ole vaikea erottaa toisistaan. Kuten olemme jo sanoneet, tietokentän pituus ei ylitä 1500 tavua, joten hyväksyttyjen sopimusten mukaisesti korkean tason protokollatyypiksi asetetaan suurempi kuin 0x05FE (1518 heksadesimaalimuodossa - koko kehyksen pituus), koska kaksitavuinen kenttä voi ottaa 65 536 eri arvoa . Siten, jos lähdeosoitteen ja datan välinen kenttäarvo on pienempi tai yhtä suuri kuin 1518, se on 802.3-kehys, muuten se on Ethernet_II-kehys.

Toinen pieni ero Ethernetin ja 802.3:n välillä on monilähetysosoitteiden luokittelu. Toisin kuin Ethernet, 802.3-spesifikaatio jakaa monilähetysosoitteet osoitteisiin, joilla on globaali ja paikallinen merkitys. Käytännössä tätä jakoa käytetään kuitenkin harvoin. (Puhuimme kolmannesta pienestä erosta - johdanto-osassa - edellä.)

Mukaan vertailumalli OSI, jokainen protokollatietolohko sisältää (kapseloi) paketit pinonsa ylempänä olevista protokollista. 802.3-protokolla kuvaa medium access -menetelmää - datalinkkikerroksen alempaa alikerrosta ja jonka päällä oleva protokolla on looginen protokolla

kanavaohjaus (Logical Link Control, LLC) - linkkikerroksen ylempi alikerros. Siksi standardi edellyttää, että tietokenttä sisältää LLC-otsikon. NetWaren varhaisissa versioissa Novell jätti tämän otsikon huomiotta ja alkoi sijoittaa IPX/SPX-paketteja suoraan kehyksen pituuskentän jälkeen, ja tietokenttä alkoi samalla tavalla kuin normaali IPX-otsikko, jossa kaksi tavua koostui ykkösistä (numero 0xFFFF). . Toisin sanoen Novell käytti kehyksiä säiliönä.

Periaatteessa 802.3-peruskehysmuodon käyttäminen ilman ylemmän linkin kerroksen ylärajaa antaa Novellin pienentää osan yleiskuormitustaan ​​kehystä kohti. Vahvistus on kuitenkin pieni, ja heterogeenisessä ympäristössä epästandardin muodon käyttö johtaa menetykseen, koska reititin tai verkkokortti pakko tarkistaa lisäkenttiä määrittääksesi paketin tyypin. Tämä oli yksi syy siihen, miksi Novell siirtyi versiosta 4.0 alkaen oletusasetuksiin vakiomuoto Ethernet_802.2. Toinen syy oli se, että Ethernet_802.3-peruskehysten käyttö teki mahdottomaksi suojausvaihtoehtojen, kuten pakettiallekirjoituksen, käytön, koska tarkistussumma paketti korjattiin arvoon 0xFFFF, jotta Ethernet_802.3-kehys voidaan erottaa muista kehystyypeistä.

KAKSI STANDARDIMUOTTOA

IEEE-määritykset tarjoavat vain kaksi vakiomuotoa - 802.2 ja 802.2 SNAP, joista toinen on luonnollinen jatko ensimmäiselle. Kuten jo mainittiin, vakiokehyksen on sisällettävä tietokentässä palvelutiedot loogista kanavan ohjausta varten, nimittäin yksitavuinen vastaanottajan palvelun yhteyspisteen kenttä (Destination Service Access Point, DSAP), yksitavuinen kenttä palvelun tukiasema lähettäjälle (Source Service Access Point, SSAP) ja yksitavuinen ohjauskenttä (katso kuva 2). IEEE määrittää Service Access Point (SAP) -numerot, ja se on varannut seuraavat numerot:

DSAP- ja SSAP-kenttiä käytetään taustalla olevan protokollan tunnistamiseen, ja ne sisältävät pääsääntöisesti saman arvon. Ohjauskentän arvo on yleensä 0x03 (LLC-protokollan mukaan tämä tarkoittaa, että yhteys on päällä linkkitasolla ei asennettu).

Sub-Network Access Protocol Pääsyprotokolla, SNAP) on suunniteltu lisäämään tuettujen protokollien määrää, koska yksitavuiset SAP-kentät voivat tukea enintään 256 protokollaa. Ethernet_SNAP-muoto tarjoaa ylimääräisen viiden tavun kentän protokollatunnistukseen (PI) tietokentässä, ja tämän kentän kahden viimeisen tavun arvot ovat samat kuin Ethernet_II:n protokollakentän arvot, jos kehykset sisältävät saman korkean tason protokollan paketteja, esimerkiksi NetWarelle ne ovat 0x8137.

ALGORITMI KEHYSMUODON MÄÄRITTÄMISEKSI

Ethernet-kehysformaatin erottaminen toisesta ei ole vaikeaa, ja voit tehdä sen seuraavasti yksinkertainen algoritmi(katso kuva 3). Ajurin on ensin tarkistettava protokollatyyppi/kehyksen pituus -kentän arvo (13. ja 14. tavu otsikossa). Jos siihen kirjoitettu arvo on suurempi kuin 0x05FE (maksimi mahdollinen kehyksen pituus), kyseessä on Ethernet_II-kehys.

(1x1)

Kuva 3.

Ethernet-kehystyypin määrittämiseksi sinun on ensin tarkistettava kentän arvo lähdeosoitteen jälkeen ja sitten tietokentän kaksi ensimmäistä tavua.

Jos ei, sinun tulee jatkaa tarkistamista. Jos kaksi ensimmäistä tavua ovat 0xFFFF, tämä on Ethernet_802.3-muoto NetWare 3.x:lle. Muuten se on tavallinen 802.2-kehysmuoto, ja meidän on vain selvitettävä, kumpi näistä kahdesta on normaali (Ethernet_802.2) vai laajennettu (Ether-net_SNAP). Ethernet_SNAP:n tapauksessa tietokentän ensimmäisen ja toisen tavun arvo on 0xAA. (Kolmannen tavun arvo on 0x03, mutta tätä ei tarvitse tarkistaa.)

KULISSIEN TAKANA

Eri protokollat ​​käyttävät erilaisia ​​kehysmuotoja (katso taulukko 1). Jälkimmäisten määrä ei kuitenkaan ole niin suuri, eikä niitä ole vaikea erottaa toisistaan. Lisäksi TCP/IP-protokolla on siirtymässä hallitsevaan asemaan paitsi globaaleissa verkoissa myös paikallisissa verkoissa, joten jopa Novell päätti luopua IPX/SPX-protokollastaan ​​TCP/IP:n hyväksi NetWaren seuraavassa versiossa. Tämä tarkoittaa, että useimmissa tapauksissa verkonvalvojan ei tarvitse huolehtia siitä, mitä Ethernet-kehysmuotoa käytetään. Kuitenkin, kuten kokemus osoittaa, vanhat teknologiat elävät melko pitkään, joten kehysmuotojen tuntemus voi olla sekä käytännöllistä että teoreettista mielenkiintoa.

TAULUKKO 1 - PÖYTÄKIRJAT JA MERKITYKSELLISET PUITETYYPIT

Verkkoteknologiat

Artikkeli osoittautui varsin laajaksi, keskustelunaiheina olivat Ethenet-kehysformaatit, L3:n hyötykuorman kokorajoitukset, Ethernet-otsikkokokojen kehitys, Jumbo Frame, Baby-Giant ja monia muita asioita käsiteltiin ohimennen. Olet jo törmännyt joihinkin niistä tietoverkkojen katsauskirjallisuudessa, mutta et varmasti ole törmännyt moniin, jos et ole tehnyt syvällistä tutkimusta.

Aloitetaan tarkastelemalla Ethernet-kehysten otsikkomuotoja niiden syntymäjonossa.

Ethernet-kehysmuodot.

1) Ethernet II

Riisi. 1

Johdanto– bittisarja, joka ei itse asiassa ole osa ETH-otsikkoa, joka määrittää Ethernet-kehyksen alun.

DA (kohdeosoite) – MAC-osoite kohde, voi olla unicast, multicast, broadcast.

SA (lähdeosoite)– lähettäjän MAC-osoite. Aina unicast.

E-TYPE (EtherType)– Tunnistaa L3-protokollan (esimerkiksi 0x0800 – Ipv4, 0x86DD – IPv6, 0x8100 – osoittaa, että kehys on merkitty 802.1q-otsikolla jne. Luettelo kaikista EtherTypeistä - standards.ieee.org/develop/regauth/ethertype eth.txt)

Hyötykuorma– L3-paketin koko 46 - 1500 tavua

FCS (Frame Check Sequences)– 4-tavuinen CRC-arvo, jota käytetään lähetysvirheiden havaitsemiseen. Lähettävä osapuoli laskee ja sijoitetaan FCS-kenttään. Vastaanottava osapuoli laskee annettu arvo itsenäisesti ja vertaa sitä saatuun.

Tämä muoto luotiin yhteistyössä kolmen yrityksen - DEC, Intel ja Xerox - kanssa. Tässä suhteessa standardia kutsutaan myös DIX Ethernet -standardi. Tämä versio standardi julkaistiin vuonna 1982 (ensimmäinen versio, Ehernet I, julkaistiin 1980. Erot versioissa ovat pieniä, formaatti kokonaisuutena pysyy ennallaan). Vuonna 1997 vuosi tämä standardi IEEE lisättiin 802.3-standardiin ja tällä hetkellä, suurin osa Ethernet-verkkojen paketeista on kapseloitu tämän standardin mukaisesti.

2) Ethernet_802.3/802.2 (802.3 LLC-otsikolla)

Riisi. 2

Kuten ymmärrät, IEEE-komitea ei voinut katsoa rauhallisesti, kun valta, raha ja naiset kirjaimellisesti luisuivat heidän käsistään. Siksi kiireisempiä kiireellisempien ongelmien kanssa standardointia varten Ethernet-tekniikat aloitettiin pienellä viiveellä (vuonna 1980 he ryhtyivät töihin, vuonna 1983 he antoivat maailmalle luonnoksen ja vuonna 1985 itse standardin), mutta suurella innolla. Valiokunta julisti innovaation ja optimoinnin ydinperiaatteikseen seuraava muoto kehys, joka näkyy kuvassa 2.

Ensinnäkin kiinnitämme huomiota siihen, että "tarpeeton" E-TYPE-kenttä muutettiin Length-kenttään, joka osoitti tämän kentän jälkeen ja ennen FCS-kenttää olevien tavujen lukumäärää. Nyt oli mahdollista ymmärtää, kenellä oli pidempi jo OSI-järjestelmän toisella tasolla. Elämästä on tullut parempaa. Elämästä on tullut hauskempaa.

Mutta tarvittiin osoitin kerroksen 3 protokollatyyppiin, ja IEEE antoi maailmalle seuraavan innovaation - kaksi kenttää, joista kukin on 1 tavu - Source Service Access Point ( SSAP) ja kohdepalvelun tukiasema ( DSAP). Tavoite on sama - korkeamman protokollan tunnistaminen, mutta mikä on toteutus! Nyt, koska yhdessä istunnossa on kaksi kenttää, paketti voidaan siirtää eri protokollien välillä tai samaa protokollaa voitaisiin kutsua eri tavalla saman istunnon kahdessa päässä. A? Millaista se on? Missä sinun Skolkovosi on?

Huomautus: Tästä on vain vähän hyötyä tosielämässä, ja SSAP/DSAP-arvot ovat yleensä samat. Esimerkiksi SAP IP:lle on 6, STP:lle - 42 (täydellinen arvoluettelo - standards.ieee.org/develop/regauth/llc/public.html)

IEEE varasi 1 bitin SSAP:ssa ja DSAP:ssa ilman taukoa. SSAP:ssa määrittämällä komento tai vastauspaketti, DSAP:ssa määrittämällä ryhmä tai yksittäinen osoite (katso kuva 6). Nämä asiat eivät olleet yleisiä Ethernet-verkoissa, mutta SAP-kenttien bittien määrä pienennettiin 7:ään, jolloin jäljelle jäi vain 128 mahdolliset numerot korkeamman protokollan ohjeiden mukaisesti. Muistakaamme tämä tosiasia, palaamme siihen myöhemmin.

Oli jo vaikea pysähtyä haluamaani tehdä paras muoto kehys maassa, ja 1 tavun kenttä tulee näkyviin IEEE-kehysmuodossa Ohjaus. Vastuu, ei paljon, ei vähän, yhteydettömästä tai yhteyssuuntautuneesta yhteydestä!

Hengitettyään ulos ja tutkittuaan heidän aivonsa, IEEE päätti pitää tauon.

Kommentti: Kyseiset 3 kenttää ovat DSAP, SNAP ja Control, ja ne ovat LLC-otsikko.

3) "Raaka" 802.3

Riisi. 3

Novell toi tämän "alitason" maailmalle. Oli villi 80-luku, kaikki selvisivät parhaansa mukaan, eikä Novell ollut poikkeus. Hankittuaan 802.3/802.2-standardin määrittelyn kehitysprosessin aikana ja heittäen LLC-otsikon esiin ranneliihdytyksellä Novell sai varsin hyvän kehysmuodon (jossa pystyi mittaamaan pituutta toisella tasolla!), mutta yksi merkittävä haittapuoli - kyvyttömyys määrittää korkeampaa protokollaa. Mutta kuten saattoi arvata, siellä työskennelleet kaverit eivät olleet tyhmiä, ja terveen järjen avulla he keksivät ratkaisun - "käännämme puutteet omiksi eduiksi" ja rajoittivat tämän kehysmuodon yksinomaan IPX-protokollaan, joita he itse tukivat. Ja idea oli hyvä, ja suunnitelma oli strategisesti oikea, mutta kuten historia on osoittanut, se ei toiminut.

4) 802.3 SNAP-otsikolla.

Aika kului. IEEE-komitea tajusi, että protokollanumerot ja rahat olivat loppumassa. Kiitolliset käyttäjät pommittivat toimittajia kirjaimilla, joissa 3-tavuinen LLC-otsikko asetettiin ihmiskunnan mahtavien innovaatioiden tasolle, kuten koiran varustaminen viidennellä jalalla tai hihalla, jota voidaan käyttää naaraan anatomian optimointiin. Oli mahdotonta odottaa enää, oli tullut aika julistaa itsemme maailmalle.

Riisi. 4

Ja auttaakseen niitä, jotka kärsivät protokollanumeroiden puutteesta (yhteensä voi olla 128 - mainitsimme), IEEE esittelee uuden Ethernet SNAP -kehysstandardin (kuva 4). Suurin innovaatio on 5-tavuisen SNAP (Subnetwork Access Protocol) -kentän lisääminen, joka puolestaan ​​koostuu kahdesta osasta - 3-tavuisesta Organisationally Unique Identifier (OUI) -kentästä ja 2-tavuisesta Protocol ID (PID) -kentästä. . 5.

Riisi. 5

OUI tai toimittajakoodi – voit tunnistaa omat protokollat ​​ilmoittamalla toimittajan. Jos esimerkiksi nappaat PVST+-paketin WireSharkilla, näet koodin 0x00000c OUI-kentässä, joka on Cisco Systemsin tunniste (kuva 6).

Riisi. 6

Kommentti: 802.3 SNAP -kehysmuotoon kapseloituun pakettiin on melko helppo törmätä jo nytkin - nämä ovat kaikki STP-perheen protokollia, CDP-, VTP-, DTP-protokollia.

PID-kenttä on olennaisesti sama EtherType-kenttä DIX Ethernet II:sta - 2 tavua, jotka osoittavat korkeamman tason protokollaa. Koska aiemmin tähän käytettiin LLC-otsikon DSAP- ja SSAP-kenttiä, mikä osoittaa, että korkeamman protokollan tyyppiä tulisi tarkastella SNAP-kentässä, DSAP- ja SSAP-kentillä on kiinteä arvo 0xAA (näkyy myös Kuva 6)

Kommentti: Käytettäessä LLC/SNAP-kehysmuotoa IP-pakettien kuljettamiseen, IP MTU pienenee 1500 tavusta 1497 tavuun ja 1492 tavuun.

Mitä tulee kehysmuodossa oleviin otsikoihin, se on periaatteessa se. Haluaisin kiinnittää huomionne vielä yhteen kohtaan kehysmuodossa – hyötykuorman kokoon. Mistä tämä alue on peräisin - 46 - 1500 tavua?

L3 Hyötykuorman koko.

Luultavasti jokainen, joka on edes lukenut ensimmäisen CCNA-opetussuunnitelman, tietää, mistä alaraja tuli. Tämä rajoitus johtuu CSMA/CD-menetelmän asettamasta 64 tavun kehyskoon rajoituksesta (64 tavua - 14 tavua L2-otsikko - 4 tavua FCS = 46 tavua) - aika, joka tarvitaan 64 tavun lähettämiseen verkkoliitännän kautta. ja riittää määrittämään törmäyksen Ethernet-ympäristössä.
Kommentti: Nykyaikaisissa verkoissa, joissa törmäysten esiintyminen on suljettu pois, tämä rajoitus ei ole enää relevantti, mutta vaatimus säilyy. Tämä ei ole ainoa noista ajoista jäljellä oleva "liite", mutta puhumme niistä toisessa artikkelissa.

Mutta mistä nämä pahamaineiset 1500 tavua tulivat, on monimutkaisempi kysymys. Löysin seuraavan selityksen - yläkehyksen kokorajoituksen käyttöönotolle oli useita edellytyksiä:

• Lähetysviive – mitä suurempi kehys, sitä kauemmin lähetys kestää. Varhaisissa verkoissa, joissa törmäysalue ei rajoittunut porttiin ja kaikkien asemien piti odottaa lähetyksen valmistumista, tämä oli vakava ongelma.
• Mitä suurempi kehys, sitä suurempi on todennäköisyys, että kehys vaurioituu lähetyksen aikana, mikä johtaa uudelleenlähetyksen tarpeeseen ja kaikki törmäysalueen laitteet joutuvat odottamaan uudelleen.
• Rajapintapuskureihin käytetyn muistin asettamat rajoitukset - tuolloin (1979) puskureiden lisäys nosti merkittävästi rajapinnan kustannuksia.
• Pituus/tyyppi -kentän tuoma rajoitus on, että standardi edellyttää, että kaikki arvot yli 1536 (05-DD - 05-FF.) osoittavat EtherTypeä, joten pituuden on oltava pienempi kuin 05-DC. (Epäilen todella, että tämä on enemmän seuraus kuin edellytys, mutta näyttää siltä, ​​​​että se on peräisin 802.3-standardin kehittäjiltä)

Kaiken kaikkiaan 802.3-standardissa kehyskoko rajoitettiin 1518 tavuun yläosassa ja hyötykuorma 1500 tavuun (siis Ethernet-liitännän oletusarvoinen MTU-koko).

Kommentti: Alle 64 tavua pienempiä kehyksiä kutsutaan Runteiksi, ja yli 1518 tavua suurempia kutsutaan jättiläisiksi. Voit tarkastella tällaisten rajapintaan vastaanotettujen kehysten määrää käyttämällä show interface gigabitEthernet moduuli/numero ja näyttää käyttöliittymän gigabitEthernet moduuli/numerolaskurit virhekomentoja. Lisäksi ennen IOS 12.1(19) laskurit sisälsivät molemmat kehykset, joissa oli väärä ja oikea CRS (vaikka jälkimmäistä ei aina hylätty - alustasta ja olosuhteista riippuen). Mutta 12.1.(19) alkaen näissä laskureissa näytetään vain ne runt- ja jättikehykset, joissa on virheellinen CRS, alle 64 tavun kehykset, mutta oikealla CRS:llä (syy liittyy yleensä 802.1Q-tunnistukseen tai kehysten lähde, ei fyysisen tason ongelmat) tästä versiosta menevät Undersize-laskuriin, pudotetaanko ne vai välitetäänkö ne edelleen, riippuu alustasta.

Ethernet-otsikoiden kokojen kehitys.

IEEE 802 -sarjan teknologioiden ja spesifikaatioiden kehittyessä myös kehyskoko muuttui. Perusmuutoksia kehyksen kokoon (ei MTU!):

• 802.3AC - nostaa enimmäiskehyksen koon 1522:een - Q-tunniste lisätään - kuljettaa tietoja 802.1Q:sta (VLAN-tunniste) ja 802.1p:stä (bitit COS:n alla)
• 802.1AD - nostaa enimmäiskehyksen koon 1526:een, QinQ-tuki
• 802.1AH (MIM) – Provider Bridge Backbone Mac Macissa + 30 tavua kehyksen kokoon
• MPLS – suurenna kehyksen kokoa tarrapinolla 1518 + n*4, missä n on pinossa olevien tarrojen lukumäärä.
• 802.1AE – Mac-suojaus, suojaustunniste ja viestitodennuskoodi -kentät lisätään vakiokenttiin + 68 tavua kehyksen kokoon.

Kaikki nämä suuremmat kehykset on ryhmitelty yhden nimen alle - Vauva-jättiläinen kehyksiä. Baby-Giantin äänetön yläraja on 1600 tavua. Nykyaikaiset verkkoliitännät välittävät nämä kehykset, usein muuttamatta edes HW MTU -arvoa.

Kiinnittäkäämme erityistä huomiota 802.3AS-spesifikaatioihin - se kasvattaa enimmäiskehyksen koon 2000:een (mutta säilyttää MTU-koon 1500 tavua!). Lisäys on nimessä ja trailerissa. Aluksi kasvun suunniteltiin olevan 128 tavua - for natiivi tuki standardi 802.3 yllä olevista laajennuksista, mutta lopulta he sopivat 2 tuhannesta, ilmeisesti, jotta ei koota kahdesti (tai kuten IEEE:ssä sanotaan - tämä kehyskoko tukee lähitulevaisuudessa olevia kapselointivaatimuksia). Standardi hyväksyttiin vuonna 2006, mutta en ole nähnyt sitä muuten kuin IEEE-esityksissä. Jos jollain on jotain lisättävää tänne (eikä vain tänne) - tervetuloa kommentteihin. Yleisesti ottaen suuntaus kasvattaa rungon kokoa samalla kun säilytetään PAYLOAD-koko herättää päässäni epämääräisiä epäilyksiä valitun liikesuunnan oikeellisuudesta.

Kommentti: Hieman edellä mainitun lisäksi FCoE-kehys on asettunut - kehyksen koko on jopa 2500 tavua, usein näitä kehyksiä kutsutaan minijumboksi. Jotta voit tukea niitä, sinun on otettava käyttöön jumbo-kehystuki.

Ja Ethernetin viimeinen "paskiainen" on Jumbo Frame (vaikka jos käännät Jumbon, niin Hodor näyttää enemmän viittaukselta Game of Thronesiin). Tämä kuvaus sisältää kaikki kehykset, jotka ovat suurempia kuin standardikoko 1518 tavua, lukuun ottamatta edellä käsiteltyjä. Jumbo-paketit eivät näy millään tavalla 802.3-spesifikaatioissa, joten toteutus on jokaisen toimittajan päätettävissä. Jumbo-kehykset ovat kuitenkin olleet olemassa niin kauan kuin Ethernet on ollut olemassa. Tämä määritellään seuraavasti:

1. Hyödy hyötykuorman ja otsikon välisestä suhteesta. Mitä korkeampi tämä suhde, sitä tehokkaammin voimme käyttää viestintälinjoja. Tietenkään ero tässä ei ole sama kuin verrattuna 64 tavun ja 1518 tavun pakettien käyttöön TCP-istunnoissa. Mutta voit voittaa 3-8 prosenttia liikenteen tyypistä riippuen.
2. Huomattavasti pienempi määrä otsikoita aiheuttaa vähemmän kuormitusta Forwading Enginelle, samoin kuin palvelumoottoreille. Esimerkiksi 10 Gt:n linkin kehysnopeus, joka on ladattu 1500 tavun kehyksillä, on 812 744 kuvaa sekunnissa, ja sama linkki, joka on ladattu 9 000 tavun Jumbo-kehyksillä, tuottaa vain 138 587 kehyksen sekunnissa. Kuva 7 esittää kaavion Alteon Networksin raportista (linkki artikkelin alareunassa) prosessorin ja gigabitin linkin käytöstä riippuen käytetyn kehyskoon tyypistä.
3. Kasvata TCP-suorituskykyä, kun MTU:n koko muuttuu -

802.3:ssa kuvattu Ethernet-teknologiastandardi kuvaa yhden MAC-kerroksen kehysmuotoa. Koska MAC-kerroksen kehyksen on sisällettävä asiakirjassa 802.2 kuvattu LLC-kerroskehys, IEEE-standardien mukaan vain yhtä versiota linkkikerroksen kehyksestä voidaan käyttää Ethernet-verkossa, joka muodostuu MAC- ja LLC-alikerroksen otsikoiden yhdistelmästä.

Käytännössä Ethernet-verkot käyttävät kuitenkin neljää tyyppistä otsikkoa datalinkkitasolla. Tämä johtuu Ethernet-tekniikan pitkästä kehityshistoriasta ennen IEEE 802 -standardien käyttöönottoa, jolloin LLC-alikerrosta ei erotettu yleisestä protokollasta ja vastaavasti LLC-otsikkoa ei käytetty.

Kolmen yrityksen, Digital, Intel ja Xerox, konsortio esitti Ethernet-standardin patentoidun versionsa 802.3-komitealle vuonna 1980, mutta 802.3-komitea hyväksyi standardin, joka poikkesi joissakin yksityiskohdissa DIX-ehdotuksesta. Erot koskivat myös kehysmuotoa, mikä johti kahden erityyppisen kehyksen olemassaoloon Ethernet-verkossa.

Toinen kehysmuoto syntyi Novellin pyrkimysten nopeuttaa protokollapinoaan Ethernet-verkoissa.

Lopuksi neljäs kehysmuoto oli seurausta 802.2-komitean pyrkimyksistä saattaa aikaisemmat kehysmuodot johonkin yhteiseen standardiin.

Nykyään melkein kaikki verkkosovittimet, verkkosovittimen ajurit, sillat/kytkimet ja reitittimet voivat toimia kaikkien käytännössä käytettyjen Ethernet-teknologian kehysmuotojen kanssa ja kehystyypin tunnistus suoritetaan automaattisesti.

Alla on kuvaus kaikista neljästä Ethernet-kehysotsikoiden muutoksesta (tässä kehys tarkoittaa koko joukkoa kenttiä, jotka liittyvät datalinkkikerrokseen, eli MAC- ja LLC-kerrosten kenttiä):

802.3/LLC-kehys (802.3/802.2-kehys tai Novell 802.2 -kehys)

Raw 802.3 -kehys (tai Novell 802.3 -kehys)

Ethernet DIX -kehys (tai Ethernet II -kehys)

Ethernet SNAP -kehys

Näiden neljän Ethernet-kehyksen muodot on esitetty kuvassa 6.2.

Kuva 6. 2. Ethernet-kehysmuodot.

Riisi. 14.3. Ethernet-kehysmuodot.

802.3/llc kehys

802.3/LLC-kehyksen otsikko on tulos IEEE802.3- ja 802.2-standardeissa määriteltyjen kehyksen otsikkokenttien yhdistämisestä.

802.3-standardi määrittelee kahdeksan otsikkokenttää:

Johdatuskenttä ( Johdanto ) koostuu seitsemän tavua kellotietoja. Jokainen tavu sisältää saman bittisarjan - 10101010 . Manchester-koodauksessa tätä yhdistelmää edustaa fyysisessä ympäristössä jaksollinen aaltosignaali, jonka taajuus on 5 MHz.

Käynnistä kehyksen rajoitin (Aloita- /- kehys- erotin, SFD) koostuu yhdestä tavusta bittisarjalla 10101011 . Tämän bittikuvion esiintyminen on osoitus siitä, että seuraava tavu on kehyksen otsikon ensimmäinen tavu.

Osoite tapaamisia (Kohdeosoite, DA) - 6 tavua. Ensimmäinen bitti korkeaa tavua kohdeosoite on merkki oi se on yksilö- tai ryhmäosoite. Jos 0 , niin osoite on yksilö ( unicast ), Mitä jos 1 , sitten tämä ryhmän osoite ( monilähetys ). Verkkoryhmän osoite voi olla tarkoitettu kaikille verkon solmuille tai tietylle verkkosolmuryhmälle. Jos osoite koostuu kaikista yksiköistä, eli sillä on heksadesimaaliesitys 0* FFFFFFFFFFFFFF, niin se on tarkoitettu kaikki solmut verkkoa kutsutaan lähetysosoite ( lähettää ) . Muissa tapauksissa ryhmäosoite liitetään vain niihin solmuihin, jotka on määritetty (esimerkiksi manuaalisesti) ryhmän jäseniksi, joiden numero on määritetty ryhmäosoitteessa. Korkean tavun toinen bitti määrittää osoitteet osoitteen määritystapa - keskitetty tai paikallinen. Jos tämä bitti on yhtä suuri 0 (mikä lähes aina tapahtuu tavallisissa Ethernet-laitteissa), sitten keskitetysti osoitettu osoite IEEE-komitean avustuksella. IEEE-komitea jakaa ns organisaation yksilölliset tunnisteet (OrganisatorisestiAinutlaatuinenTunniste, OUI) . Tämä tunniste sijoitetaan osoitteen 3 tärkeintä tavua ( esimerkiksi tunniste 000081 identifioi yrityksen Bay Networks ) .Laitteen valmistaja on vastuussa osoitteen alemman 3 tavun yksilöllisyydestä.Kaksikymmentäneljä bittiä, jotka on osoitettu valmistajalle tuotteidensa liitäntöjen käsittelemiseksi, sallivat julkaisun 16 miljoonaa käyttöliittymää yhden organisaatiotunnuksen alla.

Keskitetysti jaettujen osoitteiden ainutlaatuisuus koskee kaikkia tärkeimpiä paikallisverkkoteknologioita - Ethernet, TokenRing, FDDI jne. Huomio:

IEEE Ethernet -standardeissa tavun vähiten merkitsevä bitti on kuvattu vasemmanpuoleisessa kentän kohdassa ja merkittävin bitti oikeanpuoleisessa paikassa. Tämä on epätyypillinen tapa näyttää bittien järjestys tavussa sen mukaan, missä järjestyksessä bitit lähetetään viestintälinjalla Ethernet-lähettimellä. Lähdeosoite ( Lähde , Osoite ) S.A.

- 6-tavuinen kenttä, joka sisältää aseman osoitteen - kehyksen lähettäjän. Ensimmäisen bitin arvo on aina 0. ) . Pituus (Pituus, L Tuplatavu

pituus kenttä määrittää kehyksen tietokentän pituuden. 802.3-kehys on MAC-alikerroskehys 802.2-standardin mukaisesti Vhänen

DSAP tietokenttä upotettuna LLC-alikerroksen kehykseen ( kun kehyksen alun ja lopun liput on poistettu vastaanottajan palvelun käyttöosoite Kohde Palvelu ) Pääsy

SSAP Kohta -1 tavu. osoite pääsy palvelut lähettäjä

Ohjaus (Lähdepalvelun tukiasema) - 1 tavu.

9. ohjauskenttä – 1 tavu LLC1-tilassa ja 2 tavua LLC2-tilassa. ) Tietokenttä ( (Data) täyttää kehyksen vähimmäisarvoon 46 tavua. Koska LLC-kehyksen otsikon pituus on 3 (LLC1-tilassa) tai 4 tavua (LLC2-tilassa), datakentän enimmäiskoko pienenee 1497 (1796) tavuun.

10. Tarkistussumma-kenttä ( kehys Tarkista Järjestys , FCS ) - 4 tavua, jotka sisältävät arvon, joka lasketaan tietyllä CRC-32-algoritmilla.

Tunnistus - CSMA/CD). Kaikilla verkon tietokoneilla on pääsy yhteiseen väylään kuhunkin tietokoneeseen sisäänrakennetun verkkosovittimen kautta käyttäen half-duplex-siirtotilaa. Tietokoneen kytkentäkaavio koaksiaalikaapeli on esitetty kuvassa 6.1.

Riisi. 6.1.

Asemat perinteisessä paikallisverkossa Ethernet voidaan liittää yhteen fyysisen väylän tai tähtitopologian avulla, mutta looginen topologia- aina väsy. Tällä tarkoitamme, että media (kanava) on jaettu asemien kesken ja vain yksi asema kerrallaan voi käyttää sitä. Oletetaan myös, että kaikki asemat vastaanottavat aseman lähettämän kehyksen (lähetys). Osoitettu kohde tallentaa kehyksen, kun taas muut hylkäävät sen. Miten voimme tässä tilanteessa varmistaa, että kaksi asemaa eivät käytä mediaa samanaikaisesti? Vastaus: jos niiden kehykset törmäävät toisiinsa. CSMA/CD on suunniteltu ratkaisemaan tämä ongelma seuraavien periaatteiden mukaisesti:

1. Jokaisella asemalla on yhtäläinen oikeus mediaan (kollektiivinen pääsy).
2. Jokainen asema, jolla on kehys ensin lähetettäväksi, "kuuntelee" (monitoroi) mediaa. Jos välineessä ei ole dataa, asema voi aloittaa lähetyksen (kantoaallon taajuuden seuranta).
3. Saattaa käydä niin, että kaksi mediaa tarkkailevaa asemaa huomaa, ettei se ole varattu ja alkaa lähettää dataa. Tässä tapauksessa syntyy konflikti, jota kutsutaan törmäykseksi.

Protokolla pakottaa aseman jatkamaan linjan valvontaa lähetyksen alkamisen jälkeen. Jos on ristiriita, kaikki asemat havaitsevat sen, jokainen lähettävä asema lähettää vikasignaalin tuhotakseen linjadatan ja odottaa sitten joka kerta eri satunnaisen ajan yrittääkseen uudelleen. Satunnaiset ajat estävät tietojen lähettämisen uudelleen samanaikaisesti. Ennen lähetyksen aloittamista solmun on varmistettava, että kantoaaltomedia ei ole varattu, mikä on osoitus kantoaallon taajuuden puuttumisesta. Jos media on vapaa, solmulla on oikeus aloittaa tietyn muotoisen kehyksen lähettäminen. Oletetaan, että solmun 2 on lähetettävä kehys solmulle N. Todettuaan, että tietoväline on vapaa, solmu 2 alkaa lähettää kehystä (kuva 6.2), jota edeltää johdanto, joka koostuu 7 tavusta muotoa 10101010 ja tavusta Kehyksen erottimen alku – SFD tyyppi 10101011. Vastaanotin tarvitsee näitä yhdistelmiä päästäkseen bitti- ja kehyssynkronointiin lähettimen kanssa. Kehys päättyy 4 tavua pitkälle kehysohjaussekvenssikenttään (FCS - Frame Check Sequence) (ei näy kuvassa 6.2). Lähettimen signaalit etenevät kaapelia pitkin molempiin suuntiin, ja kaikki solmut tunnistavat kehyslähetyksen alkamisen. Vain solmu N tunnistaa sen oma osoite(kohde-MAC-osoite) kehyksen alussa ja kirjoittaa sen sisällön puskuriinsa käsittelyä varten. Vastaanotetusta kehyksestä määritetään lähdeosoite (lähde MAC-osoite), johon vastauskehys tulee lähettää. Paketin vastaanottaja kerroksessa 3 määritetään kentän mukaan Protokollatyyppi: arvo 0x0800 - IP-moduulin osoite, 0806 - ARP-moduulin osoite. Minimi ja enimmäisarvo kenttien pituudet protokollille ylemmät tasot- 46 ja 1500 tavua, vastaavasti. Kehysbittien lähetysjärjestys on: vasemmalta oikealle / alhaalta ylös (kuva 6.2), numerot osoittavat kehyskenttien pituuden tavuina.

Mikä tahansa solmu, jos on lähetettävä kehys ja varattu media, pakotetaan odottamaan julkaisuaan. Merkki lähetyksen päättymisestä on kantoaaltotaajuuden katoaminen. Kehyslähetyksen päätyttyä kaikkien solmujen on kestettävä 9,6 μs:n teknologiatauko verkkosovittimien nollaamiseksi ja estääkseen samaa solmua kaappaamasta mediaa uudelleen.

Riisi. 6.2.

Joskus syntyy tilanteita, joissa yksi solmu on jo aloittanut lähettämisen, mutta toinen solmu ei ole vielä ehtinyt havaita tätä ja alkaa myös lähettää kehystään. Tätä tilannetta, jossa useampi kuin yksi solmu kaappaa vapaan median, kutsutaan törmäys. Törmäyksen ratkaisumekanismi on seuraava (kuva 6.3):

Riisi. 6.3.

Jos vastaanotetun signaalin taso ei ylitä kynnysarvoa, solmu jatkaa lähetystä, mutta jos se ylittää sen, solmu lopettaa kehyksen lähettämisen ja lähettää verkkoon erityisen 32-bittisen tukosyhdistelmän (törmäyssignaalin). ad hoc -sekvenssi, joka yksinkertaisesti johtaa signaalitason nousuun paikallisverkossa pulssiamplitudin kasvun vuoksi Manchesterin suuntanumero kokonaissignaali. Tämän jälkeen törmäyksen havaitseva solmu pysähtyy satunnaisesti ja voi sitten yrittää lähettää kehyksen uudelleen. Uudelleenyritysten määrä ei saa ylittää 16. Jos kehys aiheuttaa törmäyksen jopa 16. yrityksen jälkeen, se hylätään. Suurella määrällä solmuja törmäyksen todennäköisyys kasvaa ja läpijuoksu Ethernet-verkko putoaa, koska verkko kaikkea pidemmän aikaa kiireinen törmäysten käsittely ja kehysten hylkääminen. Kolme tekijää määrää, miten CSMA/CD toimii: kehyksen vähimmäispituus, lähetysnopeus data- ja konfliktialue.

Sinun on odotettava asemaa tietty aika varmistaaksesi, että rivillä ei ole dataa - tämä aika on yhtä suuri kuin kehyksen vähimmäispituus jaettuna lähetysnopeus(aika, joka kuluu vähimmäispituisen kehyksen lähettämiseen), ja se on verrannollinen aikaan, joka kuluu ensimmäiseltä bitiltä verkon suurimman etäisyyden (törmäysalue) kulkemiseen. Toisin sanoen meillä on:

Kuvan vähimmäispituus/bittinopeus on verrannollinen törmäysverkkotunnukseen/etenemisnopeuteen

Perinteisessä Paikallinen verkko Ethernet, kehyksen vähimmäispituus on 520 bittiä, lähetysnopeus- 10 Mbit/s, etenemisnopeus on lähes yhtä suuri kuin valon nopeus ja konfliktialue on noin 2500 metriä.

Riisi. 6.5.

• Johdanto. Kehyksen alustusosa sisältää 7 tavua (56 bittiä) vuorottelevia ykkösiä ja nollia, jotka hälyttävät järjestelmää vastaanottamaan saapuvan kehyksen ja valmistelemaan sen synkronointia varten kellon avulla. Johdanto on itse asiassa lisätty fyysinen taso eikä se ole (muodollisesti) osa kehystä.
• Kehyksen erottimen alku(SFD - Aloituskehyksen erotin). SFD-kenttä (1 tavu: 10101011) merkitsee kehyksen alun ja ilmoittaa asemalle, että synkronointi on päättynyt. Kaksi viimeistä bittiä ovat 11 (kaksi) - signaali, että seuraava kenttä on vastaanottajan osoite.
• Vastaanottajan osoite (DA - Destination Address). DA-kenttä on 6 tavua pitkä ja sisältää fyysinen osoite kohde- tai väliasema.
• Lähteen osoite(SA -