Cisco 2950/4506 Router -- Netwerk Problemen

[Verwijderd]

Hoi Allen,

Ik volg het forum al enige tijd met interesse, en heb nu toch maar eens besloten om een account aan te maken.

Mijn vraag betreft een netwerk probleem met twee switches. De situatie is als volgt:

Ik heb twee switches (verbonden middels glas), namelijk:

1. Cisco 4506
2. Cisco 2950

Het probleem is dat dat response times van het netwerk (bijv tijdens een ping) af en toe erg lang zijn, soms zelf met een timeout, en dat netwerkverbindingen (drive mappings) af en toe worden verbroken.

Ik zou graag willen weten hoe ik dit kan oplossen...

Ik heb alle computers voor virussen gescand, het glaskabeltje naar de 2950 vervangen (deze was namelijk een beetje gebogen), maar niks helpt.

Kan iemand mij vertellen welke debug commands ik het beste op de routers kan gebruiken, die evt. wat meer informatie kunnen verschaffen over de load, en misschien zelfs met een packet sniffer oid. kunnen worden teruggeleid naar een bepaalde backplane (juiste woord?).

Kan de switch evt. kapot zijn?

Alvast bedankt,

Groeten,
Kevin

[Kabouterplop01]

Ping heeft op zo'n korte afstand op zo'n backplane bijna geen zin om er een evt virus mee aan te tonen.
Als ze echt back to back gekoppeld zitten kun je bijv een extended ping doen van switch naar switch met hele grote packets. (zonder fragmentatiebit)
Zou het kunnen zijn dat een van je GBICs kapot is?
Of is het een instelling? Welke gebruik je nu (auto neg, autoduplex, autosensing, of is alles fixed)
Wat zegt de log van je switch? (sh log)
wat zegt de cpuload? (sh proc cpu)
Wat zegt/zeggen de interface/interfaces zelf? (sh int gig0/1 etc...)
CRC errors die flink oplopen?
Full Duplex settings met een berg collissions???

[DarthPlastic]

Het is hier PNS, ik neem dus eigenlijk aan dat je de switches in een professionele bedrijfssituatie maakt, maar toch voor de zekerheid:

Cisco CCNA Basic Troublsehooting:
1) Controleer de kabel

Weet je helemaal zeker dat de kabel wel in orde is? Als je de kabel namelijk eruittrekt zul je hetzelfde ervaren.
Zeker met fiber kan dit soms een helse klus zijn...

Kijk anders eens bij de debug-commando's in je router of je daar wat vindt om de interface te monitoren terwijl er verkeer doorheen gaat.

[ Voor 4% gewijzigd door DarthPlastic op 27-06-2006 20:49 ]

[Verwijderd]

Ter verduidelijking, Ik heb de systemen afzonderlijk gescand m.b.v. een virusscanner.

De switches staan idd in een prof. bedrijfssituatie. Ik heb zelf CCNA, dus ik weet er wel 'iets' van af, maar ja...

Ik zal morgen eens proberen om een extended ping te doen van switch naar switch om te zien wat deze oplevert. Het pingen van de clients naar de andere kant gaat iig niet goed.

Hmm...Een van de gbic's defect. Dit kan ik zelf natuurlijk niet meten. Moet ik hiervoor een bedrijf laten komen, dat gelijk de hele glas verbindingen checked?
Edit: Ik bedenk me opeens dat er nog eentje vrij is, deze kan ik natuurlijk wel configureren en omsteken.

De switch wordt echter steeds trager voordat er timeouts optreden, dus waarschijnlijk staat er toch iets te flooden of misschien packet errors, brakke hardware (thuis switchje) ertussen gezet, etc.

Ik ga morgen de volgende zaken nog maar eens checken:
-Switch Log
-CPU Load
-Interfaces
-CRC errors die flink oplopen
-Full Duplex settings met een berg collissions

Kan ik Ethereal hiervoor gebruiken icm. een port mirror?

Gr,
Kevin

[ Voor 15% gewijzigd door Verwijderd op 27-06-2006 21:05 ]

[DarthPlastic]

Verwijderd schreef op dinsdag 27 juni 2006 @ 21:01:
Ter verduidelijking, Ik heb de systemen afzonderlijk gescand m.b.v. een virusscanner.

De switches staan idd in een prof. bedrijfssituatie.
Ik zal morgen eens proberen om een extended ping te doen van switch naar switch om te zien wat deze oplevert. Het pingen van de clients naar de andere kant gaat iig niet goed.

Hmm...Een van de gbic's defect. Dit kan ik zelf natuurlijk niet meten. Moet ik hiervoor een bedrijf laten komen, dat gelijk de hele glas verbindingen checked?

De switch wordt echter steeds trager voordat er timeouts optreden, dus waarschijnlijk staat er toch iets te flooden of misschien packet errors, brakke hardware (thuis switchje) ertussen gezet, etc.

Ik ga morgen de volgende zaken nog maar eens checken:
-Switch Log
-CPU Load
-Interfaces
-CRC errors die flink oplopen
-Full Duplex settings met een berg collissions

Kan ik Ethereal hiervoor gebruiken icm. een port mirror?

Gr,
Kevin

Waarom doe je dit niet gelijk vanuit een Cisco-bak?
Je kan gewoon het commando ping ingeven waarna het apparaat je allerlei dingen over de snelheid etc zal vragen
Cisco's kunnen overigens heel snel pingen als het moet (als je bv standaard 'Router> ping 10.0.0.1' invult oid) dus voor hogere loads is het ook te testen.

