Inhoud

Inleiding

Voordat u begint

Conventies

Voorwaarden

Gebruikte componenten

Achtergrondinformatie

STUN-configuratie

STUN Basic-voorbeeldconfiguratie

STUN SDLC-voorbeeldconfiguratie

STUN Multipoint (met lokale ondersteuning) configuratie

Opdrachten weergeven

Probleemoplossing

SDLC-basis voor probleemoplossing

STUN SDLC-oplossing voor problemen met en zonder lokale bevestiging

SDLC Full Multipoint Interface voor probleemoplossing

Gerelateerde informatie

Inleiding

Serial Tunneling (STUN) is het tunnelen van SDLC-frames via een WAN. In de wereld van het traditionele netwerk van systemen (SNA) worden de afstandscontrollers aan de front-end processor (FEP) bevestigd door een set modems aangesloten via POTS (Plain Old Telephone Service) of huurlijnen.

Voordat u begint

Conventies

Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.

Voorwaarden

STUN SDLC wordt het meest gebruikt in twee omgevingen: FEP naar afstandsbediening, en AS/400 naar afstandsbediening.

Gebruikte componenten

Problemen oplossen bij STUN met Cisco IOS® Software opdrachten en AS/400 voor specifieke problemen met afstandsbediening.

Achtergrondinformatie

Aangezien netwerken zich naar integratie bewegen en kantoren op afstand een ander soort diensten vereisen (zoals Netopgemerkt, IP, IPX), was het vanuit het oogpunt van onderhoud en kosten logisch om al deze diensten in één apparaat te integreren. In het volgende schema zien we bijvoorbeeld de integratie van 3270 terminals in de host met het Netbiose-verkeer van Windows-stations.

STUN geeft u toestemming om IP te gebruiken als een transport voor Synchronous Data Link Control (SDLC)-frames via een WAN- of ander media-netwerk. Dit heft de noodzaak van een extra huurlijn of POTS op. Eén SDLC-functie van Cisco-routers is mediavertaling. In mediavertaling, vertaalt de router de sessie van SDLC naar Logical Link Control, type 2 (LLC2). Dit wordt uitvoerig besproken in het begrip en de probleemoplossing van SDLC in het LLC-netwerkmediaconvertaling.

Er zijn twee soorten STUN-configuraties: STUN Basic en STUN SDLC. De eerste wordt gebruikt voor alle derivatenframes van High-Level Data Link Control (HDLC) en de tweede wordt gebruikt voor uitsluitend SDLC-frames. STUN Basic kan ook worden gebruikt voor SDLC, maar functies zoals lokaal gesprek kunnen niet worden gebruikt. Het is gebruikelijk om STUN Basic te gebruiken voor SDLC voor probleemoplossing omdat SDLC-specifieke parameters niet op de router hoeven te worden geconfigureerd.

STUN-configuratie

De eerste opdracht voor elke STUN-configuratie (Basic of SDLC) is een duidelijke peer-name. Zonder naad peer-name, zal de router u niet met de configuratiestappen laten verder.

Taak

Opdracht

Schakel STUN in voor een bepaald IP-adres.

stun peer-name ip-address

