3.0. Point-to-Point verbindingen

3.0.1. Inleiding

Een van de meest voorkomende typen WAN-verbindingen, vooral bij communicatie over lange afstanden, is een punt-naar-punt-verbinding, ook wel een seriële of huurlijnverbinding genoemd. Omdat deze verbindingen doorgaans worden geleverd door een vervoerder, zoals een telefoonmaatschappij, moeten de grenzen tussen wat door de vervoerder wordt beheerd en wat door de klant wordt beheerd, duidelijk worden vastgesteld.

Dit hoofdstuk behandelt de termen, technologie en protocollen die bij seriële verbindingen worden gebruikt. De High-Level Data Link Control (HDLC) en Point-to-Point Protocol (PPP) worden geïntroduceerd. HDLC is het standaardprotocol op een seriële interface van een Cisco-router. PPP is een protocol dat authenticatie, compressie en foutdetectie kan verwerken; kwaliteit van de verbinding bewaken; en logisch meerdere seriële verbindingen bundelen om de belasting te delen.

3.1. Serieel Point-to-Point-overzicht

3.1.1. Seriële communicatie

3.1.1.1. Seriële en parallelle poorten

Een veelvoorkomend type WAN-verbinding is de point-to-point-verbinding. Zoals weergegeven in volgende afbeelding, worden point-to-point-verbindingen gebruikt om LAN’s te verbinden met WAN’s van serviceproviders en om LAN-segmenten binnen een bedrijfsnetwerk te verbinden.

Seriële point-to-point verbinding

Een LAN-naar-WAN point-to-point verbinding wordt ook wel seriële verbinding of huurlijnverbinding genoemd. De reden is dat de lijnen worden gehuurd van een vervoerder (meestal een telefoonmaatschappij) en bestemd zijn voor gebruik door het bedrijf dat de lijnen huurt. Bedrijven betalen voor een continue verbinding tussen twee externe locaties en de lijn is continu actief en beschikbaar.

Huurlijnen zijn een veelgebruikt type WAN-toegang en de prijs ervan is over het algemeen gebaseerd op de vereiste bandbreedte en de afstand tussen de twee aangesloten punten.

Begrijpen hoe point-to-point seriële communicatie via een huurlijn werkt, is belangrijk voor een algemeen begrip van hoe WAN’s werken.

Communicatie via een seriële verbinding is een methode voor gegevensoverdracht waarbij de bits opeenvolgend over een enkel kanaal worden verzonden. Stel je de taak voor om ballen van de ene bak naar de andere te verplaatsen via een pijp die slechts breed genoeg is om één bal tegelijk te passen. Er kunnen meerdere ballen in de pijp, maar slechts één tegelijk, en ze hebben maar één uitgang, het andere uiteinde van de pijp. Een seriële poort is bidirectioneel en wordt vaak een bidirectionele poort of een communicatiepoort genoemd.

Deze seriële communicatie is in tegenstelling tot parallelle communicatie waarbij bits gelijktijdig over meerdere draden kunnen worden verzonden. Onderstaande afbeelding illustreert het verschil tussen seriële en parallelle verbindingen.

Een parallelle verbinding draagt ​​in theorie acht keer sneller gegevens over dan een seriële verbinding. Op basis van deze theorie verzendt een parallelle verbinding een byte (acht bits) in de tijd dat een seriële verbinding een enkele bit verzendt. Parallelle communicatie heeft echter problemen met overspraak over draden, vooral als de draadlengte toeneemt. Klok scheeftrekken is ook een probleem met parallelle communicatie. Klokscheefstand treedt op wanneer gegevens over de verschillende draden niet op hetzelfde moment aankomen, waardoor synchronisatieproblemen ontstaan.

Ten slotte ondersteunen veel parallelle communicaties alleen eenrichtingscommunicatie, alleen uitgaand, maar sommige ondersteunen half-duplexcommunicatie (tweerichtingscommunicatie, maar slechts in één richting tegelijk).

Seriële en paralelle communicatie

Ooit hadden de meeste pc’s zowel seriële als parallelle poorten. Parallelle poorten werden gebruikt om printers, computers en andere apparaten aan te sluiten die een relatief hoge bandbreedte nodig hadden. Parallelle poorten werden ook gebruikt tussen interne componenten. Voor externe communicatie werd voornamelijk een seriële bus gebruikt om verbinding te maken met telefoonlijnen en apparaten die mogelijk een grotere afstand zouden kunnen hebben dan een parallelle overdracht mogelijk zou maken. Omdat seriële communicatie minder complex is en eenvoudigere schakelingen vereist, is seriële communicatie aanzienlijk goedkoper om te implementeren. Seriële communicatie verbruikt minder draden, goedkopere kabels en minder connectorpinnen.

Op de meeste pc’s zijn parallelle poorten en RS-232 seriële poorten vervangen door de hogere snelheid seriële universele seriële bus (USB)-interfaces. Voor communicatie over lange afstand gebruiken veel WAN’s ook seriële transmissie.

3.1.1.2. Seriële communcatie

De afbeelding toont een eenvoudige weergave van seriële communicatie via een WAN. Gegevens worden ingekapseld door het communicatieprotocol dat wordt gebruikt door de verzendende router. Het ingekapselde frame wordt op een fysiek medium naar het WAN gestuurd. Er zijn verschillende manieren om het WAN te doorkruisen, maar de ontvangende router gebruikt hetzelfde communicatieprotocol om het frame uit te kapselen wanneer het aankomt.

Serieel communicatieproces

Er zijn veel verschillende seriële communicatiestandaarden, die elk een andere signaleringsmethode gebruiken. Er zijn drie belangrijke seriële communicatiestandaarden die van invloed zijn op LAN-naar-WAN-verbindingen:

  • RS-232 – De meeste seriële poorten op personal computers voldoen aan de RS-232C of nieuwere RS-422- en RS-423-normen. Er worden zowel 9-pins als 25-pins connectoren gebruikt. Een seriële poort is een interface voor algemeen gebruik die voor bijna elk type apparaat kan worden gebruikt, inclusief modems, muizen en printers. Dit soort randapparatuur voor computers is vervangen door nieuwe en snellere standaarden zoals USB, maar veel netwerkapparaten gebruiken RJ-45-connectoren die voldoen aan de oorspronkelijke RS-232-standaard.
  • V.35 – Deze ITU-standaard voor snelle, synchrone gegevensuitwisseling wordt doorgaans gebruikt voor modem-naar-multiplexercommunicatie en combineert de bandbreedte van verschillende telefooncircuits. In de VS is V.35 de interfacestandaard die wordt gebruikt door de meeste routers en DSU’s die verbinding maken met T1-carriers. V.35-kabels zijn snelle seriële assemblages die zijn ontworpen om hogere gegevenssnelheden en connectiviteit tussen DTE’s en DCE’s via digitale lijnen te ondersteunen. Verderop in dit gedeelte vindt u meer over DTE’s en DCE’s.
  • HSSI – Een High-Speed ​​Serial Interface (HSSI) ondersteunt overdrachtssnelheden tot 52 Mb/s. Ingenieurs gebruiken HSSI om routers op LAN’s te verbinden met WAN’s via hogesnelheidslijnen, zoals T3-lijnen. Ingenieurs gebruiken ook HSSI om snelle connectiviteit tussen LAN’s te bieden, met behulp van Token Ring of Ethernet. HSSI is een DTE/DCE-interface die is ontwikkeld door Cisco Systems en T3 plus Networking om tegemoet te komen aan de behoefte aan snelle communicatie via WAN-verbindingen.

3.1.1.3. Punt-naar-punt communicatieverbindingen

Wanneer permanente specifieke verbindingen vereist zijn, wordt een point-to-point-link gebruikt om een ​​enkel, vooraf vastgesteld WAN-communicatiepad te bieden. Dit pad gaat van de locatie van de klant, via het netwerk van de provider, naar een externe bestemming, zoals weergegeven in de volgende afbeelding.

Point-to-Point communicatieverbindingen

Een point-to-point-verbinding kan twee geografisch ver verwijderde locaties met elkaar verbinden, zoals een hoofdkantoor in New York en een regionaal kantoor in Londen. Voor een punt-tot-puntlijn zet de vervoerder specifieke middelen in voor een lijn die door de klant wordt gehuurd (huurlijn).

Opmerking: Point-to-point verbindingen zijn niet beperkt tot verbindingen die over land gaan. Honderdduizenden kilometers onderzeese glasvezelkabels verbinden landen en continenten over de hele wereld. Een zoekopdracht op internet van “onderzeese internetkabelkaart” levert verschillende kabelkaarten op van deze onderzeese verbindingen.

Point-to-point-links zijn meestal duurder dan gedeelde services. De kosten van huurlijnoplossingen kan aanzienlijk worden wanneer ze worden gebruikt om veel locaties over steeds grotere afstanden met elkaar te verbinden; soms wegen de voordelen echter op tegen de kosten van de huurlijn. De speciale capaciteit verwijdert latentie of jitter tussen de eindpunten. Constante beschikbaarheid is essentieel voor sommige toepassingen zoals spraak of video over IP.

3.1.1.4. Time-Division Multiplexing

Met een huurlijn maakt de vervoerder, ondanks het feit dat klanten betalen voor speciale diensten, en speciale bandbreedte aan de klant, nog steeds gebruik van multiplextechnologieën binnen het netwerk. Multiplexing verwijst naar een schema waarmee meerdere logische signalen een enkel fysiek kanaal kunnen delen. Twee veel voorkomende soorten multiplexing zijn multiplexing met tijdverdeling (TDM) en statistische multiplexing met tijdverdeling (STDM).

TDM

Bell Laboratories heeft TDM oorspronkelijk uitgevonden om de hoeveelheid spraakverkeer over een medium te maximaliseren. Voor het multiplexen had elk telefoongesprek zijn eigen fysieke verbinding nodig. Dit was een dure en onschaalbare oplossing. TDM verdeelt de bandbreedte van een enkele link in aparte tijdsloten. TDM verzendt twee of meer kanalen (datastroom) via dezelfde link door een ander tijdslot toe te wijzen voor de verzending van elk kanaal. In feite gebruiken de kanalen om de beurt de link.

TDM is een fysiek laagconcept. Het houdt geen rekening met de aard van de informatie die naar het uitgangskanaal wordt gemultiplext. TDM is onafhankelijk van het Layer 2-protocol dat door de ingangskanalen is gebruikt.

TDM kan worden verklaard door een analogie met snelwegverkeer. Om verkeer van vier wegen naar een andere stad te vervoeren, kan al het verkeer op één rijstrook worden gestuurd als de wegen even goed zijn onderhouden en het verkeer is gesynchroniseerd. Als elk van de vier wegen elke vier seconden een auto op de snelweg plaatst, krijgt de snelweg een auto met een snelheid van één per seconde. Zolang de snelheid van alle auto’s synchroon loopt, is er geen aanrijding. Op de bestemming gebeurt het omgekeerde en worden de auto’s van de snelweg gehaald en door hetzelfde synchrone mechanisme naar de lokale wegen gevoerd.

Dit is het principe dat wordt gebruikt in synchrone TDM bij het verzenden van gegevens via een link. TDM vergroot de capaciteit van de transmissielink door de transmissietijd te verdelen in kleinere, gelijke intervallen, zodat de link de bits van meerdere invoerbronnen overdraagt.

In de afbeelding accepteert een multiplexer (MUX) bij de zender drie afzonderlijke signalen. De MUX verdeelt elk signaal in segmenten. De MUX plaatst elk segment in een enkel kanaal door elk segment in een tijdslot in te voegen.

Time-Division Multiplexing

Een MUX aan de ontvangende kant assembleert de TDM-stroom opnieuw in de drie afzonderlijke gegevensstromen, alleen gebaseerd op de timing van de aankomst van elk bit. Een techniek die bitinterleaving wordt genoemd, houdt het aantal en de volgorde van de bits van elke specifieke transmissie bij, zodat ze bij ontvangst snel en efficiënt in hun oorspronkelijke vorm kunnen worden teruggeplaatst. Byte-interleaving voert dezelfde functies uit, maar omdat er acht bits in elke byte zitten, heeft het proces een groter of langer tijdslot nodig.

3.1.1.5. Statistical Time-Division Multiplexing

Vergelijk in een andere analogie TDM met een trein met 32 treinwagons. Elke wagon is eigendom van een ander vrachtbedrijf en elke dag vertrekt de trein met de 32 wagons eraan vast. Als een van de bedrijven vracht heeft om te verzenden, wordt de auto geladen. Als het bedrijf niets te sturen heeft, blijft de auto leeg, maar blijft in de trein. Het verschepen van lege containers is niet erg efficiënt. TDM deelt deze inefficiëntie wanneer het verkeer intermitterend is, omdat het tijdslot nog steeds wordt toegewezen, zelfs als het kanaal geen gegevens heeft om te verzenden.

STDM

STDM is ontwikkeld om deze inefficiëntie te overwinnen. STDM gebruikt een variabele tijdslotlengte waardoor kanalen kunnen strijden om elke vrije slotruimte. Het maakt gebruik van een buffergeheugen dat de gegevens tijdelijk opslaat tijdens piekmomenten. STDM verspilt geen hogesnelheidslijntijd met inactieve kanalen die dit schema gebruiken. STDM vereist dat elke uitzending identificatie-informatie of een kanaalidentificatie draagt.

