[Cisco] Tracen/debug van GIANTS

[PtrO]

Weet iemand hoe je op een Cisco 2610 gedropte Giants kan tracen/debuggen ???

We hebben een IBM/3745-FEP gekoppelde DLSW oplossing om middels Cisco routers SDLC lijnen te verbinden via een whatever-IP lan met een remote site.

DLSW is een manier om VTAM/SNA data in -en uit IP te verpakken en wordt errug veel gebruikt om op dure point-to-point leaselijnen te besparen.

Het geval wil dat regelmatig een lijn wordt gekilled omdat de VTAM/SNA omgeving de lijn recovered omdat deze volgens haar lijn-fouten bevat.
Deze fouten treden op om dat de Cisco seriële interface bepaalde data met een (Lengte van exact 1509 bytes) vermoedelijk als te groot ziet en ze als "Giants" dropped. We weten vanuit de VTAM/FEP buffer trace wat er wordt verstuurd richting de lijn-interface. Helaas hebben we geen hardware protocol analyser meer omdat onze leiding vond dat we die met ver-Cisco-ing niet (meer) nodig hebben.

We willen dus wel 's weten wat de inhoud is van die Giants. Het tracen van SDLC packets op de Cisco-encapsulation levert niets op omdat dat packets zijn die dus niet zijn/worden gedropped. Het aardige & rare is dat datastreams kleiner maar ook (veel) groter dan 1509 bytes geen enkel probleem geven. Ook het veranderen van de segmentatie (van ca 8Kbyte naar ca. 1400 bytes) op het mainframe, leverde niets op. Het vermoeden is dat de inhoud van de data dus op een nog onbekende manier misschien een rol speelt.