GBics testen is moelijk, maar met seriële routers bestond het commando 'show controllers serial 0', daarmee kon je info over de seriële if bekijken.
Kun je de routers niet uit het rack halen en bij elkaar zetten om ze met een fiberkabeltje van één meter aan elkaar te hangen?
Ideale testsituatie

edit: Probleem is dat ik totáál geen ervaring met glasvezel-spul heb
Genoeg Cisco-ervaring, maar aangezien ik nog nooit met fiber iets in elkaar heb moeten zetten ken ik daar de commando's niet voor , interface fiber 0 ofzo?

[ Voor 8% gewijzigd door DarthPlastic op 27-06-2006 21:08 ]

[Verwijderd]

DarthPlastic schreef op dinsdag 27 juni 2006 @ 21:06:
[...]


Waarom doe je dit niet gelijk vanuit een Cisco-bak?
Je kan gewoon het commando ping ingeven waarna het apparaat je allerlei dingen over de snelheid etc zal vragen
Cisco's kunnen overigens heel snel pingen als het moet (als je bv standaard 'Router> ping 10.0.0.1' invult oid) dus voor hogere loads is het ook te testen.

GBics testen is moelijk, maar met seriële routers bestond het commando 'show controllers serial 0', daarmee kon je info over de seriële if bekijken.
Kun je de routers niet uit het rack halen en bij elkaar zetten om ze met een fiberkabeltje van één meter aan elkaar te hangen?
Ideale testsituatie

edit: Probleem is dat ik totáál geen ervaring met glasvezel-spul heb
Genoeg Cisco-ervaring, maar aangezien ik nog nooit met fiber iets in elkaar heb moeten zetten ken ik daar de commando's niet voor , interface fiber 0 ofzo?

Ik heb in eerste instantie gepinged vanaf een client omdat hierbij de problemen optreden met applicaties die verbinding maken met db servers. Dit was in eerste instantie dus het makkelijkste om te kijken waarom het misgaat.

De routers staan in twee verschillende gebouwen. Naast elkaar zetten gaat dus niet op.

Btw. GigabitEthernet is de interface voor de glas module.

[joopv]

Ik neem aan dat de servers op de 4506 zijn aangesoten met gigE, en dat de 2950 een edge switch is?

snel overzicht status van de poorten op de 2950:
show int | i prot

Over de belasting van de poorten: (default 5 minuten gemiddeldes)
show int | i rate
show int | i load

Overzicht errors op de poorten:
show int | i input error
show int | i output error
Eventueel eerst een clear counters doen om een baseline te krijgen

Logging:
show logging (duh)

CPU belasting:
show proc cpu
show proc cpu history

Verder kun je b.v. mrtg op een pc zetten om grafiekjes te maken van de poorten, mits je snmp toegang hebt tot de cisco's.

Welk IOS draait het ding? Zitten er speciale zaken op de switch? veel vlan's, igmp? Speed/duplex issues (bij twijfel alles vastzetten)?
Als het probleem optreedt, verlies je dan ook pings tussen de op de 2950 aangesoten werkstations onderling of alleen naar de server?
En verliezen werkstations of servers op de 4506 of op andere edge switches dan ook pings naar de betreffende server?

Als het een bandbreedte issue is (24 maal 100Mb is veel meer dan 1Gb) dan zou je tijdelijk de werkstations op 10Mb kunnen zetten als workaround.

[ Voor 43% gewijzigd door joopv op 27-06-2006 22:21 ]

[Kabouterplop01]

om antwoord te geven op je vraag vwb de port mirror is het antwoord nee
fouten worden niet gekopieeerd.
En juist door de interfaces waar het glas opzit te bekijken kun je zien of het glas of GBIC problemen zijn.
bij vezel problemen in 1 vezel of de GBIC : de fouten komen maar op 1 kant aan.
bij het vezelpaar komen de fouten aan in 2 interfaces. en dat gevoel wat je hebt bij flooden kan best kloppen. veel van je verkeer is TCP en als er dus packets verloren gaan krijg je veel retransmits. die ook weer verloren gaan. Zo krijg je een kettingreactie.
Waarschijnlijk of je poort of je vezel of 1 van je GBICs
(goede tip trouwens van JoopV om eerst de lokale machines te pingen (eerst de machines op de 2950 en dan op de 4500, dan weet je zeker dat er iets mis is tussen de routers/l3 switches; als het beide routers zijn kun je het al snel zien: Clear arp op de router en dan een ping naar een host op de lokale switch... zie je geen probleem,vezelpaar /GBIC. Is de andere switch alleen de router, met een aparte sessie op die router een clear arp geven en met je eerste sessie pingen; je doet dan een arp request en door de packetloss zul je time outs ervaren )
Je kunt ook een commando geven in de router welk ip accounting heet.
daarmee kun je zien van waar naar waar het meeste verkeer loopt.

Als het een bandbreedte issue is (24 maal 100Mb is veel meer dan 1Gb) dan zou je tijdelijk de werkstations op 10Mb kunnen zetten als workaround

De gebruikers zullen als dat de issue is alles sneller vinden dan dat ze nu krijgen

[ Voor 27% gewijzigd door Kabouterplop01 op 27-06-2006 23:35 ]