Statistical TIme-Division Multiplexing

3.1.1.6. TDM voorbeelden

SONET en SDH

Op grotere schaal gebruikt de telecommunicatie-industrie de Synchronous Optical Networking (SONET) of Synchronous Digital Hierarchy (SDH) standaard voor optisch transport van TDM-gegevens. SONET, dat in Noord-Amerika wordt gebruikt, en SDH, dat elders wordt gebruikt, zijn twee nauw verwante standaarden die interfaceparameters, snelheden, frameformaten, multiplexmethoden en beheer voor synchrone TDM via glasvezel specificeren.

De afbeelding toont SONET, wat een voorbeeld is van STDM. SONET/SDH neemt n bitstreams, multiplext ze en moduleert de signalen optisch. Vervolgens verzendt het de signalen met behulp van een lichtgevend apparaat via glasvezel met een bitsnelheid die gelijk is aan (inkomende bitsnelheid) x n. Dus verkeer dat vanaf vier plaatsen bij de SONET-multiplexer aankomt met 2,5 Gb/s, gaat uit als een enkele stream met 4 x 2,5 Gb/s of 10 Gb/s. Dit principe wordt geïllustreerd in de figuur, die een toename van de bitsnelheid met een factor vier laat zien in tijdslot T.

TDM voorbeeld: SONET

3.1.1.7. Demarcatiepunt

Vóór de deregulering in Noord-Amerika en andere landen waren telefoonmaatschappijen eigenaar van het aansluitnet, inclusief de bedrading en apparatuur op het terrein van de klanten. Het aansluitnet verwijst naar de lijn van het pand van een telefoonabonnee naar het centrale kantoor van de telefoonmaatschappij. Deregulering dwong telefoonbedrijven om hun aansluitnetwerkinfrastructuur te ontbundelen, zodat andere leveranciers apparatuur en diensten konden leveren. Dit leidde tot de noodzaak om af te bakenen welk deel van het netwerk het telefoonbedrijf bezat en welk deel de klant bezat. Dit afbakeningspunt is het demarcatiepunt of demarc. Het demarcatiepunt markeert het punt waar uw netwerk wordt gekoppeld aan een netwerk dat eigendom is van een andere organisatie. In telefoonterminologie is dit de interface tussen Customer Premises Equipment (CPE) en apparatuur van netwerkserviceproviders. Het demarcatiepunt is het punt in het netwerk waar de verantwoordelijkheid van de serviceprovider eindigt, zoals weergegeven in de volgende afbeelding.

Demarcatiepunt

De verschillen in demarcatiepunten kunnen het beste worden weergegeven met ISDN. In de Verenigde Staten levert een serviceprovider het aansluitnet in de gebouwen van de klant en levert de klant de actieve apparatuur zoals de CSU/DSU waarop het aansluitnet wordt afgesloten. Deze beëindiging gebeurt vaak in een telecommunicatiekast en de klant is verantwoordelijk voor het onderhouden, vervangen of repareren van de apparatuur. In andere landen wordt de Network Terminating Unit (NTU) geleverd en beheerd door de serviceprovider. Hierdoor kan de serviceprovider het aansluitnet actief beheren en problemen oplossen met het demarcatiepunt dat zich na de NTU voordoet. De klant sluit een CPE-apparaat, zoals een router of Frame Relay-toegangsapparaat, aan op de NTU met behulp van een V.35 of RS-232 seriële interface.

Voor elke huurlijnverbinding is een seriële routerpoort vereist. Als het onderliggende netwerk is gebaseerd op de T-carrier- of E-carrier-technologieën, wordt de huurlijn via een CSU/DSU aangesloten op het netwerk van de carrier. Het doel van de CSU/DSU is om een ​​kloksignaal te leveren aan de interface van de klantapparatuur vanaf de DSU en om de gekanaliseerde transportmedia van de drager op de CSU te beëindigen. De CSU biedt ook diagnostische functies, zoals een loopback-test.

Zoals te zien is in de volgende afbeelding, bevatten de meeste T1- of E1 TDM-interfaces op huidige routers CSU/DSU-mogelijkheden. Een aparte CSU/DSU is niet nodig omdat deze functionaliteit is ingebed in de interface. IOS-opdrachten worden gebruikt om de CSU/DSU-bewerkingen te configureren.

T1/E1 met ingebouwde CSU/DSU

3.1.1.8. DTE-DCE

Vanuit het oogpunt van verbinding met het WAN, heeft een seriële verbinding een DTE-apparaat aan het ene uiteinde van de verbinding en een DCE-apparaat aan het andere uiteinde. De verbinding tussen de twee DCE-apparaten is het transmissienetwerk van de WAN-serviceprovider, zoals weergegeven in de afbeelding. In dit voorbeeld:

  • De CPE, die over het algemeen een router is, is de DTE. De DTE kan ook een terminal, computer, printer of faxapparaat zijn als ze rechtstreeks verbinding maken met het netwerk van de serviceprovider.
  • De DCE, gewoonlijk een modem of CSU/DSU, is het apparaat dat wordt gebruikt om de gebruikersgegevens van de DTE om te zetten in een vorm die acceptabel is voor de transmissielink van de WAN-serviceprovider. Dit signaal wordt ontvangen op de externe DCE, die het signaal terug in een reeks bits decodeert. De externe DCE geeft deze volgorde vervolgens door aan de externe DTE.

De Electronics Industry Association (EIA) en de International Telecommunication Union Telecommunications Standardization Sector (ITU-T) zijn het meest actief geweest bij de ontwikkeling van standaarden waarmee DTE’s kunnen communiceren met DCE’s.

Seriële DCE en DTE WAN verbindingen

3.1.1.9. Seriële kabels

Oorspronkelijk was het concept van DCE’s en DTE’s gebaseerd op twee soorten apparatuur: eindapparatuur die gegevens opwekte of ontving, en de communicatieapparatuur die alleen gegevens doorstuurde. Bij de ontwikkeling van de RS-232-standaard waren er redenen waarom 25-pins RS-232-connectoren op deze twee soorten apparatuur anders moesten worden aangesloten. Deze redenen zijn niet langer belangrijk, maar er zijn nog twee verschillende soorten kabels over: een om een ​​DTE op een DCE aan te sluiten en een andere om twee DTE’s rechtstreeks op elkaar aan te sluiten.

De DTE/DCE-interface voor een bepaalde standaard definieert de volgende specificaties:

  • Mechanisch/fysiek – Aantal pinnen en type connector
  • Elektrisch – Definieert spanningsniveaus voor 0 en 1
  • Functioneel – Specificeert de functies die worden uitgevoerd door betekenissen toe te kennen aan elk van de signaleringslijnen in de interface
  • Procedureel – Specificeert de volgorde van gebeurtenissen voor het verzenden van gegevens

De oorspronkelijke RS-232-standaard definieerde alleen de verbinding van DTE’s met DCE’s, dit waren modems. Als u echter twee DTE’s wilt aansluiten, zoals twee computers of twee routers in een laboratorium, is er geen DCE nodig met een speciale kabel, een nulmodem genaamd. Met andere woorden, de twee apparaten kunnen zonder modem worden aangesloten. Een nulmodem is een communicatiemethode om twee DTE’s rechtstreeks met elkaar te verbinden via een seriële RS-232-kabel. Bij een null-modemverbinding zijn de zend- (Tx) en ontvang (Rx) lijnen onderling verbonden zoals weergegeven in figuur 1.

Null-modem om twee DTE’s te verbinden

De kabel voor de DTE naar DCE verbinding is een afgeschermde seriële overgangskabel. Het routeruiteinde van de afgeschermde seriële overgangskabel kan een DB-60-connector zijn, die wordt aangesloten op de DB-60-poort op een seriële WAN-interfacekaart, zoals weergegeven in de volgende afbeelding. Het andere uiteinde van de seriële overgangskabel is verkrijgbaar met de connector geschikt voor de te gebruiken standaard.

DB-60 routerverbinding

De WAN-provider of de CSU/DSU dicteert dit type kabel meestal. Cisco-apparaten ondersteunen de seriële standaarden EIA/TIA-232, EIA/TIA-449, V.35, X.21 en EIA/TIA-530, zoals weergegeven in volgende afbeelding.

WAN seriële verbindingsopties

Om hogere poortdichtheden in een kleinere vormfactor te ondersteunen, heeft Cisco een Smart Serial-kabel geïntroduceerd, zoals weergegeven in afbeelding 4. Het routerinterface-uiteinde van de Smart Serial-kabel is een 26-pins connector die aanzienlijk compacter is dan de DB-60 aansluiting.

Smart seriële connector

Bij gebruik van een nulmodem hebben synchrone verbindingen een kloksignaal nodig. Een extern apparaat kan het signaal genereren, of een van de DTE’s kan het kloksignaal genereren. Wanneer een DTE en DCE zijn aangesloten, is de seriële poort op een router standaard het DTE-uiteinde van de verbinding en wordt het kloksignaal doorgaans geleverd door een CSU/DSU of vergelijkbaar DCE-apparaat. Wanneer u echter een nulmodemkabel gebruikt in een router-naar-router-verbinding, moet een van de seriële interfaces worden geconfigureerd als het DCE-uiteinde om het kloksignaal voor de verbinding te leveren, zoals weergegeven in afbeelding 5.

Smart seriële connector

3.1.1.10. Seriële bandbreedte

Bandbreedte verwijst naar de snelheid waarmee gegevens worden overgedragen via de communicatieverbinding. De onderliggende carrier-technologie bepaalt hoeveel bandbreedte beschikbaar is. Er is een verschil in bandbreedtepunten tussen de Noord-Amerikaanse (T-carrier) specificatie en het Europese (E-carrier) systeem. Optische netwerken gebruiken ook een andere bandbreedtehiërarchie, die weer verschilt tussen Noord-Amerika en Europa. In de Verenigde Staten definieert optische drager (OC) de bandbreedtepunten.

In Noord-Amerika wordt de bandbreedte meestal uitgedrukt als een digitaal signaalniveau (DS)-nummer (DS0, DS1, enzovoort), dat verwijst naar de snelheid en het formaat van het signaal. De meest fundamentele lijnsnelheid is 64 kb/s, of DS0, de bandbreedte die nodig is voor een ongecomprimeerd, gedigitaliseerd telefoongesprek. Seriële verbindingsbandbreedtes kunnen stapsgewijs worden verhoogd om tegemoet te komen aan de behoefte aan snellere transmissie. Er kunnen bijvoorbeeld 24 DS0’s worden gebundeld om een ​​DS1-lijn (ook wel T1-lijn genoemd) te krijgen met een snelheid van 1.544 Mb/s. Ook kunnen 28 DS1’s worden gebundeld tot een DS3-lijn (ook wel T3-lijn genoemd) met een snelheid van 44.736 Mb/s. Huurlijnen zijn verkrijgbaar in verschillende capaciteiten en worden over het algemeen geprijsd op basis van de benodigde bandbreedte en de afstand tussen de twee aangesloten punten.

OC-transmissiesnelheden zijn een reeks gestandaardiseerde specificaties voor de transmissie van digitale signalen die via SONET-glasvezelnetwerken worden verzonden. De aanduiding maakt gebruik van OC, gevolgd door een geheel getal dat de basistransmissiesnelheid van 51,84 Mb/s vertegenwoordigt. OC-1 heeft bijvoorbeeld een transmissiecapaciteit van 51,84 Mb/s, terwijl een OC-3 transmissiemedium drie keer 51,84 Mb/s of 155,52 Mb/s zou zijn.

Tabel 2-1 geeft een overzicht van de meest voorkomende lijntypen en de bijbehorende bitsnelheidscapaciteit van elk.

LijntypeBitsnelheidscapaciteit
5656 kb/s
6464 kb/s
T11.544 Mb/s
E12.048 Mb/s
J12.048 Mb/s
E334.064 Mb/s
T344.736 Mb/s
OC-151.84 Mb/s
OC-3155.54 Mb/s
OC-9466.56 Mb/s
OC-12622.08 Mb/s
OC-18933.12 Mb/s
OC-241.244 Gb/s
OC-361.866 Gb/s
OC-482.488 Gb/s
OC-964.976 Gb/s
OC-1929.954 Gb/s
OC-76839.813 Gb/s

Opmerking: E1 (2.048 Mb/s) en E3 (34.368 Mb/s) zijn Europese standaarden zoals T1 en T3, maar met verschillende bandbreedtes en framestructuren.

3.1.2. HDLC-inkapseling

3.1.2.1. WAN-inkapselingsprotocollen

Op elke WAN-verbinding worden gegevens ingekapseld in frames voordat ze de WAN-link kruisen. Om ervoor te zorgen dat het juiste protocol wordt gebruikt, moet u het juiste Layer 2-inkapselingstype configureren. De keuze van het protocol hangt af van de WAN-technologie en de communicatieapparatuur. De volgende afbeelding toont de meest voorkomende WAN-protocollen en waar ze worden gebruikt.

WAN inkapselingsprotocollen