U moet een geldig IP-adres uit de router selecteren. Dit IP-adres moet de meest betrouwbare interface in het vak zijn. Voor de beste resultaten, vorm de router met een loopback interface. (Meer informatie over het configureren van loopback interfaces.

De volgende stap is het bepalen van de STUN-modus die u wilt gebruiken. Een modus is STUN Basic, waarin het op basis en afbakening van het frame [7e] kijkt en het frame naar de andere kant transporteert. In deze manier van functioneren, geeft STUN niet om de specifieke status van de sessie of gedetailleerde SDLC informatie, zoals het stemadres. De andere modus is STUN SDLC. Deze modus vereist gedetailleerdere beslissingen in de router, vooral als u een lokale erkenning of een type multipoint hebt. De opdrachten die worden gebruikt om een STUN-modus te specificeren, worden in de onderstaande tabel beschreven:

Taak

Opdracht

Specificeer een basisprotocolgroep en wijs een groepsnummer toe.

stun protocol-group group-number basic

Specificeer een SDLC-protocolgroep en wijs een groepsnummer toe.

stun protocol-group group-number sdlc

De volgende stap is het configureren van de seriële interface voor STUN. De groep die u in de interface selecteert, moet overeenkomen met de groep die in de protocolgroep is gedefinieerd. Met virtuele multipoints moet u ook een gemengde protocol-groep definiëren met verschillende nummers voor elk van de virtuele multipoints. Zorg er altijd voor dat u slechts één secundaire interface per studiegroep hebt ingesteld, tenzij u sdlc-tg configureren. Zie Stun protocol-groep.

Taak

Opdracht

Schakel de functie STUN in op een seriële interface.

encapsulation stun

Plaats de interface in een eerder gedefinieerde STUN-groep.

stun group group-number

Opmerking: configureer dit niet op een Cisco 7000, Cisco 7500 of een andere router met een CxBUS, CyBUS tijdens de duur van het productienetwerk. Deze configuratie zorgt ervoor dat de router MTU van de interface in 2032 bytes wijzigt, die resulteren in een CBUS-bufferschijf en alle interfaces van de router stuiteren (reset). In een Token Ring-omgeving kan het betekenen dat Token Rings tot 16 seconden naar beneden gaat. Bovendien, omdat Cisco 7000 vaak het centrum van de kern is waar dit type probleem vele gebruikers beïnvloedt.

De volgende stap in het configureren van STUN is het toevoegen van de verdovende route verklaring. U kunt dit definiëren als verstoppingsroute of stut route [adres]. De configuratieopties zijn hieronder uitgelegd.

Taak

Opdracht

Doorsturen van al het TCP-verkeer voor dit IP-adres.

stun route all tcp ip-address

Specificeer TCP-insluiting.

stun route address address-number tcp ip-address [priority] [tcp-queue-max]

De bovenstaande opdrachten zijn voor TCP-insluitingstypen. U kunt ook STUN configureren voor rechtstreekse insluiting, maar deze configuratie wordt zelden gebruikt. Het meest algemene van alle configuraties is de lokale bevestiging van STUN.

Deze opdrachtparameters worden hieronder beschreven:

- De prioriteitsoptie in de stunroute statement wordt gebruikt om meerdere TCP buizen tussen twee STUN peers te maken zodat prioriteitsstructuren kunnen worden gecreëerd door gebruik van een aangepaste wachtrij of prioriteitswachtrij.

- De optie tcp_wachtrij_max wordt verhoogd of verlaagd de TCP-wachtrijen tussen de twee STUN-peers. Dit is handig als de TCP sessie tussen de peers niet erg betrouwbaar is en je moet bepalen wat er mis is tussen de peers. Deze optie wordt niet vaak gebruikt in STUN-omgevingen, behalve wanneer STUN FEP-to-FEP wordt uitgevoerd waar meer verkeer bij betrokken is.

De opdrachten die worden gebruikt om STUN met een lokale bevestiging te configureren worden hieronder beschreven.

Taak

Opdracht

Pas de STUN-enabled router en SDLC primaire rol aan.

stun sdlc-role primary

Wijs de STUN-enabled router en SDLC secundaire rol toe.

stun sdlc-role secondary

Deze opdrachten definiëren de "rol" van de STUN-instellingen. In het geval van de gastheer in het bovenstaande diagram wordt de router op primair geplaatst, wat betekent dat de gastheer degene is die de zitting initieert. Dit maakt de 3174 secundair. Wanneer je STUN Basic gebruikt, hoef je de rol niet te definiëren, omdat je niet hoeft te weten wie de sessie gaat initiëren. Maar de lokale erkenning vereist details van de lijn zelf en het bepalen van de rol laat de router de stroom van de zitting opstarten kennen, die de router moet verifiëren alvorens naar lokale erkenning te bewegen.

Opmerking: In AS/400 STUN-omgevingen die plaatselijke erkenning geven, is het erg belangrijk om de rol (op de lijnbeschrijving) in te stellen op *pri vanaf *neg. De reden hiervoor is dat in een zuiver milieu (directe modemverbinding) de AS/400 de rol kan onderhandelen. Door de rol te coderen die we in de lijn zullen spelen, kunt u verzekeren dat de rol van de router tegengesteld is aan de AS/400. U wilt gewoonlijk dat de AS/400 de sessie (met "variëren" van de lijn) initieert. Ga naar de lijnconfiguratie en stel dit in voor *pri. De beschrijving van de AS/400-weergavelijn wordt hierna weergegeven. Dit kan alleen worden gedaan bij het maken/kopiëren van de lijnbeschrijving.

De opdracht om STUN met een lokale bevestiging te configureren wordt hieronder uitgelegd.

Taak

Opdracht

Installeer SDLC lokale erkenning met behulp van TCP-insluiting.

stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

De belangrijke parameter hier is de stunroute [adres] met lokaal rek. Vergeet niet dat STUN local-ack met TCP-insluiting en Frame Relay-insluiting kan worden gerealiseerd (met behulp van RFC 1490).

Zoals in RSRB en DLSw, houdt u in STUN flow tussen de TCP-peers bij om ervoor te zorgen dat de peer verbinding omhoog is. U kunt de keepalives aanpassen als uw collega's naar beneden of naar boven gaan vanwege het verlies van de levensduur. De opdrachten STUN die worden gebruikt om keepalives te configureren worden hieronder beschreven:

Taak

Opdracht

Schakel detectie van een verloren peer op afstand in.

stun remote-peer-keepalive seconds

Aantal keren om een peer verbinding te proberen alvorens de peer "down" te verklaren.

Aantal stuks houdt aantal

STUN Basic-voorbeeldconfiguratie

STUN Basic is de eenvoudigste configuratie van STUN. In deze modus worden alle pakketten die de router van één kant ontvangt, naar het volgende verzonden. In het onderstaande schema is een basisconfiguratie voor STUN weergegeven:

De routers in het bovenstaande schema zijn als volgt geconfigureerd:

4700

2522

Current configuration:

!

version 10.3

service udp-small-servers

service tcp-small-servers

!

hostname s5e

!

stun peer-name 10.17.5.1

stun protocol-group 1 basic

!

interface Loopback1

no ip address

!

interface Serial0

ip address 10.17.5.1 255.255.255.0

clockrate 2000000

!

interface Serial1

no ip address

encapsulation stun

nrzi-encoding

clockrate 56000

stun group 1

stun route all tcp 10.17.5.2

!

Current configuration:

!

version 11.0

no service pad

service udp-small-servers

service tcp-small-servers

!

hostname rick

!

stun peer-name 10.17.5.2

stun protocol-group 1 basic

!

interface Serial0

ip address 10.17.5.2 255.255.255.0

no fair-queue

no cdp enable

!

interface Serial1

ip address 10.17.92.4 255.255.255.0

no fair-queue

no cdp enable

!

interface Serial2

no ip address

encapsulation stun

nrzi-encoding

clockrate 56000

stun group 1

stun route all tcp 10.17.5.1

STUN SDLC-voorbeeldconfiguratie

4700

2522

Current configuration:

!

version 10.3

service udp-small-servers

service tcp-small-servers

!

hostname s5e

!

stun peer-name 10.17.5.1

stun protocol-group 1 sdlc

!

interface Loopback1

no ip address

!

interface Serial0

ip address 10.17.5.1 255.255.255.0

clockrate 2000000

!

interface Serial1

no ip address

encapsulation stun

nrzi-encoding

clockrate 56000

stun group 1

stun sdlc-role secondary

sdlc address DD

stun route address DD tcp 10.17.5.2

!

Current configuration:

!

version 11.0

no service pad

service udp-small-servers

service tcp-small-servers

!

hostname rick

!

stun peer-name 10.17.5.2

stun protocol-group 1 sdlc

!

interface Serial0

ip address 10.17.5.2 255.255.255.0

no fair-queue

no cdp enable

!

interface Serial1

ip address 10.17.92.4 255.255.255.0

no fair-queue

no cdp enable

!

interface Serial2

no ip address

encapsulation stun

nrzi-encoding

clockrate 56000

stun group 1

stun sdlc-role primary

sdlc address DD

stun route address DD tcp 10.17.5.1

STUN Multipoint (met lokale ondersteuning) configuratie

4700

2522

hostname s5e

!

!

!

stun peer-name 10.17.5.1

stun protocol-group 1 sdlc

stun remote-peer-keepalive 5

!

interface Serial0

ip address 10.17.5.1 255.255.255.0

clockrate 2000000

!

interface Serial1

no ip address

encapsulation stun

idle-character marks

nrzi-encoding

clockrate 56000

stun group 1

stun sdlc-role secondary

sdlc K 1

sdlc address 01

sdlc address DD

stun route address 1 tcp 10.17.5.2 local-ack

stun route address DD tcp 10.17.5.2 local-ack

!

hostname rick

!

!

!

stun peer-name 10.17.5.2

stun protocol-group 1 sdlc

stun remote-peer-keepalive 5

!

interface Serial0

ip address 10.17.5.2 255.255.255.0

no fair-queue

no cdp enable

!

interface Serial2

no ip address

encapsulation stun

nrzi-encoding

clockrate 56000

stun group 1

stun sdlc-role primary

sdlc address DD

stun route address DD tcp 10.17.5.1 local-ack

!

interface Serial3

no ip address

encapsulation stun

clockrate 19200

stun group 1

stun sdlc-role primary

sdlc address 01

stun route address 1 tcp 10.17.5.1 local-ack

Opmerking: Op de AS400-router hebben we sdlc k1- en idle-karakter-tekens gebruikt. Raadpleeg het gedeelte Veldwaarschuwing voor meer informatie.

Opdrachten weergeven

De eerste show opdracht gebruikt met STUN is show stun. De output van deze opdracht hangt af van of u STUN Basic of STUN SDLC gebruikt met lokale ondersteuning. In het onderstaande gedeelte STUN Basic ziet u alleen pakketten die worden verzonden en ontvangen.

rick#sh stun

This peer: 10.17.5.2

*Serial2  (group 1 [basic])

state       rx_pkts   tx_pkts     drops

all     TCP 10.17.5.1        closed           5729      5718         0

In de STUN SDLC wordt hieronder het aantal lokale links weergegeven. U krijgt meer informatie omdat nu de status van de sessie bekend is.

rick#sh stun

This peer: 10.17.5.2

*Serial2  (group 1 [sdlc])

state       rx_pkts   tx_pkts     drops    poll

DD     TCP 10.17.5.1        open       *      182        94         0

Serial3  (group 1 [sdlc])

state       rx_pkts   tx_pkts     drops    poll

1     TCP 10.17.5.1        open       *      209        89         0

SDLC Local Acknowledgement:

*Serial2  (group 1 [sdlc])

slack_state conn disc iframe_s iframe_r

DD     TCP 10.17.5.1                  Active    1    0        0        0

Serial3  (group 1 [sdlc])

slack_state conn disc iframe_s iframe_r

1     TCP 10.17.5.1                  Active    1    0        3        3

De opdracht Show interface geeft ook verschillende informatie, afhankelijk van of u STUN Basic of STUN SDLC gebruikt. De show interface voor STUN Basic is hetzelfde als voor een regelmatige serielijn.

Serial2 is up, line protocol is up

Hardware is CD2430 in sync mode

MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation STUN, loopback not set

Last input 1:10:40, output 0:18:12, output hang never

Last clearing of "show interface" counters 0:21:49

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4 packets output, 312 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets, 0 restarts

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

De show interface voor STUN SDLC met lokale erkenning biedt meer informatie. De voorbeelduitvoer voor een seriële interface met lokale ingang wordt hieronder weergegeven.

Serial3 is up, line protocol is up

Hardware is CD2430 in sync mode

MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation STUN, loopback not set

Router link station role: PRIMARY (DCE)

Router link station metrics:

slow-poll 10 seconds

T1 (reply time out) 3000 milliseconds

N1 (max frame size) 12016 bits

N2 (retry count) 20

poll-pause-timer 10 milliseconds

poll-limit-value 1

k (windowsize) 7

modulo 8

sdlc addr 01 state is CONNECT

VS 1, VR 0, Remote VR 1, Current retransmit count 0

Hold queue: 0/200 IFRAMEs 16/12

TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0

RNRs 316/0 SNRMs 2/0 DISC/RDs 1/0 REJs 0/0

Poll: clear, Poll count: 0, ready for poll, chain: 01/01

Last input 0:00:00, output 0:00:00, output hang never

Last clearing of "show interface" counters 1d06

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 1 packets/sec

5 minute output rate 0 bits/sec, 1 packets/sec

332226 packets input, 664647 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

332227 packets output, 665220 bytes, 0 underruns

0 output errors, 0 collisions, 3444 interface resets, 0 restarts

0 output buffer failures, 0 output buffers swapped out

5 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Delen van deze productie worden hieronder verklaard:

- MTU is de fysieke grootte van de buffer die de interface gebruikt.

- PRIMARY (DCE) betekent dat dit het stembureau op de draad is en dat we de klok tikken. Als we zouden kijken naar de kant die aan de echte primaire basis is gekoppeld, zou deze productie SECONDARY zijn geweest.

- N1 is de waarde van de bruikbare grootte van het SDLC frame die door de seriële interface van de router kan worden ingepast.

- T1 is de hoeveelheid tijd die we verwachten dat er een antwoord is op een enquête voordat de rij is afgesloten.

- opdarm is de delta tijd in msec tussen opiniepeilingen.

- k is de venstergrootte of het aantal frames dat we tussen de finale van de enquête kunnen uitreiken.

- staat is de huidige status van de zitting , die één van de volgende staten kan zijn :

- ONTKOPPELEN

- VERBONDEN

- THEMBUSY (gewoonlijk ingesteld als resultaat van deze router die een RNR ontvangt)

- USBUSY (meestal een resultaat van het niet terugkrijgen van een reactie op het netwerk.)

- RNR's is het aantal verzonden/ontvangen RNR's.

- DTR/RTS zijn de lijnen die in de meeste halfduplex multidrop-omgevingen worden gebruikt. Wanneer u een STUN-omgeving zuivert en naar de locatie van de controller kijkt, let dan goed op RTS. Als dit met tussenpozen daalt terwijl DTR en CTS hoog zijn, is het zeer waarschijnlijk dat de DTE halfduplex is.

De laatste belangrijke show opdracht voor STUN is de show tcp opdracht, die informatie over de TCP sessie tussen de peers verstrekt. De voorbeelduitvoer wordt hieronder weergegeven:

Stand-alone TCP connection from host 10.17.5.1

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host: 10.17.5.2, Local port: 1994

Foreign host: 10.17.5.1, Foreign port: 11035

Enqueued packets for retransmit: 0, input: 0, saved: 0

Event Timers (current time is 0x1B2E50):

Timer          Starts    Wakeups            Next

Retrans           229          0             0x0

TimeWait            0          0             0x0

AckHold           229          0             0x0

SendWnd             0          0             0x0

KeepAlive           0          0             0x0

GiveUp              0          0             0x0

PmtuAger            0          0             0x0

iss: 2847665974  snduna: 2847667954  sndnxt: 2847667954     sndwnd:   9728

irs: 3999497423  rcvnxt: 3999499452  rcvwnd:       9672  delrcvwnd:    568

SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms

minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 300 ms

Flags: passive open, higher precedence

Datagrams (max data segment is 1460 bytes):

Rcvd: 459 (out of order: 0), with data: 229, total data bytes: 2028

Sent: 457 (retransmit: 0), with data: 228, total data bytes: 1979

Probleemoplossing

Problemen oplossen is een STUN-configuratie hetzelfde als bij elke peer-to-peer conventie. Als u problemen hebt in het transport, moet dit worden gediagnosticeerd voordat u een oplossing kunt vinden voor het SDLC/STUN-gedeelte. Meestal is de eerste stap om van peer aan peer te pingelen om ervoor te zorgen dat IP correct wordt ingesteld. ping met uitgebreide pakkettypen om er zeker van te zijn dat het transport betrouwbaar is.

SDLC-basis voor probleemoplossing

Deze sectie behandelt de probleemoplossing van een STUN Basic Setup. In dit voorbeeld, veronderstel dat WAN correct functioneert.

Dit scenario heeft een STUN Basic-instelling om de 5494 te verbinden met de AS/400. Het eerste ding om met elke STUN-instelling te controleren is dat de peers in de router zijn ingesteld. Om dit te bepalen, gebruik de show Stun peer opdracht. Het geeft informatie over de status van de peer en de pakketten die werden verzonden/ontvangen. De voorbeelduitvoer wordt hieronder weergegeven:

rick#sh stun peer

This peer: 10.17.5.2

*Serial2  (group 1 [basic])

state       rx_pkts   tx_pkts     drops

all     TCP 10.17.5.1        open             5729      5718         0

Als de peer, zoals hierboven, open is, gebruik de showinterface en om te bepalen wat er met de pakketten gebeurt. De voorbeelduitvoer voor deze opdracht wordt hieronder weergegeven:

Serial2 is up, line protocol is up

Hardware is CD2430 in sync mode

MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation STUN, loopback not set

Last input 1:10:40, output 0:18:12, output hang never

Last clearing of "show interface" counters 0:21:49

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4 packets output, 312 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets, 0 restarts

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Controleer eerst of de router alle seriële signalen heeft. Onder aan de bovenstaande output kunnen we zien dat alle signalen "omhoog" zijn voor "Serial2" op de 2522. DTR en RTS geven aan dat de controller de lijn zelf al heeft geactiveerd en wacht op de AS/400 om de eerste conversatie te versturen.

Controleer vervolgens de show interface voor de kant van de router AS/400. In de hieronder weergegeven uitvoer zien we dat de seriële interface die aan de AS/400 is gekoppeld, is neergezet of omlaag. Dit betekent dat de AS/400 waarschijnlijk "afgevinkt" is. Als de lijn "gevarieerd aan" is en u de lijn niet kunt omhoog krijgen of half-duplex draait, dan moet u de verbinding RS-232/V.35 controleren.

Serial1 is down, line protocol is down

Hardware is HD64570

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation STUN, loopback not set

Last input never, output 1:51:24, output hang never

Last clearing of "show interface" counters 0:00:01

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets, 0 restarts

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=down  RTS=down  CTS=up

s5e#

Controleer op dit punt "Werk met configuratiestatus" voor die specifieke controller, een AS/400-scherm dat er zo uitziet:

Daarna varieert de lijndefinitie. U zou dan moeten zien dat de router omhoog/omhoog gaat. Als de regel omhoog/omhoog komt maar de controller nog steeds niet komt, controleer dan de interface om te controleren of er pakketten zijn die de interface binnenstebuiten van de AS/400 hebben bereikt. Als het aantal nul is, controleer dan het coderingsmechanisme voor de SDLC-lijn op de AS/400. Dit bevindt zich op de beschrijving van de weergavelijn, zoals hieronder wordt getoond.

Opmerking: Op dit scherm zien we dat de regel-codering is ingesteld voor NRZI-codering. Dit moet worden ingeschakeld met de configuratie optie nezi-codering op de router.

Voor deze instelling is geen NRZ/NRZI-codering nodig, zoals bij conventionele SDLC point-to-point conventies, maar wel NRZI aan de ene kant en NRZ aan de andere kant. Maar vergeet niet dat de codering hetzelfde moet zijn tussen apparaten die de SDLC-lijn delen.

NRZI vraagt om zorgvuldige overweging. In de nieuwe routers zoals Cisco 2500 en 4500 wordt NRZI via software ingesteld. Maar met oudere platforms, waaronder de NP-2T voor Cisco 4000, moet u de pull-overs in de borden zelf wijzigen. In dergelijke gevallen is het waarschijnlijk gemakkelijker om de AS/400 in NRZ/NRZI te veranderen. Maar als u de pull-overs wilt wijzigen, raadpleegt u de Cisco-hardwaredocumentatie voor uw specifieke platform.

Als het probleem blijft optreden, voert u een debug-pakket 1 uit. Deze opdracht geeft u de volgende informatie:

STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

%LINK-3-UPDOWN: Interface Serial1, changed state to down

STUN basic: 0:00:38 Serial1         SDI:   Data: c0bf324c056452530000

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

%LINK-3-UPDOWN: Interface Serial1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

%LINK-3-UPDOWN: Interface Serial1, changed state to down

U ziet verschillende XID's uit de AS/400 vloeien, maar er was geen reactie op deze reacties (CO is het stemadres en bf is de XID). We weten dat het pakje van de AS/400 komt omdat het pakje van SDI afkomstig is. Er zijn twee typen inkomende pakketten in deze opdrachtoutput:

- SDI: Seriaal inkomend, dat pakketten worden ontvangen van de SDLC interface.

- DBI: Netwerk inkomend, die pakketten worden gekapseld van WAN.

Kijk vervolgens naar het XID-gedeelte van het frame zelf. In dit voorbeeld stuurt de AS/400 een XID samen met zijn IDBLOCK en IDNUM, 05645253.

Dit is een tijdelijke kwestie, omdat de controller niet reageert. In de AS/400, kijk naar de "systeemberichtenrij" om te zien of er berichten zijn die een probleem aangeven. Hieronder verschijnt een "SYSOPR"-scherm met een storing.

Nu op 2522, schakel debug-pakket 1 in om te zien of de pakketten naar de controller worden verzonden. De voorbeeldopdrachtoutput wordt hieronder weergegeven:

STUN basic: 0:00:34 Serial2         NDI:   Data: c0bf324c056452530000

STUN basic: 0:00:42 Serial2         NDI:   Data: c0bf324c056452530000

Dit toont aan dat de XID die afkomstig was van de AS/400-zijde, doorloopt naar de controller, maar de controller reageert niet, wat betekent dat het een controleprobleem is. Een show interface laat ons zien of alle control I.S. lopen omhoog of niet:

Serial2 is up, line protocol is up

Hardware is CD2430 in sync mode

MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation STUN, loopback not set

Last input 0:50:56, output 0:00:23, output hang never

Last clearing of "show interface" counters 0:02:06

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

1 packets output, 78 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets, 0 restarts

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

De inlopen van de controle zijn omhoog en de interface verschijnt. We kunnen ook zien dat de router pakketten uitbesteedt, maar er worden geen pakketten binnengebracht. Dit duidt op het incorrecte stemadres dat is ingesteld op de AS/400, dus de volgende stap is het controleren van het stemadres van de controller.

Elk type controller heeft een unieke manier om het stemadres te configureren. U moet dit dus controleren met de controller-handleidingen voor uw controller.

In dit voorbeeld ontdekten we dat de controller het stemadres "DD" gebruikte. Nadat u dit op de AS/400 hebt gewijzigd, wordt de uitvoer van het debug-pakket:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000

STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000

STUN basic: 0:00:00 Serial2         NDI:   Data: dd93

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

STUN basic: 0:00:00 Serial2         NDI:   Data: dd11

STUN basic: 0:00:00 Serial2         SDI:   Data: dd11

STUN basic: 0:00:00 Serial2         NDI:   Data: dd11

STUN basic: 0:00:00 Serial2         SDI:   Data: dd102f00000200016b80

STUN basic: 0:00:00 Serial2         NDI:   Data: dd31

STUN basic: 0:00:00 Serial2         SDI:   Data: dd11

STUN basic: 0:00:00 Serial2         NDI:   Data: dd31

STUN basic: 0:00:00 Serial2         SDI:   Data: dd11

.

.

.

.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd31

STUN basic: 0:00:00 Serial2         SDI:   Data: dd71

STUN basic: 0:00:00 Serial2         NDI:   Data: dd362f00020080004b80

STUN basic: 0:00:00 Serial2         NDI:   Data: dd31

STUN basic: 0:00:00 Serial2         NDI:   Data: dd53

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Deze debug uitvoer helpt u de volgende informatie te bepalen:

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000

Deze lijn bevat de XID van de AS/400 naar de controller. Dit komt van NDI (afkomstig van de cloud), dd (stemadres), bf (de XID) en het IDBLOCK en IDNUM (05645253).

STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000

Dit is het antwoord van de verantwoordelijke. Dit is aangegeven door SDI (afkomstig van SDLC-lijn) en hetzelfde als hierboven, met uitzondering van de XID-respons (073000dd), omdat dit een 5494 is.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd93

Dit is de SNRM (93) van de AS/400 tot de controller, de primaire in deze configuratie.

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Hier zien we dat de controller reageert met een UA (73), wat betekent dat de sessie aan de gang is. Daarna moeten we zien dat de verbinding komt vanaf de AS/400 toen de lijn afgevinkt was.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd53

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Deze lijnen tonen de DISK (53) en de UA respons. De grens is nu naar beneden. Na is een tabel met waarden die nodig zijn om deze problemen op te lossen.

Control-veld - ongenummerd (1 bytes)

000z 0011

0001 0111

0001 0111

0001 1111

0011 0011

0101 0011

0101 0011

0101 0011

0111 0011

1001 0011

1001 0111

101z 1111

110z 0111

111z 0011

03-13    UI

07-17    SIM

07-17    RIM

0F-1F    DM

23-33    UP

43-53    DISC

43-53    RD

43-53    RD

63-73    UA

83-93    SNRM

87-97    FRMR

AF-BF    XID

C7-D7    CFGR

E3-F3    TEST

Unnumbered Information

Set Initialization mode

Request Intialization Mode

Secondary in Disconnect Mode

Unumber Poll

Disconnect

Request Disconnect

Secondary Requests Disconnect

Unnumbered Acknowledgement

Set Normal Response Mode

Frame Reject

Exchange Identification

Configure

I-Field contains test pattern

Bedieningsveld - Toezicht (2 bytes)

rrrz cc01

rrrz 0001

rrrz 0101

rrrz 1001

xx-xx

x1-x1

x5-x5

x9-x9

Supervisory Format

Receiver Ready

Receiver Not Ready

Reject

Bedieningsveld - Informatiesoframes (2 bytes)

rrr1 sssz

xx-xx

Information format

Sleutel:

z = Het laatste poll-bit kan 0 of 1 zijn

rr = Aantal naar verwachting ontvangen blokken

sss = Aantal verzonden blokken

STUN SDLC-oplossing voor problemen met en zonder lokale bevestiging

In dit gedeelte wordt hetzelfde scenario beschreven, waarbij de lokale bevestiging is ingesteld.

In tegenstelling tot STUN Basic, vereist STUN SDLC dat u het juiste stemadres specificeert of de router de pakketten niet eens zal zien binnenkomen. Dit is waarom STUN Basic soms wordt gebruikt om het stemadres te vinden als je de informatie niet hebt, of niet bij de gastheer of de AS/400 kunt krijgen. Het diagram hierboven toont een multipoint scenario met lokale hulp.

In een traditionele point-to-point omgeving eindigt de stemming steeds. Wanneer lokale erkenning wordt geïntroduceerd, wordt de opiniepeiling beëindigd aan elk eind van de cloud, zodat elke router een eindige staatsmachine moet behouden. Deze machine houdt alle sessies bij en moet de status van de lijn kennen voor elk stembureau. Daarom moet u ervoor zorgen dat de stations het SDLC-protocol volgen.

Controleer eerst of u de juiste STUN-rol hebt. AS/400's hebben moeite om de rol met de controller te onderhandelen in traditionele point-to-point omgevingen. De lijnbeschrijving wordt hierna weergegeven.

Dit toont ons dat de router interface moet worden geconfigureerd voor een secundaire rol. Controleer altijd de regel en controleer of deze *PRI is, omdat de AS/400 standaard op *NEG staat wanneer u deze maakt. NRZI is ingesteld op *YES, dus je moet de podiumcodering coderen. Tevens worden de tekens uit het onduidelijke teken van de code en het venster op één (1) ingesteld met sdlc k 1. (Raadpleeg de waarschuwing voor het veld FNA-IOS-0696-02 voor een diepgaande beschrijving van de reden waarom onduidelijke tekens op de interface vereist zijn.) Deze codering wordt hieronder weergegeven:

interface Serial1

no ip address

encapsulation stun

idle-character marks

nrzi-encoding

clockrate 56000 (real clockrate on the line; see note about as400 line speed)

stun group 1

stun sdlc-role secondary (this must be secondary because the line is primary)

sdlc K 1

sdlc address 01

sdlc address DD

stun route address 1 tcp 10.17.5.2 local-ack

stun route address DD tcp 10.17.5.2 local-ack

Opmerking: het blokkeren dat de router biedt, is onafhankelijk van de Line snelheidsparameter die op de AS/400-lijn wordt ingesteld. (Deze parameter wordt gebruikt voor prestatieberekeningen; het kan standaard 9600 staan.) De op de lijn gevormde Exchange-identificator is die van de AS/400, zoals de XID die de AS/400 zal verzenden. De maximale controllers is het aantal PU's (controllers) dat aan deze lijn kan worden toegevoegd.

De eerste van de twee controllers die aan deze regel zijn gekoppeld, een IBM 5494, wordt in het onderstaande scherm weergegeven.

We kunnen zien dat de eerste controller een PU 2.1 zal zijn omdat de categorie van de controller "*APPC" is. Dit is de afkorting voor Advanced Program-to-Program Communications, die alleen via een T2.1-verbinding kan worden verwezenlijkt. De identificatie van het externe netwerk is opnieuw gerelateerd aan APPN/APPC en wordt "NETID" genoemd. "*NETATR" is een parameter die aangeeft hoe NETID wordt gebruikt, gedefinieerd in het gegevensgebied genaamd "Netwerkkenmerken". U kunt dit gegevensgebied weergeven met de opdracht DSPNETA en de waarden dienovereenkomstig vervangen. Het "Remote Control point" of "CP_name" is de naam van het bedieningspaneel die u in de PU2.1 hebt ingesteld. In dit geval is het CP5494. De rol van de datalink kan als *NEG worden achtergelaten. Het "Adres van het Station" moet overeenkomen met het "sdlc-adres DD" dat zowel op de secundaire interface als op een van de primaire interfaces is geconfigureerd.

interface Serial2

no ip address

encapsulation stun

nrzi-encoding

clockrate 56000

stun group 1

stun sdlc-role primary

sdlc address DD

stun route address DD tcp 10.17.5.1 local-ack

U kunt zien dat de meeste informatie die in de beschrijving van de controller zit, relevant is voor de fysieke eenheid zelf, en niet aanpasbaar voor de router.

Op dit scherm is de tweede controller (PU) feitelijk een 3174, wat een PU type 2 is. De XID ingesteld in deze 3174 is 05600001. Het "Station-adres", of het sdlc-adres dat gebruikt wordt, is 01. Je hebt een "sdlc-adres ingesteld" op de secundaire interface en een van de externe primaire interfaces. Zoals u hieronder kunt zien, is de configuratie voor een PU2 minder betrokken dan een PU2.1.

interface Serial3

no ip address

encapsulation stun

clockrate 19200

stun group 1

stun sdlc-role primary

sdlc address 01

stun route address 1 tcp 10.17.5.1 local-ack

De kenmerken van de weergavenetwerken (DSPNETA) in de AS/400 worden hierna weergegeven:

Dit scherm toont aan dat AS/400 momenteel is ingesteld voor Network-ID "NETA", wat betekent dat de 5494 moet worden geconfigureerd voor hetzelfde netwerk. Dit, evenals de rest van de APPN-specifieke configuratie, kan worden gevonden op het tweede configuratiescherm in de 5494. De lokale naam van het controlepunt van AS/400 is "RTP400A." De LU-naam van de AS/400 is "LU9404;" dit moet overeenkomen met wat is ingesteld in het definitieveld voor partner LU van 5494. De modembeschrijving die door de 5494 wordt gebruikt moet overeenkomen met wat in de beschrijving van het apparaat staat. Bijvoorbeeld, als het apparaat "*NETATR" zegt dan moet het de standaard van "BLANK" matchen.

De beschrijving van het APPC-apparaat dat voor de 5494 is gemaakt, wordt hieronder weergegeven.

Dit scherm laat zien dat de apparaatbeschrijving voor de 5494 een naam van de Remote CP heeft van "CP5494;" dit moet overeenkomen met wat is ingesteld op de 5494. NETID en de lokale locatie zijn failliet gegaan aan "*NETATR", die in het vorige voorbeeld gecodeerd waren aan LU9404 en NETA. Nogmaals, deze moeten de partner LU naam en de NETID velden in de 5494 aanpassen.

Het laatste stukje van de apparaatconfiguratie dat relevant is voor het opzetten van een verbinding wordt hieronder weergegeven.

Dit scherm toont aan dat de modus die op de beschrijving van het apparaat wordt gebruikt "QRMTWSC" is. Dit is niet de standaardinstelling in *NETATR, dus dit betekent dat het is overschreven in de apparaatbeschrijving. Dit is een van de standaardmodi die IBM aanbiedt als onderdeel van de basis-APPN-ondersteuning op de AS/400. Als u iets anders ziet, neem dan contact op met IBM omdat deze actief zijn met een beschrijving van de modus die ze hebben gemaakt. In dit voorbeeld wordt een basisverbinding tot stand gebracht; Als u informatie wilt weergeven over de beschikbare modi, kunt u de opdracht WDM of de beschrijving van de werkmodus gebruiken.

De modembeschrijving wordt hierna weergegeven.

Dit scherm identificeert duidelijk de Mode definities van IBM.

SDLC Full Multipoint Interface voor probleemoplossing

Wanneer u lokale erkenning in een multi-point omgeving met AS/400 doet, houd dan rekening met hoe de "SDLC Full Duplex Multipoint interface" is geïmplementeerd op de AS/400, SYS/38 en SYS/36 mini-mainframes. De FNA-IOS-0696-02 veldwaarschuwing (hieronder opgenomen) verklaart het type problemen dat in deze situatie kan voorkomen.

Korte beschrijving

De wijziging van de routerkabel die "drager detectie" met aarding verbindt zal geen periodieke SDLC-lijnresets van een AS/400 voorkomen als de AS/400 IBM PTF# MF10030 heeft toegepast. Dit alarm is alleen van toepassing op STUN full duplex multi-drop verbindingen naar een AS/400 waar de router SDLC-kabel is aangepast om dragerdetectie uit te schakelen.

impact

De gebruikers kunnen een periodieke reset ervaren van de STUN-verbinding en alle SDLC-secundaire apparaten, wat kan leiden tot een onbetrouwbare verbinding.

Volledige beschrijving/achtergrond

In een omgeving met meerdere uitgangen gedraagt een AS/400 zich anders dan andere IBM-apparaten. Terwijl een FEP of 0x7E karakters (vlaggen) of 0xFF (markeringen) als "lege" ruimte tussen frames accepteert, behandelt een AS/400 vlaggen en markeringen op verschillende manieren. Alleen een teken wordt als een onklaar teken uitgelegd. Een vlag wordt uitgelegd als "line is nog active", dan zijn er nog meer gegevens in behandeling." Een router van Cisco kan worden geconfigureerd om of vlaggen of tekens te verzenden maar niet allebei. Het wisselt niet tussen de twee om de lijnstaat weer te geven. Het standaard is voor router om vlaggen te verzenden.

Dit verschil stelt een probleem in volledig duplex multidrop-omgevingen. Meestal gaat de AS/400 van apparaat tot apparaat, waarbij ze allemaal voor gegevens stemmen. Als een apparaat niet reageert en de AS/400 denkt dat de lijn nog actief is, dan stelt het de gehele lijn opnieuw in. Omdat de router normaal gesproken vlaggen moet verzenden, wordt er altijd een actieve lijn weergegeven in de AS/400-regel en wordt de lijn opnieuw ingesteld in plaats van gewoon het volgende apparaat te bellen.

Om dit probleem te vermijden heeft Cisco historisch een kabelverandering aanbevolen die het dragerdetectie (CD)-signaal schakelt. Deze wijziging maakt gebruik van AS/400-logica die de afwezigheid van de luchtvaartmaatschappij interpreteert als "onbelaste toestand". Met de wijziging detecteert een AS/400 dus altijd de status van de onbelaste lijn, ongeacht de tekens die door de router worden verzonden tussen de frame-elementen. Dus als een secundair apparaat niet reageert, zal AS/400 CD controleren, een idle line zien en naar het volgende station gaan.

Onlangs heeft IBM AS/400-probleem opgelost door PTF# MF10030 te wijzigen. Hierdoor wordt de carrierdetectie op meerdere regels gewijzigd. Als deze tijdelijke oplossing is geïnstalleerd, negeert een AS/400 volledig de status van CD op volle duplex multidrop-lijnen. Als resultaat hiervan is de kabelmodificatie van Cisco niet langer effectief in het voorkomen van periodieke lijnresets.

Werken

Er zijn twee tijdelijke vaste verbindingen beschikbaar, afhankelijk van het routermodel en de versie van Cisco IOS die wordt uitgevoerd. Beide opties vereisen configuratieveranderingen in de router die op de AS/400 is aangesloten.

Optie 1

Verander het teken van het stationaire SDLC van het standaard vlaggenteken naar een teken. Het onduidelijke teken kan worden gewijzigd met behulp van de opdracht voor het configureren van de routerinterface:

idle-character marks

Voeg deze opdracht toe aan de SDLC seriële interface die aan AS/400 is aangesloten. Deze opdracht zal de router ertoe aanzetten om altijd tekens voor een pauze tussen frames te verzenden. Dus, als een secundair apparaat een enquête mist, zal de AS/400 een idle lijn zien en verder gaan om het volgende apparaat te poseren. Helaas betekent dit ook dat de AS/400 onklaar zal zien zelfs als er meer gegevensframes op weg zijn van het apparaat. AS/400 zal slechts het eerste frame erkennen, zelfs als de opiniepeiling/eindbit 0 is. Het zal dan alle opvolgende frames negeren en het volgende apparaat opvragen dat onnodige frame-terugzendingen veroorzaakt. Om terugzendingen te voorkomen, moet u de grootte van het SDLC-venster ook op 1 met de opdracht instellen:

sdlc k 1

Opmerking: De opdracht Onklaar-teken wordt ondersteund in Cisco IOS versie 10.0(5.2) en hoger en werkt op 2500s, 4x00 met NP-4T en 70x0/75x routers.

Optie 2

Detectie van inactieve secundaire apparaten met de interfaceopdracht inschakelen:

stun quick-response

Deze opdracht zal de router ertoe aanzetten te reageren met een "disconnect mode" (DM) frame voor een inactief secundair apparaat dat door de AS/400 wordt opgevraagd. De AS/400 zal dan doorgaan om het volgende apparaat te bellen zonder de lijn opnieuw in te stellen.

Opmerking: deze opdracht wordt ondersteund in Cisco IOS 11.1, 11.0(3.1) en hoger of 10.3(7.2) en hoger.

Tip: Als u problemen ondervindt om de multipoint lijn op te halen met de snelle-reactie ingesteld, gebruik optie 1. De snelle-reactie-code in de router maakt deel uit van de eindige state-machine voor lokaal-ack, die uit stap kan komen met een aantal PU's. We hebben de code in het lab getest en de interoperabiliteit ervan geverifieerd met de 5494, 5394 en Perl494E. Het is mogelijk om in problemen te geraken als de PU die u probeert toe te voegen timers anders heeft ingesteld dan wat de quick_response verwacht.

Gerelateerde informatie

- Ondersteuning van STUN/BSTUN

- IBM-technologiepagina

- Technische ondersteuning en documentatie – Cisco Systems