I dag skal vi se på driften av Layer 2 EtherChannel-kanalaggregeringsprotokollen for lag 2 av OSI-modellen. Denne protokollen er ikke så forskjellig fra Layer 3-protokollen, men før vi dykker inn i Layer 3 EtherChannel, må jeg introdusere noen konsepter, så vi kommer til Layer 1.5 senere. Vi fortsetter å følge CCNA-kursplanen, så i dag skal vi dekke seksjon 2, Konfigurering, testing og feilsøking av lag 3/1.5 EtherChannel, og underavsnitt 1.5a, Static EtherChannel, 1.5b, PAGP og XNUMXc, IEEE -LACP åpen standard. .
Før vi går videre, må vi forstå hva en EtherChannel er. La oss anta at vi har bryter A og bryter B redundant forbundet med tre kommunikasjonslinjer. Hvis du bruker STP, vil de to ekstra linjene bli logisk blokkert for å forhindre løkker.
La oss si at vi har FastEthernet-porter som gir 100 Mbps trafikk, så den totale gjennomstrømningen er 3 x 100 = 300 Mbps. Vi forlater bare en kommunikasjonskanal, på grunn av hvilken den vil falle til 100 Mbit/s, det vil si i dette tilfellet vil STP forverre nettverksegenskapene. I tillegg vil 2 ekstra kanaler være inaktive forgjeves.
For å forhindre dette utviklet KALPANA, selskapet som skapte Cisco Catalist-svitsjer og senere ble kjøpt av Cisco, en teknologi kalt EtherChannel på 1990-tallet.
I vårt tilfelle gjør denne teknologien tre separate kommunikasjonskanaler til én logisk kanal med en kapasitet på 300 Mbit/s.
Den første modusen for EtherChannel-teknologi er manuell eller statisk modus. I dette tilfellet vil ikke bryterne gjøre noe under noen overføringsforhold, og stole på det faktum at alle manuelle innstillinger av driftsparametere er gjort riktig. Kanalen slår seg ganske enkelt på og fungerer, og stoler fullstendig på innstillingene til nettverksadministratoren.
Den andre modusen er den proprietære Cisco PAGP-lenkeaggregeringsprotokollen, den tredje er IEEE-standard LACP-lenkeaggregeringsprotokollen.
For at disse modusene skal fungere, må EtherChannel gjøres tilgjengelig. Den statiske versjonen av denne protokollen er veldig enkel å aktivere: du må gå til innstillingene for brytergrensesnittet og gå inn i kanalgruppe 1-moduskommandoen.
Hvis vi har bryter A med to grensesnitt f0/1 og f0/2, må vi gå inn i innstillingene for hver port og skrive inn denne kommandoen, og EtherChannel-grensesnittgruppenummeret kan ha en verdi fra 1 til 6, det viktigste er at denne verdien er den samme for alle portene på bryteren. I tillegg må portene operere i de samme modusene: begge i tilgangsmodus eller begge i trunkmodus og ha samme opprinnelige VLAN eller tillatte VLAN.
EtherChannel-aggregering vil bare fungere hvis gruppen med kanaler består av identisk konfigurerte grensesnitt.
La oss koble bryter A med to kommunikasjonslinjer til bryter B, som også har to grensesnitt f0/1 og f0/2. Disse grensesnittene utgjør sin egen gruppe. Du kan konfigurere dem til å fungere i EtherChannel ved å bruke samme kommando, og gruppenummeret spiller ingen rolle, siden de er plassert på den lokale bryteren. Du kan angi denne gruppen som nummer 1, og alt vil fungere. Husk imidlertid - for at begge kanalene skal fungere uten problemer, må alle grensesnitt konfigureres nøyaktig likt, til samme modus - tilgang eller trunk. Etter at du har gått inn i innstillingene for begge grensesnittene til bryter A og bryter B og gått inn i kanalgruppe 1-modus på kommando, vil aggregeringen av EtherChannel-kanaler fullføres.
Begge fysiske grensesnittene til hver svitsj vil fungere som ett logisk grensesnitt. Hvis vi ser på STP-parametrene, vil vi se at svitsj A vil vise ett felles grensesnitt, gruppert fra to fysiske porter.
La oss gå videre til PAGP, en portaggregeringsprotokoll utviklet av Cisco.
La oss forestille oss det samme bildet - to brytere A og B, hver med grensesnitt f0/1 og f0/2, forbundet med to kommunikasjonslinjer. For å aktivere PAGP, bruk samme kommandokanal-gruppe 1-modus med parametere . I manuell statisk modus går du ganske enkelt inn i kanalgruppe 1-modus på kommando på alle grensesnitt, og aggregeringen begynner å fungere; her må du spesifisere ønsket eller auto-parameter. Hvis du går inn i kanalgruppe 1-moduskommandoen med ?-tegnet, vil systemet vise en melding med parameteralternativer: på, ønskelig, auto, passiv, aktiv.
Hvis du angir den samme ønskelige kommandoen i kanalgruppe 1-modus i begge ender av kommunikasjonslinjen, vil EtherChannel-modus aktiveres. Det samme vil skje hvis grensesnittene i den ene enden av kanalen er konfigurert med den ønskede kommandoen for kanalgruppe 1-modus, og i den andre enden med autokommandoen for kanalgruppe 1-modus.
Imidlertid, hvis grensesnittene i begge ender av koblingene er konfigurert til automatisk med kanalgruppe 1-modus autokommandoen, vil ikke koblingsaggregering forekomme. Husk derfor - hvis du ønsker å bruke EtherChannel over PAGP-protokollen, må grensesnittene til minst en av partene være i ønsket tilstand.
Når du bruker den åpne LACP-protokollen for kanalaggregering, brukes den samme kanalgruppe 1-moduskommandoen med parametere .
Mulige kombinasjoner av innstillinger på begge sider av kanalene er som følger: hvis grensesnittene er konfigurert til aktiv modus eller den ene siden til aktiv og den andre til passiv, vil EtherChannel-modusen fungere; hvis begge gruppene av grensesnitt er konfigurert til passiv, kanal aggregering vil ikke skje. Det må huskes at for å organisere kanalaggregering ved bruk av LACP-protokollen, må minst én av grensesnittgruppene være i aktiv tilstand.
La oss prøve å svare på spørsmålet: hvis vi har brytere A og B koblet sammen med kommunikasjonslinjer, og grensesnittene til en bryter er i aktiv tilstand, og den andre i automatisk eller ønskelig tilstand, vil EtherChannel fungere?
Nei, det vil det ikke, fordi nettverket må bruke samme protokoll - enten PAGP eller LACP, siden de ikke er kompatible med hverandre.
La oss se på flere kommandoer som brukes til å organisere en EtherChannel. Først av alt må du tildele et gruppenummer, det kan være hva som helst. For den første kommandoen kanalgruppe 1-modus kan du velge 5 parametere som et alternativ: på, ønskelig, auto, passiv eller aktiv.
I grensesnittunderkommandoer bruker vi nøkkelordet kanalgruppe, men hvis du for eksempel ønsker å spesifisere lastbalansering, brukes ordet port-kanal. La oss se på hva lastbalansering er.
Anta at vi har bryter A med to porter, som er koblet til de tilsvarende portene til bryter B. Tre datamaskiner er koblet til bryter B - 3, og en datamaskin nr. 1,2,3 er koblet til bryter A.
Når trafikken beveger seg fra datamaskin #4 til datamaskin #1, vil bryter A begynne å sende pakker på begge koblingene. Lastbalanseringsmetoden bruker hashing av avsenderens MAC-adresse slik at all trafikk fra den fjerde datamaskinen vil flyte gjennom kun én av de to koblingene. Hvis vi kobler datamaskin nr. 5 til bryter A, takket være lastbalansering, vil trafikken til denne datamaskinen bare bevege seg langs en, lavere kommunikasjonslinje.
Dette er imidlertid ikke en typisk situasjon. La oss si at vi har et nettsky og en enhet som bryter A med tre datamaskiner er koblet til. Internett-trafikk vil bli dirigert til bryteren med MAC-adressen til denne enheten, det vil si med adressen til en bestemt port, fordi denne enheten er en gateway. Dermed vil all utgående trafikk ha MAC-adressen til denne enheten.
Hvis vi foran bryter A plasserer bryter B, koblet til den med tre kommunikasjonslinjer, vil all trafikken til bryter B i retning av bryter A flyte langs en av linjene, som ikke oppfyller målene våre. Derfor må vi angi balanseringsparametere for denne bryteren.
For å gjøre dette, bruk port-channel load-balance-kommandoen, der destinasjons-IP-adressen brukes som alternativparameter. Hvis dette er adressen til datamaskin nr. 1, vil trafikken flyte langs den første linjen, hvis nr. 3 - langs den tredje, og hvis du angir IP-adressen til den andre datamaskinen, deretter langs den midterste kommunikasjonslinjen.
For å gjøre dette bruker kommandoen port-channel nøkkelordet i global konfigurasjonsmodus.
Hvis du vil se hvilke koblinger som er involvert i kanalen og hvilke protokoller som brukes, må du i privilegert modus angi kommandoen show etherchannel summary. Du kan vise lastbalanseringsinnstillingene ved å bruke kommandoen show etherchannel load-balance.
La oss nå se på alt dette i Packet Tracer-programmet. Vi har 2 brytere koblet sammen med to lenker. STP vil begynne å fungere og en av de 4 portene vil bli blokkert.
La oss gå til SW0-innstillingene og angi kommandoen show spanning-tree. Vi ser at STP fungerer og vi kan sjekke Root ID og Bridge ID. Ved å bruke den samme kommandoen for den andre bryteren, vil vi se at den første bryteren SW0 er roten, siden, i motsetning til SW1, dens rot- og bro-identifikatorverdier er de samme. I tillegg er det en melding her om at SW0 er roten - "Denne broen er roten".
Begge portene til rotsvitsjen er i utpekt tilstand, den blokkerte porten til den andre bryteren er utpekt som alternativ, og den andre er utpekt som rotporten. Du kan se hvordan STP gjør alt nødvendig arbeid feilfritt, og setter opp tilkoblingen automatisk.
La oss aktivere PAGP-protokollen; for å gjøre dette, i SW0-innstillingene, legger vi sekvensielt inn kommandoene int f0/1 og kanalgruppe 1-modus med en av 5 mulige parametere, jeg bruker ønskelig.
Du kan se at linjeprotokollen først ble deaktivert og deretter aktivert igjen, det vil si at endringene trådte i kraft og port-kanal 1-grensesnittet ble opprettet.
La oss nå gå til f0/2-grensesnittet og gå inn i samme kommandokanal-gruppe 1-modus som er ønskelig.
Du kan se at nå er portene til den øvre lenken indikert med en grønn markør, og portene til den nedre lenken er indikert med en oransje markør. I dette tilfellet kan det ikke være en blandet modus av ønskelige - automatiske porter, fordi alle grensesnittene til en svitsj må konfigureres med samme kommando. Automodusen kan brukes på den andre bryteren, men på den første må alle porter fungere i samme modus, i dette tilfellet er det ønskelig.
La oss gå inn i innstillingene til SW1 og bruke kommandoen for grensesnittområdet int range f0/1-2, for ikke å manuelt legge inn kommandoer separat for hvert av grensesnittene, men for å konfigurere begge med en kommando.
Jeg bruker kanalgruppe 2-moduskommandoen, men jeg kan bruke et hvilket som helst tall fra 1 til 6 for å angi gruppen av grensesnitt til den andre bryteren. Siden den motsatte siden av kanalen er konfigurert i ønsket modus, må grensesnittene til denne bryteren være i ønsket modus eller automatisk modus. Jeg velger den første parameteren, skriver inn kanalgruppe 2-modus ønskelig og trykker Enter.
Vi ser en melding om at kanalgrensesnitt Port-kanal 2 er opprettet, og portene f0/1 og f0/2 har sekvensielt flyttet fra ned-tilstand til opp-tilstand. Dette etterfølges av en melding om at port-kanal 2-grensesnittet har byttet til opp-tilstand og at linjeprotokollen til dette grensesnittet også er slått på. Nå har vi dannet en samlet EtherChannel.
Du kan bekrefte dette ved å gå til innstillingene til SW0-bryteren og gå inn i kommandoen vis eterkanalsammendrag. Du kan se de ulike flaggene som vi skal se på senere, og deretter gruppe 1 med 1 kanal, antall aggregatorer er også 1. Po1 betyr PortChannel 1, og betegnelsen (SU) står for S - lag 2 flagg, U - brukt. Følgende viser PAGP-protokollen som brukes og de fysiske portene aggregert i kanalen - Fa0/1 (P) og Fa0/2 (P), der P-flagget indikerer at disse portene er en del av PortChannel.
Jeg bruker de samme kommandoene for den andre bryteren, og CLI-vinduet viser lignende informasjon for SW1.
Jeg skriver inn kommandoen show spanning-tree i SW1-innstillingene, og du kan se at PortChannel 2 er et enkelt logisk grensesnitt, og kostnadene sammenlignet med kostnadene for to separate porter 19 har sunket til 9.
La oss gjøre det samme med den første bryteren. Du ser at rotparametrene ikke har endret seg, men nå mellom de to bryterne, i stedet for to fysiske koblinger, er det ett logisk grensesnitt Po1-Po2.
La oss prøve å erstatte PAGP med LACP. For å gjøre dette, i innstillingene til den første bryteren bruker jeg kommandoen for grensesnittområdet int range f0/1-2. Hvis jeg nå utsteder kanalgruppe1-modus aktiv kommando for å aktivere LACP, vil den bli avvist fordi portene Fa0/1 og Fa0/2 allerede er en del av en kanal som bruker en annen protokoll.
Derfor må jeg først angi kommandoen ingen kanalgruppe 1-modus aktiv og først deretter bruke kommandoen kanalgruppe1-modus aktiv. La oss gjøre det samme med den andre bryteren, først angi kommandoen ingen kanalgruppe 2, og deretter kommandoen kanalgruppe 2-modus aktiv. Hvis du ser på grensesnittparameterne, kan du se at Po2 er slått på igjen, men den er fortsatt i PAGP-protokollmodus. Dette er ikke sant, fordi vi for øyeblikket har LACP i kraft, og i dette tilfellet vises parametrene feil av Packet Tracer-programmet.
For å løse dette avviket bruker jeg en midlertidig løsning - å lage en annen PortChannel. For å gjøre dette, skriver jeg kommandoene int range f0/1-2 og ingen kanal-gruppe 2, og deretter kommandoen kanal-gruppe 2-modus aktiv. La oss se hvordan dette påvirker den første bryteren. Jeg går inn i kommandoen show etherchannel summary og ser at Po1 igjen vises som bruker PAGP. Dette er et problem i Packet Tracer-simuleringen fordi PortChannel for øyeblikket er deaktivert og vi burde ikke ha en kanal i det hele tatt.
Jeg går tilbake til CLI-vinduet til den andre bryteren og skriver inn kommandoen show etherchannel summary. Nå vises Po2 med en indeks (SD), der D betyr ned, det vil si at kanalen ikke fungerer. Teknisk sett er PortChannel til stede her, men den brukes ikke fordi det ikke er noen port knyttet til den.
Jeg skriver inn kommandoene int range f0/1-2 og ingen kanalgruppe 1 i innstillingene til den første bryteren, og oppretter deretter en ny kanalgruppe, denne gangen nummer 2, ved å bruke kanalgruppe 2-modus aktiv kommando. Så gjør jeg det samme i innstillingene til den andre bryteren, bare nå får kanalgruppen nummer 1.
Nå er det opprettet en ny gruppe, Port Channel 2, på den første svitsjen, og Port Channel 1 på den andre. Jeg byttet ganske enkelt navnene på gruppene. Som du kan se, har jeg teknisk opprettet en ny portkanal på den andre bryteren, og nå vises den med riktig parameter - etter å ha skrevet inn kommandoen show etherchannel summary, ser vi at Po1 (SU) bruker LACP.
Vi ser nøyaktig det samme bildet i CLI-vinduet til bryteren SW0 - den nye gruppen Po2 (SU) opererer under LACP-kontroll.
Tenk på forskjellen mellom et grensesnitt som er i aktiv tilstand og et grensesnitt som alltid er på. Jeg vil opprette en ny kanalgruppe for bryteren SW0 med kommandoene int range f0/1-2 og kanalgruppe 3-modus på. Før dette må du slette kanalgruppe 1 og 2 ved å bruke kommandoene ingen kanalgruppe 1 og ingen kanalgruppe 2, ellers, når du prøver å bruke kanalgruppe 3-modus på kommando, vil systemet vise en melding som sier at grensesnittet er allerede brukt til å jobbe med en annen kanalprotokoll.
Vi gjør det samme med den andre bryteren - slett kanalgruppe 1 og 2 og lag gruppe 3 med kommandoen kanalgruppe 3-modus på. La oss nå gå til innstillingene til SW0 og bruke kommandoen show etherchannel summary. Du vil se at den nye Po3-kanalen allerede er oppe og går og ikke krever noen foreløpige operasjoner som PAGP eller LACP.
Den slås på umiddelbart, uten å deaktivere og deretter aktivere porter. Ved å bruke samme kommando for SW1 vil vi se at her bruker ikke Po3 noen protokoll, det vil si at vi har laget en statisk EtherChannel.
Cisco hevder at for at nettverk skal være allment tilgjengelige, må vi glemme PAGP og bruke statisk EtherChannel som en mer pålitelig måte for koblingsaggregering.
Hvordan gjør vi lastbalansering? Jeg går tilbake til SW0-svitsj CLI-vinduet og skriver inn kommandoen show etherchannel load-balance. Du kan se at lastbalanseringen gjøres basert på kildens MAC-adresse.
Vanligvis bruker balansering denne parameteren, men noen ganger passer den ikke til våre formål. Hvis vi ønsker å endre denne balanseringsmetoden, må vi gå inn i den globale konfigurasjonsmodusen og angi port-kanal load-balance kommandoen, hvoretter systemet vil vise ledetekster med mulige parametere for denne kommandoen.
Hvis du spesifiserer port-channel load-balance src-mac-parameteren, det vil si spesifisere kilde-MAC-adressen, vil en hashing-funksjon bli aktivert, som da vil indikere hvilken av portene som er en del av en gitt EtherChannel som skal brukes til å trafikk fremover. Når kildeadressen er den samme, vil systemet bruke det spesifikke fysiske grensesnittet for å sende trafikk.
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, 30 % rabatt for Habr-brukere på en unik analog av inngangsnivåservere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2 ganger billigere? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com