Hieronder volgen korte beschrijvingen van elk type WAN-protocol:

  • HDLC – dit protocol is het standaard inkapselingstype voor punt-naar-punt-verbindingen, speciale koppelingen en circuitgeschakelde verbindingen wanneer de koppeling twee Cisco-apparaten gebruikt. HDLC is nu de basis voor synchrone PPP die door veel servers wordt gebruikt om verbinding te maken met een WAN, meestal internet.
  • PPP – Dit protocol biedt router-naar-router- en host-naar-netwerkverbindingen via synchrone circuits en asynchrone circuits. PPP werkt met verschillende netwerklaagprotocollen, zoals IPv4 en IPv6. PPP is gebaseerd op het HDLC-inkapselingsprotocol, maar heeft ook ingebouwde beveiligingsmechanismen zoals Password Authentication Protocol (PAP) en Challenge Handshake Authentication Protocol (CHAP).
    Serial Line Internet Protocol (SLIP): Dit standaardprotocol voor point-to-point seriële verbindingen maakt gebruik van TCP/IP. SLIP is grotendeels verdrongen door PPP.
  • X.25 – Deze ITU-T-standaard definieert hoe verbindingen tussen een DTE en DCE worden onderhouden voor externe terminaltoegang en computercommunicatie in openbare datanetwerken. X.25 specificeert Link Access Procedure, Balanced (LAPB), een datalinklaagprotocol. X.25 is een voorloper van Frame Relay.
    Frame Relay: dit industriestandaard, geschakelde datalinklaagprotocol verwerkt meerdere virtuele circuits. Frame Relay is een protocol van de volgende generatie na X.25. Frame Relay elimineert enkele van de tijdrovende processen (zoals foutcorrectie en flow control) die in X.25 worden gebruikt.
  • ATM – dit is de internationale standaard voor celrelay waarbij apparaten meerdere soorten diensten, zoals spraak, video of data, verzenden in cellen met een vaste lengte (53 bytes). Cellen met een vaste lengte maken verwerking in hardware mogelijk, waardoor transitvertragingen worden verminderd. ATM maakt gebruik van snelle transmissiemedia zoals E3, SONET en T3.

HDLC en PPP staan ​​centraal in deze cursus. De andere vermelde WAN-protocollen worden beschouwd als legacy-technologieën of vallen buiten het bestek van deze cursus.

3.1.2.2. HDLC-inkapseling

HDLC is een bitgeoriënteerd synchroon datalinklaagprotocol ontwikkeld door de International Organization for Standardization (ISO). De huidige standaard voor HDLC is ISO 13239. HDLC is ontwikkeld op basis van de Synchronous Data Link Control (SDLC)-standaard die in de jaren zeventig werd voorgesteld. HDLC biedt zowel verbindingsgerichte als verbindingsloze service.

HDLC gebruikt synchrone seriële transmissie om foutloze communicatie tussen twee punten te bieden. HDLC definieert een Layer 2 framing-structuur die flowcontrole en foutcontrole mogelijk maakt door het gebruik van bevestigingen. Elk frame heeft hetzelfde formaat, of het nu een dataframe of een controleframe is.

Wanneer frames worden verzonden via synchrone of asynchrone links, hebben die links geen mechanisme om het begin of einde van frames te markeren. Om deze reden gebruikt HDLC een framebegrenzer of vlag om het begin en het einde van elk frame te markeren.

Cisco heeft een uitbreiding van het HLDC-protocol ontwikkeld om het onvermogen om multiprotocol-ondersteuning te bieden op te lossen. Hoewel Cisco HLDC (ook wel cHDLC genoemd) eigendom is, heeft Cisco veel andere leveranciers van netwerkapparatuur toestemming gegeven om het te implementeren. Cisco HDLC-frames bevatten een veld voor het identificeren van het netwerkprotocol dat wordt ingekapseld. De volgende afbeelding vergelijkt standaard HLDC met Cisco HLDC.

Standaard en Cisco HLDC frameformaat

3.1.2.3. HDLC-inkapseling configureren

Cisco HDLC is de standaard inkapselingsmethode die Cisco-apparaten gebruiken op synchrone seriële lijnen.
Gebruik Cisco HDLC als een Point-to-Point-protocol op huurlijnen tussen twee Cisco-apparaten. Gebruik synchrone PPP als u niet-Cisco-apparaten aansluit.

Als de standaard inkapselingsmethode is gewijzigd, gebruikt u de opdracht encapsulation hdlc-interfaceconfiguratiemodus om HDLC opnieuw in te schakelen.
Voorbeeld 2-1 laat zien hoe u HDLC opnieuw kunt inschakelen op een seriële interface.

Voorbeeld 2-1 HDLC-inkapseling configureren

Router(config)# interface s0/0/0
Router(config-if)# encapsulation hdlc

3.1.2.4. HDLC-inkapseling configureren

Cisco HDLC is de standaard inkapselingsmethode die wordt gebruikt door Cisco-apparaten op synchrone seriële lijnen.

Gebruik Cisco HDLC als een point-to-point-protocol op huurlijnen tussen twee Cisco-apparaten. Gebruik synchrone PPP als u niet-Cisco-apparaten aansluit.

Als de standaard inkapselingsmethode is gewijzigd, gebruikt u de opdracht encapsulation hdlc in de bevoorrechte EXEC-modus om HDLC opnieuw in te schakelen.

Router(config)# interface s0/0/0
Router(config-if)# encapsulation hdlc

Zoals weergegeven in het voorbeeld, zijn er twee stappen om HDLC-inkapseling opnieuw in te schakelen:

Stap 1. Ga naar de interfaceconfiguratiemodus van de seriële interface.

Stap 2. Voer de opdracht encapsulation hdlc in om het inkapselingsprotocol op de interface op te geven.

3.1.2.5. Problemen met een seriële interface oplossen

De uitvoer van het seriële commando show interfaces geeft informatie weer die specifiek is voor seriële interfaces. Voeg het specifieke interfacenummer toe dat u wilt onderzoeken, zoals show interface serial 0/0/0. Wanneer HDLC is geconfigureerd, moet encapsulation HDLC getoond worden in de uitvoer, zoals gemarkeerd in het volgend voorbeeld. Het gemarkeerde gedeelte, Serial 0/0/0 is up, line protocol is up, geeft aan dat de lijn actief is en werkt, terwijl het gemarkeerde gedeelte encapsulation HDLC aangeeft dat de standaard seriële inkapseling (HDLC) is ingeschakeld.

R1# show interface serial 0/0/0
Serial0/0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 172.16.0.1/30
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set Keepalive set (10 sec)
  CRC checking enabled
  Last input 00:00:05, output 00:00:04, output hang never Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max/total/threshold/drops)
    Conversations 0/1/256 (active/max active/max total)
    Reserved Conversations 0/0 (allocated/max allocated)
    Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
    5 packets input, 1017 bytes, 0 no buffer Received 5 broadcasts (0 IP multicasts)
    0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
 0 abort
    4 packets output, 395 bytes, 0 underruns
    0 output errors, 0 collisions, 4 interface resets
    0 unknown protocol drops
    0 output buffer failures, 0 output buffers swapped
 out
    2 carrier transitions
    DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

De opdracht show interfaces serial retourneert een van de zes mogelijke toestanden:

  • Serial x is up, line protocol is up
  • Serial x is down, line protocol is down (DTE-mode)
  • Serial x is up, line protocol is down (DTE-mode)
  • Serial x is up, line protocol is down (DCE-mode)
  • Serie x is omhoog, line protocol is up (looped )
  • Serial x is up, line protocol is down (disabled)
  • Serial x is administratively down, line protocol is down

Van de zeven mogelijke toestanden zijn er zes probleemtoestanden. Tabel 2-2 geeft een overzicht van de zes mogelijke probleemstatussen, de problemen die verband houden met de probleemstatussen en hoe u een probleemstatus kunt oplossen.

LijnstatusMogelijke conditiesProbleem oplossing
Serial x is up, line protocol is upDit is de juiste status lijnconditie.Er is geen actie vereist.
Serial x is down, line protocol is down (DTE mode)– De router neemt geen Carrier Detect (CD)-signaal waar.
– Er is een probleem met de WAN-serviceprovider opgetreden, wat betekent dat de lijn niet beschikbaar is of niet is verbonden met CSU/DSU.
– Bekabeling is defect of onjuist.
Er is een hardwarefout opgetreden (CSU/DSU).
1. Controleer de LED’s op de CSU/DSU om te zien of de cd actief is.
2. Controleer of de juiste kabel en interface worden gebruikt.
3. Neem contact op met de serviceprovider om te zien of er een probleem is opgetreden.
Verwissel defecte onderdelen.
4. Gebruik een andere seriële lijn om te zien of de verbinding tot stand komt, wat aangeeft dat de eerder aangesloten interface een probleem heeft.
Serial x is up, line protocol is down (DTE mode)– Een lokale of externe router is verkeerd geconfigureerd.
– Keepalives worden niet verzonden door de externe router.
– Er is een probleem met de huurlijn of een ander netwerk van een provider opgetreden, wat betekent dat er een lijn met ruis is of een verkeerd geconfigureerde of defecte switch.
– Er is een timingprobleem opgetreden met de kabel.
– Een lokale of externe CSU/DSU is mislukt.
– De routerhardware, die zowel lokaal als extern kan zijn, is defect.
1. Veel DCE-apparaten (bijv. modems en CSU/DSU’s) hebben een zelfcontrolemechanisme voor de lokale loopback om de verbinding tussen de DCE en DTE (bijv. router) te verifiëren. Schakel dit mechanisme in en gebruik het seriële commando show interfaces op de router. Als het lijnprotocol tussen de DCE en DTE verschijnt, is het probleem hoogstwaarschijnlijk een probleem met de WAN-serviceprovider.
2. Als het probleem aan de externe kant lijkt te liggen, herhaalt u stap 1 op de externe DCE.
3. Controleer of de juiste bekabeling is gebruikt en of de DTE correct is aangesloten op de DCE en of de DCE correct is aangesloten op het netwerkaansluitpunt van de serviceprovider. Gebruik de EXEC-opdracht show controllers om te bepalen welke kabel op welke interface is aangesloten.
4. Schakel de debug serial interface EXEC opdracht in.
5. Als het lijnprotocol verschijnt en de keepalive-teller stijgt, ligt het probleem niet in de lokale router.
6. Als het lijnprotocol niet verschijnt in de lokale loopback-modus en de uitvoer van debug serial interface opdracht niet aangeeft dat de keepalives toenemen, is er waarschijnlijk een hardwareprobleem met de router. Verwissel de hardware van de routerinterface.
7. Als u vermoedt dat er defecte routerhardware is, wijzigt u de seriële lijn in een ongebruikte poort. Als de verbinding tot stand komt, heeft de eerder aangesloten interface een probleem.
Serial x is up, line protocol is down (DCE mode)– De opdracht voor de configuratie van de kloksnelheid-interface ontbreekt.
– Het DTE-apparaat ondersteunt de DCE-timing niet.
– De externe CSU of DSU heeft gefaald.
1. Voeg de opdracht voor de configuratie van de bps-interface voor kloksnelheid toe aan de seriële interface. Gebruik het vraagteken (?) om geldige bps-waarden te verifiëren.
2. Als het probleem aan de externe kant lijkt te liggen, herhaalt u stap 1 op de externe DCE.
3. Controleer of de juiste kabel wordt gebruikt.
4. Als het lijnprotocol nog steeds niet actief is, is er mogelijk een hardwarestoring of bekabelingsprobleem.
5. Vervang indien nodig defecte onderdelen.
Serial x is up, line protocol is up (looped)– Er is een lus in het circuit. Het volgnummer in het keepalive-pakket verandert in een willekeurig getal wanneer een lus voor het eerst wordt gedetecteerd. Als hetzelfde willekeurige getal wordt geretourneerd via de link, bestaat er een lus.1. Gebruik de bevoorrechte EXEC-opdracht show running-config om te zoeken naar items met loopback-interfaceconfiguratieopdrachten.
2. Als er een loopback-interfaceconfiguratieopdracht is, gebruik dan de globale configuratieopdracht no loopback-interface om de loopback te verwijderen.
3. Als er geen configuratieopdracht voor de loopback-interface is, onderzoekt u de CSU/DSU om te bepalen of deze in de handmatige loopback-modus zijn geconfigureerd. Als dit het geval is, schakelt u handmatige loopback uit.
4. Nadat u de loopback-modus op de CSU/DSU hebt uitgeschakeld, stelt u de CSU/DSU opnieuw in en inspecteert u de lijnstatus. Als het lijnprotocol verschijnt, is er geen andere actie nodig.
5. Als na inspectie de CSU of DSU niet handmatig kan worden ingesteld, neem dan contact op met de leased-line of andere vervoerder voor hulp bij het oplossen van problemen met de lijn.
Serial x is up, line protocol is down (disabled)– Er is een hoog foutenpercentage opgetreden vanwege een probleem met een WAN-serviceprovider.
– Er is een CSU- of DSU-hardwareprobleem opgetreden.
– Routerhardware (interface) is slecht.
1. Los problemen met de lijn op met een seriële analysator en breakout-box. Zoek naar wisselende CTS- en DSR-signalen.
2. Lus CSU/DSU (DTE-lus). Als het probleem zich blijft voordoen, is er waarschijnlijk een hardwareprobleem. Als het probleem niet blijft bestaan, is er waarschijnlijk een probleem met de WAN-serviceprovider.
3. Vervang indien nodig slechte hardware (CSU, DSU, switch, lokale of externe router).
Serial x is administratively down, line protocol is down– De routerconfiguratie bevat de shutdown configuratie interfaceopdracht.
– Er bestaat een dubbel IP-adres.
1. Controleer de routerconfiguratie voor de opdracht shutdown.
2. Gebruik de no shutdown interface configuratieopdracht om de opdracht shutdown te verwijderen.
3. Controleer of er geen identieke IP-adressen zijn met behulp van de show running-config bevoorrechte EXEC opdracht of de show interfaces EXEC opdracht.
4. Als er dubbele adressen zijn, lost u het conflict op door een van de IP-adressen te wijzigen.

