honk81
-
Gesamte Inhalte
28 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von honk81
-
-
OK, manchmal hilft es mir glaube ich, wenn ich einfach drüber rede.
So wie es aussieht, haben unsere Server-Leute alte Einträge von Druckservern nicht gelöscht ... und da wurde immer mal wieder versucht, den Connect aufzubauen.
Da das Netz aber nicht mehr da war, schepperte es in schöner Regelmäßigkeit.
Danke fürs Zuhören ;-)
-
HSRP bei einem Gerät ?
Spricht da was gegen ,-)
OK, die Sache ist etwas verwirrender und macht es für mich nicht einfacher.
Hier existieren 3 6509er, die in unterschiedlichen Gebäuden aufgebaut sind. Zwischen diesen drei Geräten war mal HSRP konfiguriert, was aber nicht soviel bringt, da nur einer der dreien die Anbindung ans WAN hatte. Fiel der aus, hätte es auch nichts gebracht, dass die Clients weiterhin die virt. IP und das GW hätten erreichen können. Es wäre alles tot, auch der Raum, in dem die Server stehen. Daher habe ich die restlichen 6509er auf Switch-Niveau gebracht (sie stehen in anderen Räumen und übernehmen dort nur noch Access-Aufgaben), um mir auch das interne Routing (alle VLANs waren auf allen 6509er konfiguriert, alle waren VTP server) mittels EIGRP zu sparen.
Jetzt unterhält sich halt der letzte 6509er mit sich allein über die Verfügbarkeit der virt. IP 254, er selber lauscht auf 253. Alle Geräte umzukonfigureren (entweder Clients auf neues GW oder 6509 auf 254) ist mir zu viel Aufwand und (aktuell) imho nicht notwendig...
Habe noch ein bischen gegoogelt und einen Link gefunden, in dem geschrieben wurde, dass man nach Paketen mit einer TTL von <2 suchen soll, setze mich gleich mal wieder daran und schaue, welche da aufschlagen. Vllt. kann ich so den Urheber finden.
-
Hallo,
wie die Überschrift schon sagt, kriege ich bei
show ip traffic
einen hohen bad hop count (327713) angezeigt.
Es handelt sich um einen Cisco 6509, der mehrere VLANs beherbergt und quasi meine Core-Komponente im Netzwerk ist. Einen Distribution-Layer habe ich nicht, so dass diese Komponente auch noch mehrere von diesen Aufgaben übernehmen muss (HSRP, etc)
Der 6509er macht zus. noch für das Routing nach draussen OSPF, dass funktioniert nach Aussage des Admins des WAN-Bereichs auch korrekt. Daher frage ich mich, ob die hohen bad hop counts am internen Routing liegen.
Das hier: http://www.mcseboard.de/cisco-forum-allgemein-38/intervlan-routing-gefuehlt-langsam-158236.html beschriebene Problem hat sich anscheinend erstmal gelöst, aber vllt. hängt es doch wieder irgendwie zusammen ?!?
So wie ich die Cisco-Doku zum Thema richtig verstehe (hier),
liegt es am Ablauf der TTL (klar), da der Wert aber kontinurierlich steigt, muss es ja einen Grund geben.
Ich selber bin (noch) nicht so bewandert in der Cisco6509er-Welt, hoffe aber dennoch auf Denkanstösse oder den Hinweis, dass das Verhalten normal ist.
Danke schonmal
-
So,
ich habe das eben nochmal geprüft und aktuell sieht es so aus, dass die IQD-Werte bei 0 bleiben.
Das Problem ist erstmal gelöst / verlagert.
Ob dies die Hauptursache für die Probleme waren, weiß ich noch nicht.
So wie ich das dort verstehe, habe ich ein Problem mit Paketen die für den Router adressiert waren (Cache-misses = 0).
Und damit das ganze nicht durcheinander läuft, mache ich für meine weiteren Fragen mal einen neuen Beitrag auf.
Danke schon mal bis hierhin
-
Danke für den Link,
habe ihn jetzt mal durchgeackert ... und mich am Ende erstmal für
hold-queue 100 in
entschieden, morgen früh mal schauen, ob es was ändert.
-
Hallo,
die Namen werden per Windows-Like per DNS (AD auf Win2003-Basis) aufgelöst. Für andere Systeme ist aber ebenfalls der WINS-Server korrekt konfiguriert, per Default über DHCP, bei zwei exotischen Systemen manuell.
-
Hallo zusammen,
endlich bin ich etwas weiter gekommen, in der Zwischenzeit ist eine Vielzahl von Netzwerkarbeiten gemacht worden, aber so richtig rund läuft es noch nicht.
Mittlerweile "darf" ich das Netzwerk auch komplett und fulltime machen, andere Aufgaben sind dafür weg.
Ich habe nun noch eine Sache, von der ich nicht weiß, wie ich sie einschätzen soll. Und zwar habe ich auf einigen VLAN-Interfaces hohe IQD-Werte, per
sh int vlan 8 summ
ausgelesen.
Da erhalte ich folgendes:
VLAN 5 (gefühlt langsam)
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL ------------------------------------------------------------------------ * Vlan5 0 17270 0 0 1000 1 1000 1 0
VLAN 7 (gefühlt ok, aber auch kaum Traffic drauf)
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL ------------------------------------------------------------------------ * Vlan7 0 0 0 0 0 0 0 0 0
VLAN8 (ebenfalls eher lahm)
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL ------------------------------------------------------------------------ * Vlan8 0 436 0 0 1000 1 0 0 0
Kann mir einer sagen, wodran diese hohen IQD-Werte liegen?
"Packets dropped from incoming queue" muss ja nen Grund haben.
Danke im Vorraus
honk81
-
Hallo,
das InterVLAN-Routing (und das Routing per OSPF in das FirmenLAN) übernimmt der 6509er. Was meinst du mit durchschauen?
Ich habe mir die Interaces schon angeschaut, Fehler auf der Leitung passieren nicht, Late Collisions auch nicht.
Was meinst du mit CAM?
Was mir gerade einfällt, könnte HSRP schuldig sein?
Ist mal in der Vergangenheit eingerichtet worden (sagt die Doku, die hier vor mir liegt, damals war hier noch ein weiterer 6509er verbaut). Es sieht jetzt so aus, dass die virt. IP .254 als def-GW auf allen Clients per DHCP eingetragen wird. Hier wird dann auf die physik. IP .253 umgebogen.
-
Hallo,
ich habe hier ein kleines(?) Problem in einem Netzwerk, was ich mal eben so mit verwalten soll.
Eigentlich sieht alles gut aus, aber eine Sache macht mir Bauchschmerzen.
Ich habe hier einen Cisco 6509, an dem alle weiteren Switche (hauptsächlich Cisco 2590) dranhängen, die in 4 anderen Gebäuden und einzelnen Etagen untergebracht sind. Dieser 6509er hängt wiederum an einem Cisco 3600, der am Ende auf einen Nortel geht (ich weiß, eigentlich erhitzt der nur den Raum zusätzlich, aber das ist der nächste Schritt). Vom Nortel geht es in den Rest des Firmen-LAN. Im Netz sind unterschiedliche VLANs inkl. VTP eingerichtet. STP sowieso.
Das Problem ist nun, dass der Aufruf von Diensten (egal ob HTTP oder SMB) in ein Subnetz (hier VLAN 4) aus einem anderen Subnetz (VLANs 5,6,7,8,9...) gefühlt langsam ablaufen. Ich habe per netio schon Messungen gemacht, die sagen mir allerdings nicht, dass es Probleme gibt.
Auffällig wird es dadurch, dass ein Client (z.B. in VLAN 5) eine Intranetseite aufruft und dies etwa 5 Sekunden dauert. Ein anderer (baugliecher) Client im gleichen Raum (somit gleiche Verkabelung, etc.), aber in VLAN 4 (dort stehen auch der Server) braucht zeitgleich nur 2 Sekunden.
Hat irgendwer eine Idee, wie ich feststellen könnte, wo es Probleme gibt?
Die Server habe ich mit allen mir möglichen Ideen getestet, dadran scheint es nicht zu liegen.
Danke schon mal im Voraus
-
aber ein Ethernet Interface gibts, trunk doch dort raus
gute Idee, ich denke, so werde ich es machen ... wenn es so klappt, wie ich es mir vorstelle
-
Hab ich AUI geschrieben ?
Asche auf mein Haupt, AUX passt wohl besser, dass das X und das I aber auch so nah auf der Tastatur zusammenliegen müssen ;-)
-
Hallo,
danke für die schnelle Antwort ...
Offiziell gibt es keine weiteren E bzw FE Interface für 26xx Router.dann packe ich die Büchse halt wieder dahin, wo ich sie herhabe. Schade eigentlich
Gruß
-
Hallo zusammen,
ich habe auf der Arbeit einen "alten" Cisco 2612-Router mit 1 x TokenRing, 1 x AUI und 1 X Ethernet gefunden.
Für ein kleines Netz könnten wir den ganz gut gebrauchen, allerdings fehlt mir da ein weiteres Iface für Ethernet (egal ob FE oder Ethernet).
Ich habe versucht, bei Cisco passende WIC zu finden, allerdings bin ich von den ganzen Querverweisen mehr verwirrt als alles andere.
Gibt es irgendeine Karte, die mir einen zusätzliches Iface bereitstellt?
Danke im Voraus
-
access-list 116 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 80
access-list 116 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255
kann es sein, dass du die source und destination nicht richtig setzt?
ich hätte das jetzt etwa so vermutet:
access-l 116 permit tcp 192.168.1.0 0.0.0.255 192.168.[b]2[/b].0 0.0.0.255 eq 80
damit sollte der Verkehr aus 192.168.1.0/24 nach 192.168.2.0/24 auf Port 80 erlaubt, und alles andere verboten sein.
Ich hoffe, dass passt so, bin aktuell auch noch dabei, mich intensiver mit ACLs zu befassen.
Gruß
-
Cisco SFPs
naja, auf der Verpackung, die ich rausgekramt habe, steht ziemlich eindeutig Cisco Systems, GLC-SX-MM, die Dinger stecken in dem 2970.
Im 6509 stecken normale GBICs, auch Original, gekleckert wird hier halt nicht ;)
Lustigerweise bestätigt sich hier mal wieder was auch schon mein Berufsschullehrer immer gesagt hat. Im Zweifel ist es immer das KabelOder das was mein Lehrer sagte: Alles unter Layer2 ist doof ;)
-
So, nach mehrtägiger Betrachtung und mehreren Tests scheint sich das Problem wirklich durch den anderen Port und neue Kabel größtenteils erledigt zu haben.
Seltsam ist nur, dass es anfänglich auch über den defekten Port gut ging, verm. ein schleichender Tod.
Danke allen, die Tipps gegeben haben.
-
Auf den 2970 kann ich keine Geschwindigkeit auf den SFPs einstellen, da geht nur nonegotiate.
Auf den 6509er ebenso.
Ich habe das mit den Fehlern auf den Interfaces mal weiteruntersucht und gesehen, dass ein Interface gi4/12 auf dem 6509er Probleme hat, wenn es im Channel ist. Ich habe jetzt ein anderen Port auf den 6509er genommen und in den Channel gepackt, aktuell sieht es nicht so schlimm aus, etwas Paketverlust ist da, aber nicht so extrem wie bei den anderen Einstellungen.
-
Hallo zusammen,
ich habe SPT getestet, aber da sehe ich aktuell keine Probleme. Für die VLANS 4 und 221 ist der 6509er Root, für die internen VLANS, die nur auf dem 2970 existieren, ist logischerweise der 2970 Root.
Was mir aufgefallen ist, wenn der Channel "steht", kriege ich auf dem 6509 relativ schnell Input-Fehler auf dem interface port-channel:
140 input errors, 15 CRC, 0 frame, 0 overrun, 0 ignored
Auf dem 2970 gibt es keine Probleme.
Vllt. hilft diese Info.
-
Hallo,
,Da fällt mir aber noch Spanning-Tree ein (grund warum ein port down ist) ? check das mal ..der Grund für den heruntergefahrenen Port gi 0/28 auf 2970 ist, dass es bei der aktuellen Konfig (etherchannel mode on) nicht wirklich zu gebrauchen ist. Pings auf dahinterliegende Systeme kommen nur zu zwei Dritteln an, bei PAgP war die Quote besser.
Wenn ich das Interface wieder hochfahre, kommt einiges an debug-Meldungen bei STP und etherchannel, aber nichts, wo ich was wirklich mit anfangen kann.
STP werde ich am Dienstag mal testen, habe jetzt erstmal Ostern.
Aber eigentlich sollte bei nem Channel doch keine Neukonfig des Tree entstehen, nur weil ich einen Port (der vorher shutdown war) mit in den Channel nehme, oder?
-
Zeig doch mal alle 4 IF Configs...
6509:
6509#sh run int gi 4/11 Building configuration... Current configuration : 220 bytes ! interface GigabitEthernet4/11 description Uplink LB Switch 8.5.221.220 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 4,221 switchport mode trunk channel-group 3 mode on end 6509#sh run int gi 4/12 Building configuration... Current configuration : 220 bytes ! interface GigabitEthernet4/12 description Uplink LB Switch 8.5.221.220 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 4,221 switchport mode trunk channel-group 3 mode on end
und 2970
2970#sh run int gi 0/27 Building configuration... Current configuration : 217 bytes ! interface GigabitEthernet0/27 description Uplink Core per Etherchannel switchport trunk encapsulation dot1q switchport trunk allowed vlan 4,221 switchport mode trunk no ip address channel-group 2 mode on end 2970#sh run int gi 0/28 Building configuration... Current configuration : 227 bytes ! interface GigabitEthernet0/28 description Uplink Core per Etherchannel switchport trunk encapsulation dot1q switchport trunk allowed vlan 4,221 switchport mode trunk no ip address shutdown channel-group 2 mode on end
-
OK, ist etwas missverständlich.
Auf dem 6509er existieren schon 2 Channel (Po1 und PO2) für die Anbindung von 2 anderen 6509ern Po3 ist der Channel zum 2970, der dort lokal unter Po2 läuft ... ich gebe zu, dass hätte man schöner lösen können, aber so wie ich die Doku verstanden habe, spielt die lokale Bezeichnung keine Rolle, oder sehe ich das falsch?
-
Hallo,
ich habe einen neuen etherchannel erstellt, aber die Probleme bleiben:
6509#sh etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling Number of channel-groups in use: 4 Number of aggregators: 4 Group Port-channel Protocol Ports ------+-------------+-----------+------------------------------------ 1 Po1(SU) PAgP Gi1/1(P) Gi1/2(P) 2 Po2(SU) PAgP Gi2/1(P) Gi2/2(P) 3 Po3(SU) - Gi4/11(P) Gi4/12(P) 6509#Und der 2970:
2970#sh etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 u - unsuitable for bundling U - in use f - failed to allocate aggregator d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel Protocol Ports ------+-------------+-----------+------------------------------ 1 Po1(SD) - 2 Po2(SU) - Gi0/27(P) Gi0/28(P) 2970#Bei genauerer Betrachtung ist es durch diese Konfig sogar noch schlimmer.
-
Und hier noch der Output von den beiden Channeln:
2970:
2970#sh int port-channel 1 Port-channel1 is up, line protocol is up (connected) Hardware is EtherChannel, address is 0012.80a9.b31b (bia 0012.80a9.b31b) Description: PortChannel fur LB MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 1000Mb/s input flow-control is off, output flow-control is off Members in this channel: Gi0/27 Gi0/28 ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 03:28:39, output hang never Last clearing of "show interface" counters 00:13:22 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, 0 packets/sec 5 minute output rate 10913000 bits/sec, 116042 packets/sec 393595 packets input, 103963625 bytes, 0 no buffer Received 2919 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 29650936 multicast, 0 pause input 0 input packets with dribble condition detected 471659 packets output, 180165356 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out6509
6509# sh int port-channel 123 Port-channel123 is up, line protocol is up (connected) Hardware is EtherChannel, address is 0012.4361.422a (bia 0012.4361.422a) Description: Channel Server MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 1000Mb/s input flow-control is off, output flow-control is unsupported Members in this channel: Gi4/11 Gi4/12 ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of "show interface" counters 00:13:43 Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 2156000 bits/sec, 667 packets/sec 5 minute output rate 1145000 bits/sec, 551 packets/sec 469380 packets input, 172487488 bytes, 0 no buffer Received 492 broadcasts (132 multicast) 0 runts, 0 giants, 0 throttles 103 input errors, 8 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 396255 packets output, 106873241 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out -
Stimmt, jetzt wo du es sagst, ich hatte einen Port runtergefahren, als ich ein paar der Konfigs gepostet hatte:
Vom 2970, wenn ein Port hochgefahren wird, gibt es folgende debug-Meldungen:
H5221220#debug etherchannel all PAgP/LACP Shim All debugging is on H5221220# 025651: 3y35w: FEC: returning agport Po1 for port (Gi0/27) 025652: Apr 8 11:18:23: %LINK-3-UPDOWN: Interface GigabitEthernet0/28, changed state to up 025653: 3y35w: FEC: pagp_switch_port_up: Gi0/28 025654: 3y35w: FEC: pagp_switch_invoke_port_up: Gi0/28 025655: 3y35w: FEC: pagp_switch_agc_compatable: comparing GC values of Gi0/28 Gi 0/27 flag = 1 1 025656: 3y35w: FEC: pagp_switch_port_attrib_diff: compare PAgP modes for Gi0/28 025657: 3y35w: FEC: pagp_switch_port_attrib_diff: Gi0/28 Gi0/27 same 025658: 3y35w: FEC: pagp_switch_agc_compatable: GC values are compatable 025659: 3y35w: FEC: pagp_switch_agc_compatable: comparing GC values of Gi0/28 Gi 0/27 flag = 1 1 025660: 3y35w: FEC: pagp_switch_port_attrib_diff: compare PAgP modes for Gi0/28 025661: 3y35w: FEC: pagp_switch_port_attrib_diff: Gi0/28 Gi0/27 same 025662: 3y35w: FEC: pagp_switch_agc_compatable: GC values are compatable 025663: 3y35w: FEC: pagp_switch_calculate_vgc: gc for port Gi0/28 is 10001 025664: 3y35w: FEC: fec_bundle: Gi0/28 025665: 3y35w: FEC: add port (Gi0/28) to agport (Po1) 025666: 3y35w: FEC: pagp_switch_add_port_to_agport_internal: msg to PM to bundle port Gi0/28 with Po1 025667: 3y35w: FEC: pagp_switch_want_to_bundle: Bndl msg to PM for port Gi0/28 t o Agport Po1 025668: 3y35w: FEC: pagp_switch_hotstandby: for agport Po1 025669: 3y35w: FEC: fec_next_port_in_agport: port for Po1 is Gi0/27 025670: 3y35w: FEC: fec_next_port_in_agport: port for Po1 is Gi0/28 025671: 3y35w: FEC: fec_next_port_in_agport: cannot return first port for agpor t Po1 025672: 3y35w: FEC: pagp_switch_hotstandby: returning null for agport Po1 025673: 3y35w: FEC: pagp_switch_reset_load_index: reading load-index for port Po 1 025674: 3y35w: FEC: returning agport Po1 for port (Gi0/28) 025675: Apr 8 11:18:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gigabit Ethernet0/28, changed state to up 025676: 3y35w: FEC: returning agport Po1 for port (Gi0/28) 025677: 3y35w: FEC: returning agport Po1 for port (Gi0/27) 025678: 3y35w: FEC: returning agport Po1 for port (Gi0/28) 025679: 3y35w: FEC: returning agport Po1 for port (Gi0/27) 025680: 3y35w: FEC: returning agport Po1 for port (Gi0/28) 025681: 3y35w: FEC: returning agport Po1 for port (Gi0/27) 025682: 3y35w: FEC: returning agport Po1 for port (Gi0/28) 025683: 3y35w: FEC: returning agport Po1 for port (Gi0/27) 025684: 3y35w: FEC: returning agport Po1 for port (Gi0/28) 025685: 3y35w: FEC: returning agport Po1 for port (Gi0/27) 025686: 3y35w: FEC: returning agport Po1 for port (Gi0/28) undeb all All possible debugging has been turned off
Hoffe das hilft weiter.
6509er bootet nicht sauber, sync´d nicht
in Cisco Forum — Allgemein
Geschrieben
Hallo zusammen,
ich habe hier einen etwas älteren 6509er mit 2 x WS-X6K-Sup1A-2GE
Dummerweise wollen diese beiden Sups nicht miteinander arbeiten. Wie ich auf den Cisco-Seiten herausgefunden habe, liegt das u.a. an unterschiedlichen IOSen auf den Sups. Auf der einen Sup habe ich
auf der anderen
. Ich habe das Prozedere von Cisco weitestgehend durchgespielt, aber trotz allem schaffe ich es nicht, auf beiden Sups das gleiche IOS zu booten.
Die eine SUP läst nicht von der Version 12.1(3a)E4 los.
Bootflash, flash beinhalten dies Image nicht, daher weiss ich aktuell nicht, woher der das immer wieder herzaubert.
bootvar ist auf beiden Sups gleich:
Ich kann die bootldr auch auf c6sup... verändern, interessiert alles nicht.
Mit dem aktuellen Stand ist es halt Glückssache, welche Sup er bootet, und eine händische Pflege der Configs ohne autosync ist mir zu doof...
Vllt. hat jemand noch nen Tipp für mich?