[ Voor 2% gewijzigd door PtrO op 07-09-2004 00:09 . Reden: typo's ]

[TrailBlazer]

wat je kan doen is een access-list maken die match op pakketten die over de dlsw peer gaan. Ik ga er even vanuit dat dat vaste poorten zijn.
Vervolgens kan je het undocument commando
debug ip packet acl nummer dump gebruiken. Dan krijg je als het goed is het volledige hexadecimale pakket te zien. Let er wel goed op dat je ACl in orde is anders gata je router geheid onderuit

[Verwijderd]

idd... Hou de "no debug all" command dus bij de hand!

[PtrO]

Dank voor de insights.

Het probleem is, dat de pakketten al door de seriële interface worden gedropped als Giants (oversized frames) en dus niet via de DLSW (peer) verbinding worden gestuurd.

Het heeft, denk ik met mijn beperkte Cisco kennis, misschien dus geen zin om een IP/ACL (layer 3) match te zetten omdat die (giants) op physical-layer 1 (danwel/wellicht LLC layer 2) al worden weggesmeten. Of mis ik wat nu wat ??

Kortom laat ik het anders zeggen, kan je met Cisco-router op layer 1 of (delen van ) layer 2, tracen ??? Zeg maar dat ik een soort Etherpeek-achtige kale in/output trace wil hebben wat op/naar de seriële interface gaat met het verschil dat we het hier niet hebben over ethernet maar over SDLC.

Het vervelende is dat ik helaas geen toegang meer heb tot die bepaalde cisco router en dus niet 'zomaar' wat kan proberen. Te meer omdat die router (offshored verwegistan) beheerd door iemand anders die alleen doet/weet wat 'm door ons opgedragen wordt.

[Verwijderd]

En wat gebeurt er als je je mtu gewoon wat groter zet op je interface met het mtu commando ?

[ Voor 70% gewijzigd door Verwijderd op 07-09-2004 13:06 ]

[PtrO]

MTU van der interface (regel 5) staat al groter en wel op 9600 bytes.

Let wel, we hebben het hier over SDLC en dus niet over Ethernet (mtu limit ~1500).

Het vreemde is dat het probleem optreedt (giants) wanneer volgens m'n FEP-output (buffer trace 8 SDLC *I-frames van 201+6*211+80 = 1547 bytes) met daarin 1519 bytes inhoudelijke data, richting de Cisco serial interface worden verstuurd. Wanneer meer of minder, al is het 1546 of 1548, bytes is er niets aan het handje.

_{excuses voor de eerdere rekenfout in de begin post waar ik het heb over 1509 data-bytes, dat is dus bij nader inzien 1519 bytes.}

Kortom, hoe kan ik achterhalen wat de inhoud is van de giants, danwel de ruwe hex-data op de interface en vooral waarom Giants optreden. Protocol analyser is helaas niet in de buurt, laat staan iemand die dat ding kan bedienen.

code:

xxxxxxxx#sh int s0/1
Serial0/1 is up, line protocol is up 
  Hardware is PowerQUICC Serial
  Description: SDLC connection to XXXXXXXXXXX
  MTU 9600 bytes, BW 256 Kbit, DLY 20000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation SDLC, loopback not set
    Router link station role: SECONDARY (DTE)
    Router link station metrics:
      group poll not enabled
      poll-wait 40000 millieseconds
      N1 (max frame size)  76816 bits
      modulo 8
      sdlc vmac: XXXX.XXXX.XX--
  sdlc addr 01 state is CONNECT
      cls_state is CLS_IN_SESSION
      VS 1, VR 1, Remote VR 1, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 2478938/2385887
      TESTs 0/0 XIDs 395/0, DMs 9/0 FRMRs 1/0
      RNRs 0/0 SNRMs 0/0 DISC/RDs 5/0 REJs 0/0 chain: 01/01
  Last input never, output 00:00:00, output hang never
  Last clearing of "show interface" counters 2d00h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 3 packets/sec
  5 minute output rate 0 bits/sec, 3 packets/sec
     819993 packets input, 57232090 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 99 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     642846 packets output, 11419042 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

[Predator]

Puur uit interesse:
Waarom doe je die DLSW via die IBM controllers, en niet direct op de cisco routers ?
(als die al lokaal staan ten opzichte van de eindtoestellen).

Wij hebben vroeger DLSW gebruikt op 261x'n voor SNA verkeer tussen AS/400's.
Het werkte prima, maar de performantie was echt bedroevend als je files over SNA overpompt. De cpu impact was nogal hoog op z'n lichte 261x.
Nu doen we dit rechtstreeks op de AS/400's via ANYNET. Er komt geen SNA packet meer op het netwerk. De AS/400 handelen zelf de encapsulatie e.d. af.
Werkt prima, performantie is bijna even goed als TCP/IP en de impact op een AS/400 is zo goed als nul.

Zijn IBM controllers performanter ?

[Verwijderd]

Ik ben aardig bekend met cisco maar packet / frame content debuggen is volgens mij onmogenlijk.

Verder als debug ip packet detail kom je volgens mij niet.

[JackBol]

Verwijderd schreef op 08 september 2004 @ 14:44:
Ik ben aardig bekend met cisco maar packet / frame content debuggen is volgens mij onmogenlijk.

Verder als debug ip packet detail kom je volgens mij niet.

makkelijker zou inderdaad een tap zijn met packetanalyzer...

[TrailBlazer]

Verwijderd schreef op 08 september 2004 @ 14:44:
Ik ben aardig bekend met cisco maar packet / frame content debuggen is volgens mij onmogenlijk.

Verder als debug ip packet detail kom je volgens mij niet.

zoals ik zeg debug ip packet dump bestaat ook maar is undocumented en staat ook niet in het lijstje met ?

[PtrO]

Predator schreef op 07 september 2004 @ 19:22:
Puur uit interesse:
Waarom doe je die DLSW via die IBM controllers, en niet direct op de cisco routers ?
(als die al lokaal staan ten opzichte van de eindtoestellen).

Wij hebben vroeger DLSW gebruikt op 261x'n voor SNA verkeer tussen AS/400's.
Het werkte prima, maar de performantie was echt bedroevend als je files over SNA overpompt. De cpu impact was nogal hoog op z'n lichte 261x.
Nu doen we dit rechtstreeks op de AS/400's via ANYNET. Er komt geen SNA packet meer op het netwerk. De AS/400 handelen zelf de encapsulatie e.d. af.
Werkt prima, performantie is bijna even goed als TCP/IP en de impact op een AS/400 is zo goed als nul.

Zijn IBM controllers performanter ?

Voor alle duidelijkheid, qua performance, througput in combinatie met betrouwbaarheid en beheersbaarheid, zijn naar mijn bescheiden mening 3745 controller en SNA onverslaanbaar. Maar da's ondertussen halfvergane glorie à la Philips. Zo van, "Bedankt voor het idee maar te duur".

Voor de duidelijkheid, DLSW doen we via Cisco standaard oplossing en niet via FrontEndProcessors.

Tja, je hebt wel gelijk met de vraag waarom we het niet anders doen. Ware het niet dat we/ik gebonden ben aan een bestaande zaak die je niet FF in een eenmansactie kan wijzigen.

Er is overigens wel een reden waarom we dat via die controller moeten doen en dat is omdat we verschillende SNA network (id's) koppelen wat vereist dat je een tussenbox (3745 controller oid) gebruikt ter seperatie.
Met gebruik van APPN (next evolution van SNA) is dat niet nodig maar da's nog niet zover. Verder kan je verschillende native NETID's koppelen (en verbinden) met gebruik van EE (EnterpriseExtender) waarmee je rechstreeks vanuit een (MVS cq. OS/390) mainframe SNA kan transporteren over IP. Dit is zeg encapsulatie etc. van SNA naar IP binnen het mainframe (VTAM/TCPIP en OSA adapters).
Ware het niet dat het systeem dat aangesloten is, een VM/VSE systeem betreft die dat niet support. Overschakelen naar MVS is zoiets als je fiets inruilen voor een tank. Mooier/leuker maar veel duurder en ingewikkelder om je te verplaatsen.

Performance is overigens hier niet een echt zaak van belang. Qau zekerheid, bestaande LULU/APPC applicaties en vooral vanwege security wordt SNA gebruikt waarbij we dus de (sna) data (heavy encrypted enz.) transporteren via het IP/FR netwerk.

P.s. wat ik hier allemaal blaat is Professional Networking met een hoofdletter P en zal je meestal niet snel tegenkomen in de wat kleinere (decentrale) omgevingen.

Mocht iemand interesse hebben om meer te weten, zoek of roep maar.

[Predator]

PtrO schreef op 08 september 2004 @ 17:16:
[...]

Voor alle duidelijkheid, qua performance, througput in combinatie met betrouwbaarheid en beheersbaarheid, zijn naar mijn bescheiden mening 3745 controller en SNA onverslaanbaar. Maar da's ondertussen halfvergane glorie à la Philips. Zo van, "Bedankt voor het idee maar te duur".

Dat is wel wat ik vermoedde. Ik heb wat rondgezocht indertijd en ik kwam vaak op IBM controllers uit. Ik denkt dat het ook die 3745 waren.

Er is overigens wel een reden waarom we dat via die controller moeten doen en dat is omdat we verschillende SNA network (id's) koppelen wat vereist dat je een tussenbox (3745 controller oid) gebruikt ter seperatie.
Met gebruik van APPN (next evolution van SNA) is dat niet nodig maar da's nog niet zover. Verder kan je verschillende native NETID's koppelen (en verbinden) met gebruik van EE (EnterpriseExtender) waarmee je rechstreeks vanuit een (MVS cq. OS/390) mainframe SNA kan transporteren over IP. Dit is zeg encapsulatie etc. van SNA naar IP binnen het mainframe (VTAM/TCPIP en OSA adapters).
Ware het niet dat het systeem dat aangesloten is, een VM/VSE systeem betreft die dat niet support. Overschakelen naar MVS is zoiets als je fiets inruilen voor een tank. Mooier/leuker maar veel duurder en ingewikkelder om je te verplaatsen.

Bij AS/400's is het APPN. ANYNET doet ook hetzelfde als je hier beschrijft, dus zoveel verschil zal er ook niet inzitten. Het principe blijft hetzelfde.

Het wordt wel nog niet veel gebruikt volgens mij hoewel het al lang beschikbaar is.
(sedert V3R1). Wij hadden wat problemen omdat de AS/400's de TCP sessies naar zijn peers voor SNA gewoon open laat staan en later terug gebruikt als hij ze nodig heeft. Maw, soms blijven er TCP connecties tientallen uren inactief zonder enige keepalive en poogt hij ze daarna nog te gebruiken. Nu zijn die dan al lang uit de statetables van de firewall die er tussen staat en zijn ze natuurlijk onbruikbaar.

IBM support gecontacteerd:
-> ANYNET ? Ja, dat ken ik, ik heb dat ooit al eens geconfigureerd. ( )
2 uur later
-> Ik heb het hier tussen 2 AS/400's geconfigureerd en ik heb hetzelfde probleem.

PS: IBM support techniekers zijn geen prutsers, dus dit zegt meer over ANYNET dan over de technieker is kwestie.

Er was geen instelling te vinden om die lange inactieve sessies op te kuisen.
Dus dat hebben we dan maar zelf moeten programmeren.
Dat is imo wel tekenend dat het toch erg weinig gebruikt wordt en er meestal op DLSW teruggevallen wordt.

Er was ook ERG weinig over te vinden, zelfs op de gespecialiseerde AS/400 sites & IBM knowledge bases.

Performance is overigens hier niet een echt zaak van belang. Qau zekerheid, bestaande LULU/APPC applicaties en vooral vanwege security wordt SNA gebruikt waarbij we dus de (sna) data (heavy encrypted enz.) transporteren via het IP/FR netwerk.

Het gebruik van SNA zal bij ons ook niet snel verdwijnen om diezelfde redenen.
Daarbij zit SNA ook diep in de vele applicaties.

Als performantie belangerijk is dan gebruik je beter ook geen SNA. Maar nu wij ANYNET gebruik is het verschil met TCP/IP wel erg klein. Behalve de overhead door encapsulatie scheelt het verder erg weinig.

Maar ik heb me later vertellen dat als je ANYNET wilt gaan doen tussen een IBM mainframe, en een AS/400, dat heel wat complexer is. Of dat klopt weet ik niet.
Wij hebben geen mainframe. Bij DLSW heb je dat probleem niet. Het is gewoon SNA wat er aan de andere kant toekomt.
Alle via ANYNET gekoppelde systemen zijn AS/400's met dezelfde OS versie.
Dat maakt configuratie natuurlijk eenvoudiger.

Jij hebt blijkbaar ook het probleem dat je verschillende systemen hebt, en dan zal DLSW zoiezo wel minder haaruitval veroorzaken.

Dat heeft bij ons altijd prima gewerkt (behalve de performantie).

---

Ik ga je nu maar verder laten concentreren op je probleem, maar ik wou de kans grijpen om je ervaringen even te polsen. Je hoort en leest namelijk maar weinig over SNA, en nog minder over het gebruikt in een TCP/IP netwerk.

succes !

[PtrO]

Predator schreef op 08 september 2004 @ 21:04:
[....leuk verhaal over Anynet etc......]

Interessant wederom te vernemen dat SNA als zodanig nog zeker niet dood is.

IBM, de diehards dan, zijn idd geen prutsers. Kheb jaren voor & met ze gewerkt , we prutste inside wel een hoop af maar wat we uiteindelijk afleverden was meestal echt OK. Intern is het kennis niveau van Himalaya gehalte. Duurt dus even voordat je serieus kan mee tokkelen.
Wat geweldig was dat je intern een enorme pool aan IBM kennis en knowhow hebt en opdoet. Wat minder is (imho) de kennis en de wil om te praten over wat niet uit de eigen keuken komt zoals ooit bijv. TCPIP.

BTW Anynet op een MVS-mainframe dan, is beslist niet moeilijker (juiste VTAM feature hebben, hardware opties configgen, FF TCPIP instellen en een CDRSC/Switchmajornode maken en voìla). Mja, dat geldt voor alles, wanneer je het eenmaal (begrijpt en) weet wat je wel/niet moet doen.
Echter Anynet is meer bedoeld voor APPN omgevingen en kan bij mijn weten geen native SNA netwerken koppelen. Verder is Anynet, zo mij bijstaat, ook weer niet beschikbaar voor/op VM/VSE omgevingen.

Het probleem van Anynet en veel andere technologie ontstaat vaak omdat je als netwerkman zo verschikkelijk veel moet weten van allerlei omliggende *shit* voordat je wat zinnigs kan doen en te meer wanneer je moet gaan debuggen en traces/dumps moet gaan lezen.

V.w.b het alive-houden van TCP-sessies staat me iets bij dat je op het mainframe een TCPIP/KeepAlive timer optie hebt. Hiermee kan je zorgen dat tussenliggende brandmuren/routers bij de les blijven. Wat je ook wel ziet bij APPC sessies dat men een periodiek een SNA/(A)PING achtige applicatie inzet om de boel actief te houden. KeepAlive houden van sessies kan overigens weer nadelen geven à la Cruyff.

SNA heeft overigens itt TCP/IP qua ontwerp meer een permanent en besloten sessie karakter.
SNA is onstaan in de periode dat netwerken via vaste en van te voren bepaalde hardcoded-paden verliepen. Session setup was/is in principe eenmalig (en relatief traag vanwege de vele checks) waarna alleen *nog* maar de kwaliteit & integriteit tijdens data-exchange hoefde te worden gechecked.

TCPIP heeft qua opzet en gebruik (TCP/UDP) gewoon een veel meer dynamisch karakter waarbij feitelijk alleen gedurende een data-exchange, een sessie(pad) wordt gestart. Hier heb je dus ook eik hetzelfde probleem met dit verschil dat hierdoor automatisch de active 'states' worden bijgesteld.

Ga je nu SNA over TCPIP gebruiken, dan weet SNA niet beter dat ooit de sessie goed was opgebouwd en zal deze niet zelf continú checken of ie er nog steeds is.
Het uitvallen van een lijn verbinding (wat TCPIP vanuit SNA gezien is) wordt verondersteld gesignaleerd te worden door de hardware (controllers) die VTAM/SNA hiervan een sense melding geeft.
Nu wil het geval dat TCPIP (= software) niet uit zichzelf een signaal geeft dat de 'verbinding' onderbroken is, ergo SNA kan dan ook niet *weten* dat de verbinding weggevallen is.
SNA merkt pas dat de brug weg is wanneer 'data' moet worden verstuurd en zal dan z'n lijnverbinding herstellen waarbij (helaas) actieve applicatie sessies worden gekilled.

Anynet op zichzelf prima ontworpen maar kon niet weten dat er *gekken* gingen rondlopen die vage brandmuurtjes hebben die 'zomaar' logische IP sessies gaan killen om dat ze toevallig FF (lang) niet worden gebruikt.

Kortom het voordeel of gebrek van een toepassing zit 'm in waarvoor en hoe je het moet/wil gebruiken.

P.s. vwb m'n probleem is er bij Cisco een probleem geopend en wacht nu met spanning af dat zij mij gaan wijsmaken dat de 'fout' toch echt in de IBM omgeving zit.

[PtrO]

Nog even een feedback. Het probleem is/wordt opgelost.

Cisco TAC is/was druk bezig geweest en ze hadden een eerder een soortgelijk probleem waarbij de serial-sdlc interface SNA packetsize van 1543 bytes aanmerkte als GIANT's en ze wegsmeet.

We kregen een test LAB-ios met een fix voor 1543 bytes. Echter het probleem bleef. Het was zefs nog erger Die IOS kon, volgens Cisco, alleen maar packets aan van 1543 bytes (incl. SNA FID4 header).

Nader onderzoek leert dat de data-size bij 'ons' van 1519 bytes nog moet worden aangevuld met 26 bytes voor de SNA header. Totaal is dan 1545 bytes.

Overigens we hadden ook nog intern geprobeerd via aanpassingen van de 3745-NCP de SNA (buffer) op iets van 870 bytes te zetten maar dat werd helemaal niets. Er kwam geen byte meer doorheen op die betreffende aansluiting.

Enfin, probleem is voor ons (MF/SNA) van de baan en onze Cisco guys mogen het lekker verder uitzoeken.

[ Voor 2% gewijzigd door PtrO op 08-10-2004 00:03 . Reden: Correctie 1545 ]