Het opdracht show controllers is een ander belangrijk diagnostisch hulpmiddel bij het oplossen van problemen met seriële lijnen, zoals weergegeven in het volgend voorbeeld.

R1# show controllers serial 0/0/0
Interface Serial0/0/0 Hardware is GT96K
DCE V.35, clock rate 64000
idb at 0x66855120, driver data structure at 0x6685C93C
<output omitted>

De uitgang geeft de status van de interfacekanalen aan en of er een kabel op de interface is aangesloten. In het voorbeeld heeft interface seriële 0/0/0 een V.35 DCE-kabel aangesloten. De opdrachtsyntaxis varieert, afhankelijk van het platform.

Opmerking: Cisco 7000-serie routers gebruiken een cBus-controllerkaart voor het aansluiten van seriële verbindingen. Gebruik bij deze routers de opdracht show controllers cbus.

Als de uitvoer van de elektrische interface wordt weergegeven als “UNKNOWN” in plaats van “V.35”, “EIA/TIA-449” of een ander type elektrische interface, is het waarschijnlijke probleem een onjuist aangesloten kabel. Een probleem met de interne bedrading van de kaart is ook mogelijk. Als de elektrische interface niet bekend is, geeft het corresponderende display voor het seriële commando show interfaces aan dat de interface en het lijnprotocol niet beschikbaar zijn.

3.2. PPP-werking

3.2.1. Voordelen van PPP

3.2.1.1. Introductie van PPP

HDLC is de standaard seriële inkapselingsmethode bij het verbinden van twee Cisco-routers. Met een toegevoegd veld voor het protocoltype is de Cisco-versie van HDLC bedrijfseigen. Daarom kan Cisco HDLC alleen werken met andere Cisco-apparaten. Gebruik echter, zoals weergegeven in Afbeelding 2-6, PPP-inkapseling wanneer u verbinding moet maken met een niet-Cisco-router.

Wat is PPP?

PPP wordt vaak gebruikt als een datalinklaagprotocol voor verbinding via synchrone en asynchrone circuits. PPP-inkapseling is zorgvuldig ontworpen om compatibiliteit met de meest gebruikte ondersteunende hardware te behouden. PPP kapselt dataframes in voor verzending via Layer 2 fysieke verbindingen. Het brengt een directe verbinding tot stand met behulp van seriële kabels, telefoonlijnen, trunklijnen, mobiele telefoons, gespecialiseerde radioverbindingen of glasvezelverbindingen.

PPP bevat drie hoofdcomponenten:

  • HDLC-achtige framing voor het transporteren van multiprotocol-pakketten via point-to-point-verbindingen.
  • Link Control Protocol (LCP) voor het tot stand brengen, configureren en testen van de datalinkverbinding.
  • Familie van Network Control Protocols (NCP’s) voor het opzetten en configureren van verschillende netwerklaagprotocollen. PPP maakt het gelijktijdig gebruik van meerdere netwerklaagprotocollen mogelijk. De meest voorkomende NCP’s zijn IPv4 Control Protocol en IPv6 Control Protocol.

Opmerking: Andere NCP’s zijn AppleTalk Control Protocol, Novell IPX Control Protocol, Cisco Systems Control Protocol, SNA Control Protocol en Compression Control Protocol.

3.2.1.2. Voordelen van PPP

PPP is oorspronkelijk ontstaan ​​als een inkapselingsprotocol voor het transporteren van IPv4-verkeer via point-to-point-verbindingen. Het biedt een standaardmethode voor het transporteren van multiprotocol-pakketten via point-to-point-verbindingen.

Er zijn veel voordelen aan het gebruik van PPP, inclusief het feit dat het niet bedrijfseigen is. PPP bevat veel functies die niet beschikbaar zijn in HDLC:

  • De functie Link Quality Management (LQM) bewaakt de kwaliteit van de link. LQM kan worden geconfigureerd met het interface-opdracht ppp quality percentage. Als het foutpercentage onder de geconfigureerde drempel komt, wordt de link verwijderd en worden pakketten omgeleid of verwijderd.
  • PPP ondersteunt PAP- en CHAP-authenticatie. Deze functie wordt uitgelegd en geconfigureerd in de volgende sectie.
Voordelen van PPP

3.2.2. LCP en NCP

3.2.2.1. PPP-gelaagde architectuur

Een gelaagde architectuur is een logisch model, ontwerp of blauwdruk die helpt bij de communicatie tussen onderling verbonden lagen. De figuur brengt de gelaagde architectuur van PPP in kaart met het Open System Interconnection (OSI) -model. PPP en OSI delen dezelfde fysieke laag, maar PPP verdeelt de functies van LCP en NCP anders.

PPP gelaagde architectuur: fysieke laag

Op de fysieke laag kunt u PPP configureren op een reeks interfaces, waaronder:

  • Asynchroon serieël
  • Synchroon serieël
  • HSSI
  • ISDN

PPP werkt via elke DTE/DCE-interface (RS-232-C, RS-422, RS-423 of V.35). De enige absolute vereiste die door PPP wordt opgelegd, is een full-duplex circuit, ofwel toegewijd ofwel geschakeld, dat kan werken in een asynchrone of synchrone bit-seriële modus, transparant voor PPP-linklaagframes. PPP legt geen andere beperkingen op met betrekking tot de transmissiesnelheid dan die welke worden opgelegd door de specifieke DTE/DCE-interface die in gebruik is.

Het meeste werk van PPP vindt plaats op de datalink- en netwerklagen door de LCP en NCP’s. Het LCP stelt de PPP-verbinding en zijn parameters in, de NCP’s verwerken protocolconfiguraties van een hogere laag en het LCP beëindigt de PPP-verbinding.

2.2.2.2. PPP: Link Control Protocol (LCP)

LCP functioneert binnen de datalinklaag en speelt een rol bij het tot stand brengen, configureren en testen van de datalinkverbinding. LCP brengt de point-to-point-verbinding tot stand. LCP onderhandelt en stelt ook besturingsopties in op de WAN-datalink, die worden afgehandeld door de NCP’s, zoals weergegeven in Afbeelding 2-7.

PPP gelaagde architectuur: LCP laag

LCP biedt automatische configuratie van de interfaces aan elk uiteinde:

  • Omgaan met verschillende limieten voor pakketgrootte
  • Veelvoorkomende configuratiefouten detecteren
  • De koppeling beëindigen
  • Bepalen wanneer een link goed werkt of niet werkt

Nadat de koppeling tot stand is gebracht, gebruikt PPP LCP ook om automatisch overeenstemming te bereiken over inkapselingsformaten zoals authenticatie, compressie en foutdetectie.

3.2.2.3. PPP: Network Control Protocol (NCP)

Met PPP kunnen meerdere netwerklaagprotocollen op dezelfde communicatieverbinding werken. Voor elk gebruikt netwerklaagprotocol gebruikt PPP een afzonderlijk NCP, zoals weergegeven in de volgende afbeelding. IPv4 gebruikt bijvoorbeeld IP Control Protocol (IPCP) en IPv6 gebruikt IPv6 Control Protocol (IPv6CP).

PPP architectuur: netwerklaag

NCP’s bevatten functionele velden die gestandaardiseerde codes bevatten om het netwerklaagprotocol aan te geven dat PPP inkapselt. Tabel 2-3 vermeldt de veldnummers van het PPP-protocol. Elk NCP beheert de specifieke behoeften die vereist zijn door de respectieve netwerklaagprotocollen. De verschillende NCP-componenten omvatten en onderhandelen over opties voor meerdere netwerklaagprotocollen.

Waarde (in Hex) Protocolnaam
8021Internet Protocol (IPv4) Control Protocol
8057Internet Protocol version 6 (IPv6) Control Protocol
8023OSI Network Layer Control Protocol
8029Appletalk Control Protocol
802bNovell IPX Control Protocol
c021 Link Control Protocol
c023Password Authentication Protocol
c223Challenge Handshake Authentication Protocol

2.2.2.4. PPP-framestructuur

Een PPP-frame bestaat uit zes velden. De volgende beschrijvingen vatten de PPP-framevelden geïllustreerd in volgende afbeelding:

  • Vlag – Een enkele byte die het begin of einde van een frame aangeeft. Het veld Vlag bestaat uit de binaire reeks 01111110.
  • Adres – Een enkele byte die de binaire reeks 11111111 bevat, het standaard broadcast-adres. PPP kent geen individuele stationsadressen toe.
  • Besturing – een enkele byte die de binaire reeks 00000011 bevat, die oproept tot verzending van gebruikersgegevens in een niet-opeenvolgend frame.
  • Protocol – twee bytes die het protocol identificeren dat is ingekapseld in het informatieveld van het frame. Het veld Protocol van 2 bytes identificeert het protocol van de PPP-payload.
  • Gegevens – nul of meer bytes die het datagram bevatten voor het protocol dat is opgegeven in het protocolveld.
  • Frame Check Sequence (FCS) – Dit is normaal gesproken 16 bits (2 bytes). Als de berekening van de FCS door de ontvanger niet overeenkomt met de FCS in het PPP-frame, wordt het PPP-frame stil weggegooid.

LCP’s kunnen onderhandelen over wijzigingen aan de standaard PPP-framestructuur. Gemodificeerde frames zijn echter altijd te onderscheiden van standaard frames.

PPP framevelden

3.2.3. PPP-sessies

3.2.3.1. Opzetten van een PPP-sessie

Het opzetten van een PPP-sessie omvat drie fasen, zoals weergegeven in de volgende afbeelding en beschreven in de onderstaande lijst.

PPP-sessie tot stand brengen
  • Fase 1 – Koppeling tot stand brengen en configuratie-onderhandeling: Voordat PPP datagrammen op de netwerklaag, zoals IP, uitwisselt, moet het LCP eerst de verbinding openen en onderhandelen over configuratie-opties. Deze fase is voltooid wanneer de ontvangende router een configuratiebevestigingsframe terugstuurt naar de router die de verbinding tot stand brengt.
  • Fase 2 – Bepaling linkkwaliteit (optioneel): Het LCP test de link om te bepalen of de linkkwaliteit voldoende is om netwerklaagprotocollen op te halen. Het LCP kan de verzending van netwerklaagprotocolinformatie vertragen totdat deze fase is voltooid.
  • Fase 3 – Onderhandeling over configuratie van netwerklaagprotocol: Nadat het LCP de fase voor het bepalen van de verbindingskwaliteit heeft voltooid, geschikte NCP kan de netwerklaagprotocollen afzonderlijk configureren en ze op elk moment naar boven en beneden halen. Als het LCP de koppeling verbreekt, informeert het de netwerklaagprotocollen zodat zij passende maatregelen kunnen nemen.

De koppeling blijft geconfigureerd voor communicatie totdat expliciete LCP- of NCP-frames de koppeling sluiten, of totdat een externe gebeurtenis plaatsvindt, zoals een inactiviteitstimer die afloopt of een beheerder ingrijpt.

Het LCP kan de koppeling op elk moment beëindigen. Dit wordt meestal gedaan wanneer een van de routers om beëindiging verzoekt, maar dit kan gebeuren vanwege een fysieke gebeurtenis, zoals het verlies van een vervoerder of het verstrijken van een timer voor inactiviteit.

3.2.3.2. LCP-werking

LCP-werking omvat voorzieningen voor het tot stand brengen van een link, het onderhoud van de link en het beëindigen van de link. LCP-bewerking gebruikt drie klassen LCP-frames om het werk van elk van de LCP-fasen uit te voeren:

  • Koppelingsframes brengen een koppeling tot stand en configureren deze (Configure-Request, Configure-Ack, Configure-Nak en Configure-Reject).
  • Koppelingsonderhoudsframes beheren en debuggen een koppeling (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply en Discard-Request).
  • Koppelingsbeëindigingsframes beëindigen een koppeling (Terminate-Request en Terminate-Ack).

Link tot stand brengen

Het tot stand brengen van een verbinding is de eerste fase van de werking van het LCP, zoals te zien is in de volgende afbeelding. Deze fase moet met succes worden voltooid voordat netwerklaagpakketten kunnen worden uitgewisseld. Tijdens het tot stand brengen van de link opent het LCP de verbinding en onderhandelt het over de configuratieparameters. Het proces voor het tot stand brengen van een verbinding begint met het initiërende apparaat dat een Configure-Request-frame naar de responder verzendt. Het frame Configure-Request bevat een variabel aantal configuratie-opties die nodig zijn om op de link in te stellen.

PPP-koppeling tot stand brengen

