Cisco Router 2821 Fehlersuche
Hi all,
nachdem ich lange keine Zeit hatte wieder mal was von mir ...
In dem Thread IPTV
hatte ich das alte IPTV am laufen. Mittlerweile wurde ich umgestellt auf das "neue" IPTV mit nur einm VLAN .
Soweit habe ich auch alles angepasst das alles soweit wieder am laufen ist.
Allerdings das Phänomen mit 2-3 ca 3-4 Sekunden Hänger pro Stunde TV habe ich immer noch oder wieder.
Ist das ganze an der Fritzbox läuft es ohne Ruckeln. Also Kabel eher unwahrscheinlich.
CPU ist nur bei Peaks kurz an 50 % .
Was ich aber gesehen habe ist :
Int Gi0/0 WAN über Modem 113 Input errors und CRC Fehler :
sowie in das LAN GI0/1 input errors und unknown protocol drops? :
Wäre klasse wenn mir jemand bei dem Problem Tipps geben könnte bzw. Aufklärung was das für Fehler sein könnten.
Danke vorab und Guten Rutsch
nachdem ich lange keine Zeit hatte wieder mal was von mir ...
In dem Thread IPTV
hatte ich das alte IPTV am laufen. Mittlerweile wurde ich umgestellt auf das "neue" IPTV mit nur einm VLAN .
Soweit habe ich auch alles angepasst das alles soweit wieder am laufen ist.
Allerdings das Phänomen mit 2-3 ca 3-4 Sekunden Hänger pro Stunde TV habe ich immer noch oder wieder.
Ist das ganze an der Fritzbox läuft es ohne Ruckeln. Also Kabel eher unwahrscheinlich.
CPU ist nur bei Peaks kurz an 50 % .
Was ich aber gesehen habe ist :
Int Gi0/0 WAN über Modem 113 Input errors und CRC Fehler :
Internet address will be negotiated using DHCP
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is T
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 16:51:31
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 4000 bits/sec, 4 packets/sec
5 minute output rate 5000 bits/sec, 4 packets/sec
30612477 packets input, 3538677862 bytes, 0 no buffer
Received 6069 broadcasts (0 IP multicasts)
4 runts, 0 giants, 0 throttles
113 input errors, 68 CRC, 0 frame, 0 overrun, 41 ignored
0 watchdog, 0 multicast, 0 pause input
869408 packets output, 126230169 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped ou
sowie in das LAN GI0/1 input errors und unknown protocol drops? :
GigabitEthernet0/1 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 001a.6df3.4399 (bia 001a.6df3.4399)
Description: internal network
Internet address is 192.168.5.2/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is T
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 16:53:15
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 2000 bits/sec, 3 packets/sec
5 minute output rate 1000 bits/sec, 2 packets/sec
884185 packets input, 122904904 bytes, 0 no buffer
Received 29153 broadcasts (30098 IP multicasts)
0 runts, 0 giants, 0 throttles
52 input errors, 0 CRC, 0 frame, 0 overrun, 52 ignored
0 watchdog, 0 multicast, 0 pause input
30661670 packets output, 3347101445 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
2552 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 4 pause output
0 output buffer failures, 0 output buffers swapped
Wäre klasse wenn mir jemand bei dem Problem Tipps geben könnte bzw. Aufklärung was das für Fehler sein könnten.
Danke vorab und Guten Rutsch
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 359572
Url: https://administrator.de/contentid/359572
Ausgedruckt am: 24.11.2024 um 00:11 Uhr
28 Kommentare
Neuester Kommentar
Deine IGMP Timer auf dem Cisco und dem angeschlossenen Switch sind unterschiedlich. Das bewirkt die Hänger.
Du solltest die IGMP Timer dort so einstellen wie im Cisco Default.
WO siehst du das Ruckeln ? Media Box oder sowas ?
Teste es mal direkt mit VLC aus. Die Adressen dazu findest du hier:
http://iptv.blog/artikel/multicastadressliste/
Du solltest die IGMP Timer dort so einstellen wie im Cisco Default.
WO siehst du das Ruckeln ? Media Box oder sowas ?
Teste es mal direkt mit VLC aus. Die Adressen dazu findest du hier:
http://iptv.blog/artikel/multicastadressliste/
ist von einem SG switch oder?
Nein, das ist ein billiger China Kracher... ein Trendnet 16 Port Gig Switch.Wie gesagt beim Cisco Router selber musst du gar nichts verändern. Wenn du auch einen Catalyst Switch hast dort ebenfalls nicht, denn bei Cisco IOS Geräten sind die Timer in der IOS Modellreihe natürlich abgestimmt.
Lässt du die FritzBox nur als reinen dummen WLAN Ac cesspoint laufen ?
Kopplung von 2 Routern am DSL Port
Vermutlich ja, oder ?
Dann ist das normal, denn auf der FritzBox rennt ja auch ein kleiner 4 Port LAN Switch, sprich der embeddete Switch am LAN Port der FB.
Dort hat AVM mit an Sicherheit grenzender Wahrscheinlichkeit auch IGMP Snooping am laufen. Das beweist das Show Kommando ja eindeutig. Würdest du so auch im Wireshark sehen !
Hier mal der Auszug aus dem RFC 2236 der IGMPv2 beschreibt und RFC 3376 der IGMPv3 beschreibt:
There is normally only one Querier per physical network. All multicast routers start up as a Querier
on each attached network. If a multicast router hears a Query message from a router with a lower IP
address, it MUST become a Non-Querier on that network.
Also in einem Netz mit multiplen Queriern also z.B. einem Netz mit mehreren Layer 3 IGMP Snooping Switches gewinnt bei der Querier Election immer der mit der niedrigsten IP Adresse, da es in einer L2 Domain immer nur einen einzigen Querier geben kann.
Das ist bei dir nunmal dann die FritzBüx mit der .1. Designtechnisch ist das nicht ganz so gut, denn besser ist wenn der Router oder Switch als zentrales Element im Netz das machen würde und eben kein Endgerät. Es schadet letztlich aber auch nicht.
Kopplung von 2 Routern am DSL Port
Vermutlich ja, oder ?
Dann ist das normal, denn auf der FritzBox rennt ja auch ein kleiner 4 Port LAN Switch, sprich der embeddete Switch am LAN Port der FB.
Dort hat AVM mit an Sicherheit grenzender Wahrscheinlichkeit auch IGMP Snooping am laufen. Das beweist das Show Kommando ja eindeutig. Würdest du so auch im Wireshark sehen !
Hier mal der Auszug aus dem RFC 2236 der IGMPv2 beschreibt und RFC 3376 der IGMPv3 beschreibt:
There is normally only one Querier per physical network. All multicast routers start up as a Querier
on each attached network. If a multicast router hears a Query message from a router with a lower IP
address, it MUST become a Non-Querier on that network.
Also in einem Netz mit multiplen Queriern also z.B. einem Netz mit mehreren Layer 3 IGMP Snooping Switches gewinnt bei der Querier Election immer der mit der niedrigsten IP Adresse, da es in einer L2 Domain immer nur einen einzigen Querier geben kann.
Das ist bei dir nunmal dann die FritzBüx mit der .1. Designtechnisch ist das nicht ganz so gut, denn besser ist wenn der Router oder Switch als zentrales Element im Netz das machen würde und eben kein Endgerät. Es schadet letztlich aber auch nicht.
auf wegen dem Mikrotik einbinden.
Der Dativ ist dem Genitiv sein Tod...! Sollte ich vielleicht ein eigenes VLAN machen nur für die TV Box ?
Dann müsstest du PIM Routing zwischen den VLAN Segmenten machen was einen L3 Switch bedingt. Ich habe das hier eben mal mit einem 35er Catalysten und einem Mikrotik ausprobiert und das hat fehlerfrei geklappt.Ist aber sinnfrei wenn du ihn nicht so oder so in ein anderes VLAN isolieren willst oder musst.
Normal arbeitet die Media Box auch fehlerlos im loaklen LAN mit IGMP Snooping am Switch.
Ich habe das hier mal parallel mit einem RasPi und Kodi (Libreelec und Simple IPTV Addon) und auch der Entertain Box getestet und geht fehlerfrei. Logischerweise auch beides parallel sowie zusätzlich mit einem VLC Client.
Was du testweise mal machen kannst ist das IGMP Snooping am Switch mal zu deaktivieren oder einen billigen unmanaged Switch nehmen.
Dann muss der Switch das Multicasting fluten an alle Ports ohne IGMP was dann nur auf dem Router rennt.
Das sollte immer gehen. Nur mal um zu sehen das das Snooping nicht der Buhmann ist.
Oder den Media Receiver mal direkt an den Router anschliessen ohne Switch HW. Auch das sollte dann klappen. Dann wüsstest du das es irgendwas mit dem IGMP und dann vermutlich den Timern ist.
Wäre zwar ungewöhnlich kommt aber mal vor wenn Switch Hersteller exotiscxhe Default Timer Werte verwenden. In deinem reinen Cisco Umfeld kann man sowas aber eigentlich so gut wie ausschliessen.
Wenn du die Set Top Box mitsnifferst kannst du dann ein IGMP Join Request sehen, also quasi den gleichen Sessionaufbau wie bei VLC ?
So, hat mir keine Ruhe gelassen. Ich habe mal eine Entertain Media Box 400 genommen und die in den jungfräulichen Werksreset gesetzt.
Ins IP TV Netz gehängt in dem (vorher getestet) Kodi (RasPi mit Librelec) und VLC fehlerfrei laufen.
Die Media Box verhält sich tatsächlich so wie du beschreibst.
Sie startet, geht in "Init" Status (Display) und dann "Software Download". Dort bleibt sie hängen, quttiert das nach ca. 3 Minuten mit einem "Download Error" und "Fehler 14" und rebootet neu um die gleiche Prozedur zu starten.
Mmmhhh....
Ein Wireshark Trace zeigt aber das die Box sehr wohl eine DHCP IP Adresse vom Cisco bekommt aber dann scheitert am TFTP Download der Firmware vom Telekom Server:
Verlauf ist klassisch...
Das ist jetzt mal spannend rauszubekommen was das ist.
Aber irgendwie hat der Medi Receiver 400 da ein Problem... Grrrr.
Ins IP TV Netz gehängt in dem (vorher getestet) Kodi (RasPi mit Librelec) und VLC fehlerfrei laufen.
Die Media Box verhält sich tatsächlich so wie du beschreibst.
Sie startet, geht in "Init" Status (Display) und dann "Software Download". Dort bleibt sie hängen, quttiert das nach ca. 3 Minuten mit einem "Download Error" und "Fehler 14" und rebootet neu um die gleiche Prozedur zu starten.
Mmmhhh....
Ein Wireshark Trace zeigt aber das die Box sehr wohl eine DHCP IP Adresse vom Cisco bekommt aber dann scheitert am TFTP Download der Firmware vom Telekom Server:
Verlauf ist klassisch...
- DHCP Adress Vergabe
- Gratious ARP um zu checken das die DHCP IP nicht doppelt ist
- DNS Request auf den Download Server slbupifk11100.prod.sngtv.t-online.de
- DNS Antwort Ziel IP 62.155.251.136
- TFTP GET File auf diese IP mit dem Imagenamen Chipset7241DraImage.img
- Keine Antwort
Das ist jetzt mal spannend rauszubekommen was das ist.
Aber irgendwie hat der Medi Receiver 400 da ein Problem... Grrrr.
OK, das TFTP Problem war die Zone Based Firewall des Routers. Ein match protocol tftp hat das Problem schnell gefixt und nun kommen auch die Antworten des Telekom TFTP Servers an der Media Box an für das Image: (.158 ist die Box)
Helfen tut das aber auch nix, denn jetzt kommen zwar ein Block an aber danach bricht der Transfer wieder mit Fehler 14 ab nur das das Timeout Intervall der 400er Box jetzt kürzer ist weil ja schon was ankommt.
Vermutlich machen die Telekomiker keine UDP MTU Path Discovery auf ihren Servern, denn das Paket kommt fragmentiert an. Bei PPPoE darf maximal 1464 Byte im Frame sein der Server sendet aber mit 1472
Gut generell kein Problem aber irgendwie bleibt der Transfer hängen....
Also weiterforschen.... Mal nen gruseligen Speedport nehmen und mitsniffern....
Helfen tut das aber auch nix, denn jetzt kommen zwar ein Block an aber danach bricht der Transfer wieder mit Fehler 14 ab nur das das Timeout Intervall der 400er Box jetzt kürzer ist weil ja schon was ankommt.
Vermutlich machen die Telekomiker keine UDP MTU Path Discovery auf ihren Servern, denn das Paket kommt fragmentiert an. Bei PPPoE darf maximal 1464 Byte im Frame sein der Server sendet aber mit 1472
Gut generell kein Problem aber irgendwie bleibt der Transfer hängen....
Also weiterforschen.... Mal nen gruseligen Speedport nehmen und mitsniffern....
Man musste nur etwas warten, dann hat sich die MTU Discovery wohl geeinigt und die STB lud die Firmware.
Übrigens meckert auch ein Grusel Speedport Router über diese Fragmentierung und meldet gleich einen Angriff auf sich... (soviel zum Thema Speedport !)
Interessant ist aber das die MB400 Box ausschliesslich nur mit dem Entertain TV IP Adressen 87.141.x.y kommuniziert.
Das sieht man ganz deutlich wenn man sich den Traffic Flow mal mit dem Wireshark ansieht. Ist hier auch nachzulesen:
https://iptv.blog/artikel/die-entertaintv-receiver/
Alle TV Sender sowohl SD als auch HD hatten dort über diese IPs deutlich mehr Ruckler als wenn man die Standard Multicast Streams 239.35.x.y von Entertain nutzt. Letztere laufen vollkommen ruckelfrei sowohl auf VLC oder Kodi.
Die Entertain TV Streams wie sie hier https://iptv.blog/artikel/multicastadressliste/ angegeben sind im Format rtp://87.141.215.251@232.0.20.234:10000 usw. konnte ich weder mit VLC noch Kodi starten obwohl es über die MB400 ging. Geht das bei dir ?
Was noch interessant ist: Die MB400 kann ausschliesslich nur IGMPv3. Das gibt dann natürlich Probleme wenn man in einem IGMP Snooping Netz ist was nur v1 oder v2 kann.
Da sollte man dann besser das Snooping mindestens aber den Switch Querier deaktivieren und nur den v3 Querier des Routers laufen lassen.
Im Handbuch und Tutorials wird auch darauf hingewiesen das man das dann alles abschlaten soll wenn man Probleme hat.
Ist natürlich sinnfrei, denn dann flutet der Switch das Multicasting an alle Ports. Beim Unicasting natürlich nicht.
Übrigens meckert auch ein Grusel Speedport Router über diese Fragmentierung und meldet gleich einen Angriff auf sich... (soviel zum Thema Speedport !)
Interessant ist aber das die MB400 Box ausschliesslich nur mit dem Entertain TV IP Adressen 87.141.x.y kommuniziert.
Das sieht man ganz deutlich wenn man sich den Traffic Flow mal mit dem Wireshark ansieht. Ist hier auch nachzulesen:
https://iptv.blog/artikel/die-entertaintv-receiver/
Alle TV Sender sowohl SD als auch HD hatten dort über diese IPs deutlich mehr Ruckler als wenn man die Standard Multicast Streams 239.35.x.y von Entertain nutzt. Letztere laufen vollkommen ruckelfrei sowohl auf VLC oder Kodi.
Die Entertain TV Streams wie sie hier https://iptv.blog/artikel/multicastadressliste/ angegeben sind im Format rtp://87.141.215.251@232.0.20.234:10000 usw. konnte ich weder mit VLC noch Kodi starten obwohl es über die MB400 ging. Geht das bei dir ?
Was noch interessant ist: Die MB400 kann ausschliesslich nur IGMPv3. Das gibt dann natürlich Probleme wenn man in einem IGMP Snooping Netz ist was nur v1 oder v2 kann.
Da sollte man dann besser das Snooping mindestens aber den Switch Querier deaktivieren und nur den v3 Querier des Routers laufen lassen.
Im Handbuch und Tutorials wird auch darauf hingewiesen das man das dann alles abschlaten soll wenn man Probleme hat.
Ist natürlich sinnfrei, denn dann flutet der Switch das Multicasting an alle Ports. Beim Unicasting natürlich nicht.
Also ich kann mit VLC die 87. starten das geht.
Machst du das genau so wie in dem URL steht also z.B. rtp:87.141.215.251@232.0.20.234:10000// ?Das rennt hier ins Nirwana, bzw. VLC reportet sofort einen Fehler.
Mehr kannst du auch nicht machen wenn du jetzt durchgehend v3 machst dann ist das aus Netzwerk Sicht ja alles sauber.
Mmmmhhh...spannend.
1.) Könnte Autonegotiation Probleme bedeuten
2.) Könnte bedeuten das die anderen VLANs die über den Trunk gehen den Traffic beeinträchtigen.
Oder was meintest du jetzt mit Trunk ? Tagged Uplink oder Link Aggregation ?
Übrigens der rtp://87.141.215.251@232.0.20.234:10000 Link geht hier de facto nicht in VLC.
1.) Könnte Autonegotiation Probleme bedeuten
2.) Könnte bedeuten das die anderen VLANs die über den Trunk gehen den Traffic beeinträchtigen.
Oder was meintest du jetzt mit Trunk ? Tagged Uplink oder Link Aggregation ?
Übrigens der rtp://87.141.215.251@232.0.20.234:10000 Link geht hier de facto nicht in VLC.
Kein Ruckeln
Das ist ja schon mal ne gute Message ! So sollte es ja sein.Priorisiere den Multicast Traffic doch einfach auf dem Switch ! Dann sollte es auch auf dem Trunk keinen Ruckler geben.
Soweit ich gesehen habe im Wireshark ist der Entertain Multicast und auch Unicast Traffic schon DSCP priorisiert. Du musst also nur dem Swiotch sagen das er das bitte in die High Queue packen soll.
Macht so oder so Sinn Audio und Video Traffic so generell zu priorisieren.
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/softwar ...
Stichwort DSCP Priorisierung...
Stichwort DSCP Priorisierung...