De initiator bevat de opties voor hoe hij de koppeling wil maken, inclusief protocol- of authenticatieparameters. De responder verwerkt het verzoek:

  • Als de opties niet acceptabel zijn of niet worden herkend, stuurt de responder een Configure-Nak- of Configure-Reject-bericht. Als dit gebeurt en de onderhandeling mislukt, moet de initiatiefnemer het proces opnieuw starten met nieuwe opties.
  • Als de opties acceptabel zijn, reageert de responder met een Configure-Ack-bericht en gaat het proces verder naar de authenticatiefase. De exploitatie van de koppeling wordt overgedragen aan het NCP.

Wanneer NCP alle benodigde configuraties heeft voltooid, inclusief het valideren van authenticatie indien geconfigureerd, is de lijn beschikbaar voor gegevensoverdracht. Tijdens de gegevensuitwisseling gaat LCP over op linkonderhoud.

Link onderhoud

Tijdens het onderhoud van de link kan het LCP berichten gebruiken om feedback te geven en de link te testen, zoals weergegeven in de volgende afbeelding:

  • Echo-Request, Echo-Reply en Discard-Request – deze frames kunnen worden gebruikt om de link te testen.
  • Code-Reject en Protocol-Reject – deze frametypes geven feedback wanneer een apparaat een ongeldig frame ontvangt. Het verzendende apparaat zal het pakket opnieuw verzenden.
PPP link-onderhoud

Linkbeëindiging

Nadat de gegevensoverdracht op de netwerklaag is voltooid, beëindigt het LCP de koppeling, zoals weergegeven in de volgende afbeelding. NCP beëindigt alleen de netwerklaag en de NCP-link. De link blijft open totdat het LCP deze beëindigt. Als het LCP de verbinding vóór NCP beëindigt, wordt ook de NCP-sessie beëindigd.

PPP link-beëindiging

PPP kan de link op elk moment beëindigen. Dit kan gebeuren door het verlies van de provider, een authenticatiefout, een fout in de kwaliteit van de link, het verstrijken van een timer voor inactiviteit of het administratief sluiten van de link. Het LCP sluit de link door Terminate-pakketten uit te wisselen. Het apparaat dat de uitschakeling initieert, verzendt een bericht voor het beëindigen van een verzoek. Het andere apparaat antwoordt met een Terminate-Ack. Een beëindigingsverzoek geeft aan dat het apparaat dat het verzendt, de link moet sluiten. Wanneer de koppeling wordt gesloten, informeert PPP de netwerklaagprotocollen zodat zij passende maatregelen kunnen nemen.

3.2.3.3. LCP-pakket

De volgende afbeelding toont de velden in een LCP-pakket:

  • Code – Het codeveld is 1 byte lang en identificeert het type LCP-pakket.
  • Identifier – Het identifier-veld is 1 byte lang en wordt gebruikt om pakketverzoeken en antwoorden te matchen.
  • Length – Het lengteveld is 2 bytes lang en geeft de totale lengte (inclusief alle velden) van het LCP-pakket aan.
  • Data – Het gegevensveld is 0 of meer bytes, zoals aangegeven door het lengteveld. Het formaat van dit veld wordt bepaald door de code.

Elk LCP-pakket is een enkel LCP-bericht dat bestaat uit een LCP-codeveld dat het type LCP-pakket identificeert, een identificatieveld zodat verzoeken en antwoorden kunnen worden vergeleken, en een lengteveld dat de grootte van het LCP-pakket en LCP-pakkettypespecifiek aangeeft gegevens.

LCP pakketcodes

Elk LCP-pakket heeft een specifieke functie bij het uitwisselen van configuratie-informatie, afhankelijk van het pakkettype. Het codeveld van het LCP-pakket identificeert het pakkettype volgens onderstaande tabel.

LCP codeLCP pakkettypeBeschrijving
1Configure-RequestVerzonden om een PPP-verbinding te openen of te resetten. Configure-Request bevat een lijst met LCP-opties met wijzigingen in de standaardoptiewaarden.
2Configure-AckWordt verzonden wanneer alle waarden van alle LCP-opties in het laatst ontvangen configuratieverzoek worden herkend en acceptabel zijn. Wanneer beide PPP-peers Configure-Acks verzenden en ontvangen, is de LCP-onderhandeling voltooid.
3Configure-NakWordt verzonden wanneer alle LCP-opties worden herkend, maar de waarden van sommige opties zijn niet acceptabel. Configure-Nak bevat de niet-overeenkomende opties en hun acceptabele waarden.
4Configure-RejectWordt verzonden wanneer LCP-opties niet worden herkend of niet acceptabel zijn voor onderhandeling. Configure-Reject bevat de niet-herkende of niet-onderhandelbare opties.
5Terminate-RequestOptioneel verzonden om de PPP-verbinding te sluiten.
6Terminate-AckVerzonden naar aanleiding van het Beëindigingsverzoek.
7Code-RejectWordt verzonden wanneer de LCP-code onbekend is. Het bericht Code-Reject bevat het afgewezen LCP-pakket.
8Protocol-RejectWordt verzonden wanneer het PPP-frame een onbekende protocol-ID bevat. Het Protocol-Reject-bericht bevat het afgewezen LCP-pakket. Protocol-Reject wordt meestal verzonden door een PPP-peer als reactie op een PPP NCP voor een LAN-protocol dat niet is ingeschakeld op de PPP-peer.
9Echo-RequestOptioneel verzonden om de PPP-verbinding te testen.
10Echo-ReplyVerzonden naar aanleiding van een Echo-Request. De PPP Echo-Request en Echo-Reply zijn niet gerelateerd aan de ICMP Echo Request- en Echo Reply-berichten.
11Discard-RequestOptioneel verzonden om de link in de uitgaande richting uit te oefenen.

3.2.3.4. PPP-configuratieopties

PPP kan worden geconfigureerd om verschillende optionele functies te ondersteunen. Er zijn drie optionele functies:

  • Authenticatie met behulp van PAP of CHAP
  • Compressie met behulp van Stacker of Predictor
  • Multilink die twee of meer kanalen combineert om het WAN bandbreedte te verhogen
PPP configuratieopties

Om te onderhandelen over het gebruik van deze PPP-opties, bevatten de LCP-link-vestigingsframes optie-informatie in het gegevensveld van het LCP-frame, zoals weergegeven in de volgende afbeelding. Als een configuratieoptie niet is opgenomen in een LCP-frame, is de standaardwaarde daarvoor configuratieoptie wordt verondersteld.

Deze fase is voltooid wanneer een configuratiebevestigingsframe is verzonden en ontvangen.

LCP optievelden

3.2.3.5. NCP uitgelegd

Nadat het LCP de basiskoppeling heeft geconfigureerd en geverifieerd, wordt het juiste NCP aangeroepen om de specifieke configuratie van het gebruikte netwerklaagprotocol te voltooien. Wanneer het NCP met succes het netwerk laagprotocol heeft geconfigureerd, bevindt het netwerkprotocol zich in de open toestand op de tot stand gebrachte LCP-link. Op dit punt kan PPP de corresponderende netwerklaagprotocolpakketten dragen.

IPCP-voorbeeld

Als voorbeeld van hoe de NCP-laag werkt, toont figuur 2-13 de NCP-configuratie van IPv4. Nadat LCP de koppeling tot stand heeft gebracht, wisselen de routers IPCP-berichten uit en onderhandelen ze over opties die specifiek zijn voor IPv4. IPCP is verantwoordelijk voor het configureren, inschakelen en uitschakelen van de IPv4-modules aan beide uiteinden van de link.

PPP NCP operatie

PPP NCP Operatie IPCP onderhandelt over twee opties:

  • Compressie – hiermee kunnen apparaten onderhandelen over een algoritme om TCP- en IP-headers te comprimeren en bandbreedte te besparen. De TCP/IP-headercompressie van Van Jacobson reduceert de omvang van de TCP/IP-headers tot slechts 3 bytes. Dit kan een aanzienlijke verbetering zijn op langzame seriële lijnen, vooral voor interactief verkeer.
  • IPv4-adres – Hiermee kan het initiërende apparaat een IPv4-adres specificeren om te gebruiken voor het routeren van IP via de PPP-link, of om een ​​IPv4-adres op te vragen voor de responder. Vóór de komst van breedbandtechnologieën zoals DSL- en kabelmodemdiensten, gebruikten inbelnetwerkapparaten vaak de IPv4-adresoptie.

Nadat het NCP-proces is voltooid, gaat de link naar de open toestand en neemt LCP het weer over in een onderhoudsfase van de link. Linkverkeer bestaat uit elke mogelijke combinatie van LCP-, NCP- en netwerklaagprotocolpakketten.

Wanneer de gegevensoverdracht is voltooid, beëindigt NCP de protocolkoppeling en beëindigt LCP de PPP-verbinding.

3.3. PPP-implementatie

3.3.1. PPP configureren

3.3.1.1. PPP-configuratieopties

In het vorige gedeelte werden configureerbare LCP-opties geïntroduceerd om te voldoen aan specifieke WAN-verbindingsvereisten. PPP kan verschillende LCP-opties bevatten:

  • Authenticatie – Peer-routers wisselen authenticatieberichten uit. Twee authenticatiemogelijkheden zijn Password Authentication Protocol (PAP) en Challenge Handshake Authentication Protocol (CHAP).
  • Compressie – Deze optie verhoogt de effectieve doorvoer op PPP-verbindingen door het aantal bits dat over de link moet reizen te verminderen. Het protocol decomprimeert het frame op zijn bestemming. Twee compressieprotocollen die beschikbaar zijn in Cisco-routers zijn Stacker en Predictor.
  • Foutdetectie – Deze optie identificeert foutcondities. De opties Quality en Magic Number zorgen voor een betrouwbare, lusvrije datalink. Het veld Magisch getal helpt bij het detecteren van links die zich in een teruggeluste toestand bevinden. Totdat de Magic-Number-configuratieoptie met succes is onderhandeld, moet het Magic-Number als nul worden verzonden. Magische getallen worden willekeurig gegenereerd aan elk uiteinde van de verbinding.
  • PPP-callback – PPP-callback wordt gebruikt om de beveiliging te verbeteren. Met deze LCP-optie kan een Cisco-router fungeren als callback-client of callback-server. De client voert de eerste oproep uit, verzoekt de server deze terug te bellen en beëindigt de eerste oproep. De callback-router beantwoordt de eerste oproep en belt de client terug op basis van de configuratie-instructies.
  • Multilink PPP – Dit alternatief biedt load balancing over de routerinterfaces die PPP gebruikt. Multilink PPP, ook wel MP, MPPP, MLP of Multilink genoemd, biedt een methode voor het spreiden van verkeer over meerdere fysieke WAN-links en biedt tegelijkertijd pakketfragmentatie en hermontage, juiste sequencing, interoperabiliteit van meerdere leveranciers en taakverdeling op inkomend en uitgaand verkeer.

Wanneer opties zijn geconfigureerd, wordt een overeenkomstige veldwaarde ingevoegd in het LCP-optieveld, zoals weergegeven in de volgende tabel.

Optie naamOptie typeOptie lengteBeschrijving
Maximum Receive Unit (MRU)14MRU is de maximale grootte van een PPP frame en mag niet groter zijn dan 65.535. De standaardwaarde is 1500, en als geen van beide peers de standaardwaarde wijzigt, wordt hierover niet onderhandeld.
Asynchronous Control Character Map (ACCM)26Dit is een bitmap die karakter-escapes mogelijk maakt voor asynchrone links. Standaard worden karakter-escapes gebruikt.
Authentication
Protocol
35 of 6Dit veld geeft het authenticatieprotocol aan, PAP of CHAP.
Magic Number56Dit is een willekeurig getal dat is gekozen om een peer te onderscheiden en om teruggekoppelde lijnen te detecteren.
Protocol Compression72Deze vlag geeft aan dat de PPP-protocol-ID wordt gecomprimeerd tot een enkel octet wanneer de 2-byte protocol-ID zich in het bereik 0x00-00 tot 0x00-FF bevindt.
Address and Control Field Compression82Deze vlag geeft aan dat het veld PPP Address (altijd ingesteld op 0xFF) en het veld PPP Control (altijd ingesteld op 0x03) uit de PPP-header worden verwijderd.
Callback13 of 0x0D3Deze 1-octet indicator bepaalt hoe terugbellen wordt bepaald.

3.3.1.2. PPP Basisconfiguratieopdracht

Om PPP in te stellen als de inkapselingsmethode die wordt gebruikt door een seriële interface, gebruikt u de opdracht encapsulation ppp-interfaceconfiguratie. De opdracht heeft geen argumenten. Onthoud dat als PPP niet is geconfigureerd op een Cisco-router, de standaard inkapseling voor seriële interfaces HDLC is.
De volgende afbeelding toont een topologie met twee routers die wordt gebruikt om de PPP-configuratie te demonstreren.

PPP-basisconfiguratie

Het volgend voorbeeld toont de configuratie voor R1 en R2 met zowel een IPv4- als een IPv6-adres op de seriële interfaces. PPP is een Layer 2-inkapseling die verschillende Layer 3-protocollen ondersteunt, waaronder IPv4 en IPv6.

hostname R1
!
interface Serial 0/0/0
  ip address 10.0.1.1 255.255.255.252
  ipv6 address 2001:db8:cafe:1::1/64
  encapsulation ppp
  hostname R2
hostname R2
!
interface Serial 0/0/0
  ip address 10.0.1.2 255.255.255.252
  ipv6 address 2001:db8:cafe:1::2/64
  encapsulation ppp

3.3.1.3. PPP-compressieopdrachten

Point-to-point softwarecompressie op seriële interfaces kan worden geconfigureerd nadat PPP-inkapseling is ingeschakeld. Omdat deze optie een softwarecompressieproces aanroept, kan dit de systeemprestaties beïnvloeden. Als het verkeer al bestaat uit gecomprimeerde bestanden, zoals .zip, .tar of .mpeg, gebruik deze optie dan niet.

Gebruik het compress [predictor | stac] interfaceconfiguratieopdracht om PPP-compressie in te schakelen.

SleutelwoordBeschrijving
predictor(Optioneel) Specificeert dat een predicatorcompressiealgoritme wordt gebruikt
stac(Optioneel) Specificeert dat een Stacker (LZS)-compressiealgoritme wordt gebruikt
PPP-basisconfiguratie

Het volgend voorbeeld toont de configuratie voor R1 en R2 om predictor compressie te gebruiken.

hostname R1
!
interface Serial 0/0/0
  ip address 10.0.1.1 255.255.255.252
  ipv6 address 2001:db8:cafe:1::1/64 
  encapsulation ppp
  compress predictor 
hostname R2
!
interface Serial 0/0/0
  ip address 10.0.1.2 255.255.255.252
  ipv6 address 2001:db8:cafe:1::2/64
  encapsulation ppp
  compress predictor

3.3.1.4. PPP Link Quality Monitoring Command

LCP biedt een optionele fase voor het bepalen van de verbindingskwaliteit. In deze fase test LCP de link om te bepalen of de kwaliteit van de link voldoende is om Layer 3-protocollen te gebruiken.

Het interfaceconfiguratiecommando ppp quality precentage zorgt ervoor dat de link voldoet aan de gestelde kwaliteitseisen; anders wordt de link gesloten. De procentuele waarde geeft de drempel voor de verbindingskwaliteit aan met een bereik tussen 1 en 100.

De percentages worden berekend voor zowel inkomende als uitgaande richtingen. De uitgaande kwaliteit wordt berekend door het totale aantal verzonden pakketten en bytes te vergelijken met het totale aantal pakketten en bytes dat door het bestemmingsknooppunt is ontvangen. De inkomende kwaliteit wordt berekend door het totale aantal ontvangen pakketten en bytes te vergelijken met het totale aantal pakketten en bytes dat door het bestemmingsknooppunt is verzonden.

Als het linkkwaliteitspercentage niet wordt gehandhaafd, wordt de link als van slechte kwaliteit beschouwd en wordt deze verwijderd. LQM implementeert een tijdvertraging zodat de link niet op en neer stuitert.

De configuratie ppp quality 80, getoond in het volgend voorbeeld, stelt de minimumkwaliteit in op 80 procent.

hostname R1
!
interface Serial 0/0/0
  ip address 10.0.1.1 255.255.255.252
  ipv6 address 2001:db8:cafe:1::1/64
  encapsulation ppp
  compress predictor
  ppp quality 80
hostname R2
!
  interface Serial 0/0/0
  ip address 10.0.1.2 255.255.255.252
  ipv6 address 2001:db8:cafe:1::2/64
  encapsulation ppp
  compress predictor
  ppp quality 80

3.3.1.5. PPP Multilink-opdrachten

Multilink PPP (ook wel MP, MPPP, MLP of Multilink genoemd) biedt een methode voor het spreiden van verkeer over meerdere fysieke WAN-links. Multilink PPP biedt ook pakketfragmentatie en hermontage, juiste sequencing, interoperabiliteit van meerdere leveranciers en taakverdeling op inkomend en uitgaand verkeer.

Met MPPP kunnen pakketten worden gefragmenteerd en worden deze fragmenten tegelijkertijd via meerdere point-to-point-verbindingen naar hetzelfde externe adres verzonden. De meerdere fysieke koppelingen komen tot stand als reactie op een door de gebruiker gedefinieerde belastingsdrempel. MPPP kan de belasting meten op alleen inkomend verkeer of alleen uitgaand verkeer, maar niet op de gecombineerde belasting van zowel inkomend als uitgaand verkeer.

PPP multilink

PPP Multilink Het configureren van MPPP vereist twee stappen:

Stap 1. Maak een multilinkbundel aan.

  • Gebruik de opdracht voor globale configuratie van het multilink-nummer van de interface om de multilink-interface te maken.
  • Wijs in de interfaceconfiguratiemodus een IPv4- en/of IPv6-adres toe aan de multilink-interface.
  • Gebruik de configuratieopdracht ppp multilink interface om multilink PPP in te schakelen.
  • Gebruik de interfaceconfiguratieopdracht ppp multilink-groepsnummer om het multilink-groepsnummer toe te wijzen.

Stap 2. Wijs elke fysieke interface toe aan de multilinkbundel.

  • Gebruik de configuratieopdracht ppp encapsulation interface om PPP in te schakelen.
  • Gebruik de configuratieopdracht ppp multilink interface om multilink PPP in te schakelen.
  • Gebruik de interfaceconfiguratieopdracht ppp multilink-groepsnummer om het multilink-groepsnummer toe te wijzen.

Het volgend voorbeeld toont de configuratie voor R3 en R4.

hostname R3
!
interface Multilink 1
  ip address 10.0.1.1 255.255.255.252
  ipv6 address 2001:db8:cafe:1::1/64
  ppp multilink	
  ppp multilink group 1
!
interface Serial 0/1/0
  no ip address
  encapsulation ppp
  ppp multilink	
  ppp multilink group 1
!
interface Serial 0/1/1
  no ip address
  encapsulation ppp
  ppp multilink	
  ppp multilink group 1
hostname R4
!
interface Multilink 1
  ip address 10.0.1.2 255.255.255.252
  ipv6 address 2001:db8:cafe:1::2/64
  ppp multilink	
  ppp multilink group 1
!
interface Serial 0/0/0
  no ip address
  encapsulation ppp
  ppp multilink	
  ppp multilink group 1
!
interface Serial 0/0/1
  no ip address
  encapsulation ppp
  ppp multilink	
  ppp multilink group 1

Om PPP multilink uit te schakelen, gebruikt u de no ppp multilink interface-configuratieopdracht op elk van de gebundelde interfaces.

2.3.1.6. PPP-configuratie verifiëren

Gebruik de opdracht show interfaces serial om de juiste configuratie van HDLC- of PPP-inkapseling te controleren. De opdrachtuitvoer in het volgend voorbeeld toont een PPP-configuratie.

R2# show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up 
  Hardware is GT96K Serial
  Internet address is 10.0.1.2/30
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP, IPV6CP, CCP, CDPCP, loopback not set Keepalive set (10 sec)
  CRC checking enabled
  Last input 00:00:02, output 00:00:02, output hang never 
  Last clearing of "show interface" counters 01:29:06 
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total
 output drops: 0
  Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max
/total/threshold/drops)
    Conversations 0/1/256 (active/max active/max total) 
    Reserved Conversations 0/0 (allocated/max allocated) 
    Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec 
    1944 packets input, 67803 bytes, 0 no buffer 
    Received 0 broadcasts (0 IP multicasts)
    0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    1934 packets output, 67718 bytes, 0 underruns
    0 output errors, 0 collisions, 5 interface resets
    1 unknown protocol drops
    0 output buffer failures, 0 output buffers swapped out
    8 carrier transitions
    DCD=up DSR=up DTR=up RTS=up CTS=up
R2#

Wanneer u HDLC configureert, moet de uitvoer van de opdracht show interfaces serial encapsulation HDLC weergeven. Wanneer PPP is geconfigureerd, geeft de opdracht ook de LCP- en NCP-statussen weer. Merk op dat NCP’s IPCP en IPV6CP open staan voor IPv4 en IPv6 omdat R1 en R2 zijn geconfigureerd met zowel IPv4- als IPv6-adressen.

De volgende tabel geeft een overzicht van de opdrachten die worden gebruikt bij het verifiëren van PPP.

OpdrachtBeschrijving
show interfacesGeeft statistieken weer voor alle interfaces die zijn geconfigureerd op de router
show interfaces serialGeeft informatie weer over een seriële interface
show ppp multilinkGeeft informatie weer over een PPP-multilinkinterface

De opdracht show ppp multilink controleert of PPP multilink is ingeschakeld op R3, zoals weergegeven in het volgend voorbeeld. De uitvoer geeft de interface Multilink 1 aan, de hostnamen van zowel de lokale als de externe eindpunten en de seriële interfaces die aan de multilinkbundel zijn toegewezen.

R3# show ppp multilink
Multilink1
  Bundle name: R4
  Remote Endpoint Discriminator: [1] R4
  Local Endpoint Discriminator: [1] R3
  Bundle up for 00:01:20, total bandwidth 3088, load 1/255 
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x2 received sequence, 0x2 sent sequence
  Member links: 2 active, 0 inactive (max 255, min not set)
    Se0/1/1, since 00:01:20
    Se0/1/0, since 00:01:06
No inactive multilink interfaces 
R3#

3.3.2. PPP-authenticatie configureren

3.3.2.1. PPP-authenticatieprotocollen

PPP definieert een LCP waarmee kan worden onderhandeld over een authenticatieprotocol voor authenticatie van zijn peer voordat netwerklaagprotocollen over de link kunnen worden verzonden. RFC 1334, PPP-authenticatieprotocollen, definieert twee protocollen voor authenticatie, PAP en CHAP, zoals weergegeven in volgende afbeelding.

PPP-authenticatieprotocollen

PAP is een basisproces in twee richtingen. Er is geen encryptie. De gebruikersnaam en het wachtwoord worden in platte tekst verzonden. Als het wordt geaccepteerd, is de verbinding toegestaan. CHAP is veiliger dan PAP. Het gaat om een ​​uitwisseling van een gedeeld geheim in drie richtingen.

De authenticatiefase van een PPP-sessie is optioneel. Indien gebruikt, wordt de peer geauthenticeerd nadat LCP de link tot stand heeft gebracht en het authenticatieprotocol heeft gekozen. Authenticatie vindt plaats voordat de configuratiefase van het netwerklaagprotocol begint.

De authenticatie-opties vereisen dat de oproepende zijde van de link authenticatie-informatie verstrekt. Dit helpt ervoor te zorgen dat de gebruiker toestemming heeft van de netwerkbeheerder om te bellen. Peer-routers wisselen authenticatieberichten uit.

3.3.2.2. Password Authentication Protocol (PAP)

PAP biedt een eenvoudige methode voor een extern knooppunt om zijn identiteit vast te stellen met behulp van een tweerichtingshandshake. PAP is niet interactief. Wanneer de ppp-authenticatie pap-interfaceconfiguratieopdracht wordt gebruikt, worden de gebruikersnaam en het wachtwoord verzonden als één LCP-gegevenspakket, zoals weergegeven in volgende afbeelding, in plaats van één PPP-apparaat dat een login-prompt verzendt en wacht op een reactie zoals bij sommige authenticatiemechanismen .

PAP initiëren

PAP-proces

Nadat PPP de verbindingsfase heeft voltooid, stuurt het externe knooppunt herhaaldelijk een gebruikersnaam-wachtwoordpaar over de link totdat het ontvangende knooppunt dit bevestigt of de verbinding beëindigt.

Bij het ontvangende knooppunt controleert het apparaat waarop PPP draait de gebruikersnaam-wachtwoord. Dit apparaat staat de verbinding toe of weigert deze. Een acceptatie- of afwijzingsbericht wordt teruggestuurd naar de aanvrager, zoals weergegeven in volgende afbeelding.

PAP voltooien

PAP is geen sterk authenticatieprotocol. Met behulp van PAP worden wachtwoorden in platte tekst over de link verzonden en is er geen bescherming tegen afspelen of herhaalde trial-and-error-aanvallen. Het externe knooppunt heeft de controle over de frequentie en timing van de inlogpogingen.

Toch kan het gebruik van PAP soms gerechtvaardigd zijn. Ondanks de tekortkomingen kan PAP worden gebruikt in de volgende omgevingen:

  • Een groot aantal geïnstalleerde clienttoepassingen die CHAP niet ondersteunen
  • Incompatibiliteit tussen verschillende leveranciersimplementaties van CHAP
  • Situaties waarin een wachtwoord in leesbare tekst beschikbaar moet zijn om een ​​aanmelding bij de externe host te simuleren

3.3.2.3. Challenge Handshake Authentication Protocol (CHAP)

PAP authenticeert slechts één keer. Nadat authenticatie is ingesteld met PAP, wordt het niet opnieuw geverifieerd, waardoor het netwerk kwetsbaar wordt voor aanvallen. CHAP is veiliger omdat het periodieke uitdagingen uitvoert om ervoor te zorgen dat het externe knooppunt nog steeds een geldige wachtwoordwaarde heeft. De wachtwoordwaarde is variabel en verandert onvoorspelbaar terwijl de link bestaat.

CHAP wordt geconfigureerd met behulp van de ppp authentication chap interface-configuratieopdracht.

CHAP-proces

Nadat de fase van het tot stand brengen van de PPP-link is voltooid, stuurt de lokale router een uitdagingsbericht naar het externe knooppunt, zoals weergegeven in volgende afbeelding.

CHAP initiëren

Het externe knooppunt reageert met een waarde die wordt berekend met behulp van een eenrichtings-hashfunctie. Dit is meestal Message Digest 5 (MD5) op basis van het wachtwoord en het challenge-bericht, zoals weergegeven in volgende afbeelding.

Reageren op CHAP

De lokale router vergelijkt de respons met zijn eigen berekening van de verwachte hash-waarde. Als de waarden overeenkomen, bevestigt het initiërende knooppunt de authenticatie, zoals weergegeven in volgende afbeelding. Als de waarden niet overeenkomen, beëindigt het initiërende knooppunt de verbinding onmiddellijk.

CHAP voltooien

CHAP biedt bescherming tegen een afspeelaanval door een variabele uitdagingswaarde te gebruiken die uniek en onvoorspelbaar is. Omdat de uitdaging uniek en willekeurig is, is de resulterende hashwaarde ook uniek en willekeurig. Het gebruik van herhaalde uitdagingen beperkt de tijd van blootstelling aan een enkele aanval. De lokale router, of een authenticatieserver van een derde partij, heeft de controle over de frequentie en timing van de uitdagingen.

3.3.2.4. PPP-inkapseling en authenticatieproces

Het stroomschema in de volgende afbeelding kan worden gebruikt om het PPP-authenticatieproces te helpen begrijpen bij het configureren van PPP. Het stroomdiagram geeft een visueel voorbeeld van de logische beslissingen die door PPP worden genomen.

PPP-inkapseling en authenticatieproces

Als een inkomend PPP-verzoek bijvoorbeeld geen authenticatie vereist, gaat PPP door naar het volgende niveau. Als een inkomend PPP-verzoek authenticatie vereist, kan het worden geverifieerd met behulp van de lokale database of een beveiligingsserver. Zoals geïllustreerd in het stroomschema, gaat succesvolle authenticatie door naar het volgende niveau, terwijl een authenticatiefout de verbinding verbreekt en het inkomende PPP-verzoek laat vallen.

Volg de stappen terwijl de animatie vordert in volgende afbeelding om R1 te zien die een geverifieerde PPP CHAP-verbinding met R2 tot stand brengt.

Voorbeel CHAP authenticatieproces

Stap 1. R1 onderhandelt in eerste instantie over de linkverbinding met behulp van LCP met router R2 en de twee systemen komen overeen om CHAP-authenticatie te gebruiken tijdens de PPP LCP-onderhandeling.

Stap 2. R2 genereert een ID en een willekeurig getal en stuurt dat en zijn gebruikersnaam als een CHAP-uitdagingspakket naar R1.

Stap 3. R1 gebruikt de gebruikersnaam van de uitdager (R2) en verwijst ernaar met zijn lokale database om het bijbehorende wachtwoord te vinden. R1 genereert vervolgens een uniek MD5-hashnummer met behulp van de gebruikersnaam, ID, willekeurig nummer en het gedeelde geheime wachtwoord van de R2. In dit voorbeeld is het gedeelde geheime wachtwoord boardwalk.

Stap 4. Router R1 stuurt vervolgens de challenge-ID, de gehashte waarde en de gebruikersnaam (R1) naar R2.

Stap 5. R2 genereert zijn eigen hash-waarde met behulp van de ID, het gedeelde geheime wachtwoord en het willekeurige nummer dat het oorspronkelijk naar R1 heeft gestuurd.

Stap 6. R2 vergelijkt zijn hash-waarde met de hash-waarde verzonden door R1. Als de waarden hetzelfde zijn, stuurt R2 een verbindingsantwoord naar R1.

Als de authenticatie is mislukt, wordt een CHAP-foutpakket opgebouwd uit de volgende componenten:

  • 04 = CHAP-foutberichttype
  • id = gekopieerd van het antwoordpakket
  • “Verificatiefout” of een soortgelijk sms-bericht, dat bedoeld is als een voor de gebruiker leesbare uitleg

Het gedeelde geheime wachtwoord moet identiek zijn op R1 en R2.

3.3.2.5. PPP authenticatie configureren

Om de volgorde te specificeren waarin de CHAP- of PAP-protocollen op de interface worden aangevraagd, gebruikt u de ppp authentication {chap | chap pap | pap chap | pap} [if-needed] [list-name | default] [callin] interfaceconfiguratieopdracht. Gebruik de no-vorm van de opdracht om deze authenticatie uit te schakelen.

Nadat u CHAP- of PAP-authenticatie of beide hebt ingeschakeld, vereist de lokale router dat het externe apparaat zijn identiteit bewijst voordat het dataverkeer kan stromen. Dit gebeurt als volgt:

PAP-authenticatie vereist dat het externe apparaat een naam en wachtwoord verzendt om te worden vergeleken met een overeenkomend item in de lokale gebruikersnaamdatabase of in de externe TACACS/TACACS+-database.

CHAP-verificatie stuurt een uitdaging naar het externe apparaat. Het externe apparaat moet de uitdagingswaarde versleutelen met een gedeeld geheim en de versleutelde waarde en zijn naam terugsturen naar de lokale router in een antwoordbericht. De lokale router gebruikt de naam van het externe apparaat om het juiste geheim op te zoeken in de lokale gebruikersnaam of externe TACACS/TACACS+-database. Het gebruikt het opgezochte geheim om de oorspronkelijke uitdaging te versleutelen en te verifiëren dat de versleutelde waarden overeenkomen.

Opmerking: Authenticatie, autorisatie en accounting (AAA)/TACACS is een speciale server die wordt gebruikt om gebruikers te authenticeren. TACACS-clients sturen een query naar een TACACS-authenticatieserver. De server kan de gebruiker authenticeren, autoriseren wat de gebruiker kan doen en bijhouden wat de gebruiker heeft gedaan.

PAP of CHAP of beide kunnen worden ingeschakeld. Als beide methoden zijn ingeschakeld, wordt de eerste opgegeven methode gevraagd tijdens koppelingsonderhandeling. Als de peer voorstelt om de tweede methode te gebruiken of gewoon de eerste methode weigert, moet de tweede methode worden geprobeerd. Sommige externe apparaten ondersteunen alleen CHAP en sommige alleen PAP. De volgorde waarin u de methoden opgeeft, is gebaseerd op uw zorgen over het vermogen van het externe apparaat om correct te onderhandelen over de juiste methode en uw bezorgdheid over de beveiliging van de datalijn. PAP-gebruikersnamen en wachtwoorden worden verzonden als tekst zonder opmaak en kunnen worden onderschept en hergebruikt. CHAP heeft de meeste bekende beveiligingslekken geëlimineerd.

3.3.2.6. PPP configureren met verificatie

De procedure die in de tabel wordt beschreven, beschrijft hoe u PPP-inkapseling en PAP/CHAP-authenticatieprotocollen configureert. Een juiste configuratie is essentieel, omdat PAP en CHAP deze parameters gebruiken om te verifiëren.

PAP-verificatie configureren

Het volgend voorbeeld toont een tweerichtings PAP-authenticatieconfiguratie. Beide routers verifiëren en zijn geverifieerd, dus de PAP-authenticatieopdrachten spiegelen elkaar. Gebruik de ppp pap sent-username name password password interface configuratieopdracht om de gebruikersnaam en wachtwoordparameters op te geven die een router zal verzenden. Deze combinatie van gebruikersnaam en wachtwoord moet overeenkomen met die gespecificeerd met de username name password password opdracht van de andere ontvangende router.

hostname R1
username R2 password sameone
!
interface Serial0/0/0
ip address 10.0.1.1 255.255.255.252
ipv6 address 2001:DB8:CAFE:1::1/64 encapsulation ppp
  ppp authentication pap
  ppp pap sent-username R1 password sameone 
hostname R2
username R1 password 0 sameone
!
interface Serial 0/0/0
ip address 10.0.1.2 255.255.255.252
ipv6 address 2001:db8:cafe:1::2/64 encapsulation ppp
  ppp authentication pap
  ppp pap sent-username R2 password sameone

PAP biedt een eenvoudige methode voor een extern knooppunt om zijn identiteit vast te stellen met behulp van een tweerichtingshandshake. Dit wordt alleen gedaan bij het opzetten van de eerste link. De hostnaam op de ene router moet overeenkomen met de gebruikersnaam die de andere router heeft geconfigureerd voor PPP. De wachtwoorden moeten ook overeenkomen.

CHAP-verificatie configureren

Configureer altijd CHAP in plaats van PAP omdat CHAP veiliger is dan PAP. CHAP verifieert periodiek de identiteit van het externe knooppunt met behulp van een drieweg-handshake. De hostnaam op de ene router moet overeenkomen met de gebruikersnaam die de andere router heeft geconfigureerd. De wachtwoorden moeten ook overeenkomen. Dit gebeurt bij het tot stand brengen van de eerste link en kan op elk moment worden herhaald nadat de link tot stand is gebracht. Het volgend voorbeeld toont een CHAP-configuratie.

hostname R1
username R2 password sameone
!
interface Serial0/0/0
  ip address 10.0.1.1 255.255.255.252
  ipv6 address 2001:DB8:CAFE:1::1/64
  encapsulation ppp
  ppp authentication chap 
hostname R2
username R1 password 0 sameone
!
interface Serial 0/0/0
  ip address 10.0.1.2 255.255.255.252
  ipv6 address 2001:db8:cafe:1::2/64
  encapsulation ppp
  ppp authentication chap

3.4. Problemen met WAN-connectiviteit oplossen

32.4.1. Problemen met PPP oplossen

3.4.1.1. Problemen met PPP seriële inkapseling oplossen

De debug opdracht in de gepriviligeerde EXEC-modus is erg handig voor het oplossen van problemen. De opdracht genereert realtime uitvoerinformatie over verschillende routerbewerkingen, gerelateerd verkeer dat door de router wordt gegenereerd of ontvangen, en eventuele foutmeldingen.

De opdracht debug is echter een arbeidsintensief proces. Het kan een aanzienlijke hoeveelheid CPU-bronnen verbruiken, omdat de router wordt gedwongen om de pakketten die worden gedebugd, te verwerken en te schakelen. Daarom is de debug opdracht niet iets dat we inschakelen om het netwerk regelmatig te controleren. De opdracht is bedoeld om voor een korte periode te worden gebruikt bij het oplossen van problemen.

Onthoud daarom altijd om debug opdracht uit te schakelen met de no debug of undebug all bevoorrechte EXEC-opdrachten.

Gebruik de debug ppp {packet | negatiation | error | authentication | compression} gepriviligeerde EXEC-modusopdracht om informatie over de werking van PPP weer te geven.

De volgende tabel beschrijft de opties voor de opdracht debug ppp.

SleutelwoordBeschrijving
packetGeeft PPP-pakketten weer die worden verzonden en ontvangen.
negotiationGeeft PPP-pakketten weer die tijdens het opstarten van PPP zijn verzonden. Het is handig om te zien hoe PPS-opties worden onderhandeld.
errorGeeft protocolfouten en foutstatistieken weer die verband houden met PPP-verbindingsonderhandeling en -werking.
authenticationGeeft PAP- en CHAP-authenticatieprotocolberichten weer.
compressionGeeft informatie weer die specifiek is voor de uitwisseling van PPP-verbindingen met behulp van pakketcompressie.

Gebruik de no-vorm van deze opdracht om de foutopsporingsuitvoer uit te schakelen.

Gebruik de opdracht debug ppp wanneer u het volgende probeert te zoeken:

  • NCP’s die aan beide uiteinden van een PPP-verbinding worden ondersteund Alle lussen die in een PPP-internetwerk kunnen voorkomen
  • Knooppunten die (of niet) goed onderhandelen over PPP-verbindingen Fouten die zijn opgetreden via de PPP-verbinding
  • Oorzaken voor CHAP-sessiefouten
  • Oorzaken voor mislukte PAP-sessies
  • Informatie specifiek voor de uitwisseling van PPP-verbindingen met behulp van het Callback Control Protocol (CBCP), gebruikt door Microsoft-clients
  • Onjuiste informatie over pakketvolgnummers waar MPPC-compressie is ingeschakeld

3.4.1.2. PPP debuggen

Een handig commando om te gebruiken bij het oplossen van problemen met de inkapseling van de seriële interface is het debug ppp packet geprivilegieerde EXEC-moduscommando, zoals getoond in het volgend voorbeeld.

R1# debug ppp packet
PPP packet display debugging is on R1#
*Apr 1 16:15:17.471: Se0/0/0 LQM: O state Open magic 0x1EFC37C3 len 48
*Apr 1 16:15:17.471: Se0/0/0 LQM:	LastOutLQRs 70 LastOutPackets/Octets 194/9735
*Apr 1 16:15:17.471: Se0/0/0 LQM:	PeerInLQRs 70 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr 1 16:15:17.471: Se0/0/0 LQM:	PeerOutLQRs 71 PeerOutPackets/Octets 197/9839
*Apr 1 16:15:17.487: Se0/0/0 PPP: I pkt type 0xC025, datagramsize 52 link[ppp]
*Apr 1 16:15:17.487: Se0/0/0 LQM: I state Open magic 0xFE83D624 len 48
*Apr 1 16:15:17.487: Se0/0/0 LQM:	LastOutLQRs 71 LastOutPackets/Octets 197/9839
*Apr 1 16:15:17.487: Se0/0/0 LQM:	PeerInLQRs 71 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr 1 16:15:17.487: Se0/0/0 LQM:	PeerOutLQRs 71 PeerOutPackets/Octets 196/9809
*Apr 1 16:15:17.535: Se0/0/0 LCP: O ECHOREQ [Open] id 36 len 12 magic 0x1EFC37C3
*Apr 1 16:15:17.539: Se0/0/0 LCP-FS: I ECHOREP [Open] id 36 len 12 magic 0xFE83D624
*Apr 1 16:15:17.539: Se0/0/0 LCP-FS: Received id 36, sent id 36, line up
*Apr 1 16:15:18.191: Se0/0/0 PPP: I pkt type 0xC025, datagramsize 52 link[ppp]
*Apr 1 16:15:18.191: Se0/0/0 LQM: I state Open magic 0xFE83D624 len 48
*Apr 1 16:15:18.191: Se0/0/0 LQM:	LastOutLQRs 71 LastOutPackets/Octets 197/9839
*Apr 1 16:15:18.191: Se0/0/0 LQM:	PeerInLQRs 71 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr 1 16:15:18.191: Se0/0/0 LQM:	PeerOutLQRs 72 PeerOutPackets/Octets 198/9883
*Apr 1 16:15:18.191: Se0/0/0 LQM: O state Open magic 0x1EFC37C3 len 48
*Apr 1 16:15:18.191: Se0/0/0 LQM:	LastOutLQRs 72 LastOutPackets/Octets 198/9883
*Apr 1 16:15:18.191: Se0/0/0 LQM:	PeerInLQRs 72 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr 1 16:15:18.191: Se0/0/0 LQM:	PeerOutLQRs 72 PeerOutPackets/Octets 199/9913
*Apr 1 16:15:18.219: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 36 len 12 magic 0xFE83D624
*Apr 1 16:15:18.219: Se0/0/0 LCP-FS: O ECHOREP [Open] id 36 len 12 magic 0x1EFC37C3 
R1# un all

Het voorbeeld toont pakketuitwisselingen onder normale PPP-werking.

De debug ppp negatiation bevoorrechte EXEC-modusopdracht stelt de netwerkbeheerder in staat om de PPP-onderhandelingstransacties te bekijken, het probleem of de fase waarin de fout optreedt te identificeren en een oplossing te ontwikkelen.

Het volgend voorbeeld toont de uitvoer van de opdracht debug ppp negotiation in een normale onderhandeling, waarbij beide partijen het eens zijn over NCP-parameters.

R1# debug ppp negotiation
PPP protocol negotiation debugging is on R1#
*Apr 1 18:42:29.831: %LINK-3-UPDOWN: Interface
Serial0/0/0, changed state to up
*Apr 1 18:42:29.831: Se0/0/0 PPP: Sending cstate UP notification
*Apr 1 18:42:29.831: Se0/0/0 PPP: Processing CstateUp message
*Apr 1 18:42:29.835: PPP: Alloc Context [66A27824]
*Apr 1 18:42:29.835: ppp2 PPP: Phase is ESTABLISHING
*Apr 1 18:42:29.835: Se0/0/0 PPP: Using default call direction
*Apr 1 18:42:29.835: Se0/0/0 PPP: Treating connection as a dedicated line
*Apr 1 18:42:29.835: Se0/0/0 PPP: Session handle[4000002] Session id[2]
*Apr 1 18:42:29.835: Se0/0/0 LCP: Event[OPEN] State[Initial to Starting]
*Apr 1 18:42:29.835: Se0/0/0 LCP: O CONFREQ [Starting] id 1 len 23
*Apr 1 18:42:29.835: Se0/0/0 LCP:	AuthProto CHAP (0x0305C22305)
*Apr 1 18:42:29.835: Se0/0/0 LCP:	QualityType 0xC025 period 1000 (0x0408C025000003E8)
*Apr 1 18:42:29.835: Se0/0/0 LCP:	MagicNumber 0x1F887DD3 (0x05061F887DD3)
<Output omitted>
*Apr 1 18:42:29.855: Se0/0/0 PPP: Phase is AUTHENTICATING, by both
*Apr 1 18:42:29.855: Se0/0/0 CHAP: O CHALLENGE id 1 len 23 from “R1”
<Output omitted>
*Apr 1 18:42:29.871: Se0/0/0 IPCP: Authorizing CP
*Apr 1 18:42:29.871: Se0/0/0 IPCP: CP stalled on event[Authorize CP]
*Apr 1 18:42:29.871: Se0/0/0 IPCP: CP unstall
<Output omitted>
*Apr 1 18:42:29.875: Se0/0/0 CHAP: O SUCCESS id 1 len 4
*Apr 1 18:42:29.879: Se0/0/0 CHAP: I SUCCESS id 1 len 4
*Apr 1 18:42:29.879: Se0/0/0 PPP: Phase is UP
*Apr 1 18:42:29.879: Se0/0/0 IPCP: Protocol configured, start CP. state[Initial]
*Apr 1 18:42:29.879: Se0/0/0 IPCP: Event[OPEN] State[Initial to Starting]
*Apr 1 18:42:29.879: Se0/0/0 IPCP: O CONFREQ [Starting] id 1 len 10
*Apr 1 18:42:29.879: Se0/0/0 IPCP:	Address 10.0.1.1 (0x03060A000101)
*Apr 1 18:42:29.879: Se0/0/0 IPCP: Event[UP] State[Starting to REQsent]
*Apr 1 18:42:29.879: Se0/0/0 IPV6CP: Protocol configured, start CP. state[Initial]
*Apr 1 18:42:29.883: Se0/0/0 IPV6CP: Event[OPEN] State[Initial to Starting]
*Apr 1 18:42:29.883: Se0/0/0 IPV6CP: Authorizing CP
*Apr 1 18:42:29.883: Se0/0/0 IPV6CP: CP stalled on event[Authorize CP]
<Output omitted>
*Apr 1 18:42:29.919: Se0/0/0 IPCP: State is Open
*Apr 1 18:42:29.919: Se0/0/0 IPV6CP: State is Open
*Apr 1 18:42:29.919: Se0/0/0 CDPCP: State is Open
*Apr 1 18:42:29.923: Se0/0/0 CCP: State is Open
*Apr 1 18:42:29.927: Se0/0/0 Added to neighbor route AVL tree: topoid 0, address 10.0.1.2
*Apr 1 18:42:29.927: Se0/0/0 IPCP: Install route to 10.0.1.2
*Apr 1 18:42:39.871: Se0/0/0 LQM: O state Open magic 0x1F887DD3 len 48
*Apr 1 18:42:39.871: Se0/0/0 LQM:	LastOutLQRs 0 LastOutPackets/Octets 0/0
*Apr 1 18:42:39.871: Se0/0/0 LQM:	PeerInLQRs 0 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr 1 18:42:39.871: Se0/0/0 LQM:	PeerOutLQRs 1 PeerOutPackets/Octets 3907/155488
*Apr 1 18:42:39.879: Se0/0/0 LQM: I state Open magic 0xFF101A5B len 48
*Apr 1 18:42:39.879: Se0/0/0 LQM:	LastOutLQRs 0 LastOutPackets/Octets 0/0
*Apr 1 18:42:39.879: Se0/0/0 LQM:	PeerInLQRs 0 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr 1 18:42:39.879: Se0/0/0 LQM:	PeerOutLQRs 1 PeerOutPackets/Octets 3909/155225
<Output omitted>

In dit geval worden protocoltypes IPv4 en IPv6 voorgesteld en bevestigd. De uitvoer omvat de LCP-onderhandeling, authenticatie en NCP onderhandeling.

De opdracht debug ppp error geprivilegieerde EXEC-modus wordt gebruikt om protocolfouten en foutstatistieken weer te geven die verband houden met PPP-verbindingsonderhandeling en -werking, zoals getoond in het volgend voorbeeld.

R1# debug ppp error
PPP Serial3(i): rlqr receive failure. successes = 15 
PPP: myrcvdiffp = 159 peerxmitdiffp = 41091
PPP: myrcvdiffo = 2183 peerxmitdiffo = 1714439 
PPP: threshold = 25
PPP Serial2(i): rlqr transmit failure. successes = 15 
PPP: myxmitdiffp = 41091 peerrcvdiffp = 159
PPP: myxmitdiffo = 1714439 peerrcvdiffo = 2183 
PPP: l->OutLQRs = 1 LastOutLQRs = 1
PPP: threshold = 25
PPP Serial3(i): lqr_protrej() Stop sending LQRs. 
PPP Serial3(i): The link appears to be looped back.

3.4.1.3. Problemen met een PPP-configuratie met authenticatie oplossen

Authenticatie is een functie die correct moet worden geïmplementeerd; anders kan de veiligheid van uw seriële verbinding in gevaar komen. Verifieer uw configuratie altijd met de opdracht show interfaces serial, op dezelfde manier als u doet zonder authenticatie.

Ga er nooit vanuit dat de authenticatieconfiguratie werkt zonder deze te testen met behulp van de eerder behandelde show opdrachten. Als u problemen ontdekt, kunt u met foutopsporing controleren of het probleem met authenticatie te maken heeft en eventuele tekortkomingen corrigeren. Gebruik voor het debuggen van PPP-authenticatie de debug ppp authentication geprivilegieerde EXEC-modus opdracht zoals getoond in het volgend voorbeeld.

R2# debug ppp authentication
Serial0: Unable to authenticate. No name received from peer
Serial0: Unable to validate CHAP response. USERNAME pioneer not found.
Serial0: Unable to validate CHAP response. No password defined for USERNAME pioneer
Serial0: Failed CHAP authentication with remote. Remote message is Unknown name
Serial0: remote passed CHAP authentication. Serial0: Passed CHAP authentication with remote. Serial0: CHAP input code = 4 id = 3 len = 48

Het volgende is een interpretatie van de output:

  • Regel 1 informeert ons dat de router niet kan authenticeren op interface Serial0 omdat de peer geen naam heeft verzonden.
  • Regel 2 zegt dat de router het CHAP-antwoord niet kon valideren omdat de gebruikersnaam “pionier” niet werd gevonden in de lokale routerdatabase.
  • Regel 3 zegt dat er geen wachtwoord is gevonden voor ‘pionier’.
  • In de laatste regel betekent code 4 dat er een fout is opgetreden (andere codewaarden zijn 1 – Challenge, 2 – Response en 3 – Succes). De laatste regel toont ook het ID-nummer van het LCP-pakket (dat wil zeggen, id – 3) en de pakketlengte (dat wil zeggen, len – 48) zonder de koptekst.

3.5. Samenvatting

Seriële transmissies verzenden achtereenvolgens één bit tegelijk over één enkel kanaal. Een seriële poort is bidirectioneel. Synchrone seriële communicatie vereist een kloksignaal.

Point-to-point-links zijn meestal duurder dan gedeelde services; de voordelen kunnen echter opwegen tegen de kosten. Voor sommige protocollen, zoals VoIP, is constante beschikbaarheid belangrijk.

SONET is een optische netwerkstandaard die STDM gebruikt voor efficiënt gebruik van bandbreedte. In de Verenigde Staten zijn OC-transmissiesnelheden gestandaardiseerde specificaties voor SONET.
De bandbreedtehiërarchie die door providers wordt gebruikt, is anders in Noord-Amerika (T-carrier) en Europa (E-carrier). In Noord-Amerika is de fundamentele lijnsnelheid 64 kb/s of DS0. Meerdere DS0’s zijn gebundeld om hogere lijnsnelheden te bieden.

Het demarcatiepunt is het punt in het netwerk waar de verantwoordelijkheid van de dienstverlener eindigt en de verantwoordelijkheid van de klant begint. De CPE, meestal een router, is het DTE-apparaat. De DCE is meestal een modem of CSU/DSU.

Cisco HDLC is een bitgeoriënteerde synchrone datalink-laagprotocoluitbreiding van HDLC; veel leveranciers gebruiken het om multiprotocol-ondersteuning te bieden. Dit is de standaard inkapselingsmethode die wordt gebruikt op Cisco synchrone seriële lijnen.

Synchrone PPP wordt gebruikt om verbinding te maken met niet-Cisco-apparaten, om de linkkwaliteit te bewaken, authenticatie te bieden of links te bundelen voor gedeeld gebruik. PPP gebruikt HDLC voor het inkapselen van datagrammen. LCP is het PPP-protocol dat wordt gebruikt om de datalinkverbinding tot stand te brengen, te configureren, te testen en te beëindigen. LCP kan optioneel een peer authenticeren met PAP of CHAP. Het PPP-protocol gebruikt een familie van NCP’s om gelijktijdig meerdere netwerklaagprotocollen te ondersteunen. Multilink PPP verspreidt het verkeer over gebundelde links door pakketten te fragmenteren en deze fragmenten tegelijkertijd over meerdere links naar hetzelfde externe adres te verzenden, waar ze opnieuw worden samengesteld.

PPP ondersteunt optioneel authenticatie met behulp van PAP-, CHAP- of zowel PAP- als CHAP-protocollen. PAP verzendt authenticatiegegevens in platte tekst. CHAP maakt gebruik van periodieke challenge-berichten en een eenrichtings-hash die helpt beschermen tegen afspeelaanvallen.