Multicast Probleem

[FabiandJ]

Oke het volgende probleem heb ik en vele mensen meer.

Ik woon op het campus van de UTwente.
Hier heb je de mogelijkheid om via het campusnetwerk IPTV te kijken dit gebeurt doormiddel van multicast.
Nu is er alleen het probleem dat zodra ik of iemand anders naar bijvoorbeeld NED1 kijk. En er iemand anders ook de stream van Ned1 joint. Dat er voor een aantal seconden het signaal weg valt, bij iedereen die ook NED1 kijkt. Mensen die een andere zender zitten te kijken hebben geen last van diegene die de NED1 stream joint, maar wel dus als iemand de stream joint waarop diegene zit te kijken.

Als er iemand stopt met het kijken van een stream hebben we hier geen last van.

Ik en nog iemand dachten dat we alleen last hadden van diegene die op dezelfde switch zaten als wij, maar dit is dus niet zo aangezien we het getest hebben op een switch daarop verder niemand anders IPTV kijkt.

De apparatuur die hier op het campus gebruikt word zijn:
- Cisco Catalyst 6509 router
- HP L2 switches

Na zelf wat zoek werk kwam ik erachter dat dit probleem zeer waarschijnlijk ligt in een instelling van IGMP bij het Join onderdeel.

Dus mijn vraag, heeft er iemand anders hier ervaring met multicasting en een idee heeft hoe dit probleem op te lossen valt.

[MoBi]

Is het niet slimmer om het probleem bij de ut te leggen en niet hier? Hun zouden ook evt aanpassingen kunnen doen in het netwerk mocht dit noodzakelijk zijn.

[FabiandJ]

MoBi schreef op zondag 18 november 2007 @ 10:37:
Is het niet slimmer om het probleem bij de ut te leggen en niet hier? Hun zouden ook evt aanpassingen kunnen doen in het netwerk mocht dit noodzakelijk zijn.

Ja klopt helemaal wat je zegt, maar ik zat meer te hopen dat hier iemand anders hetzelfde probleem heeft gehad en de oplossing zo weet. Aangezien ze op de UT er niet veel tijd voor hebben om dit helemaal te gaan achter halen

[FabiandJ]

Ik heb ondertussen de multicast configuratie van de router, misschien iemand hier iets aanziet.

-=snip=-
ip pim neighbor-filter pim-neighbor-filter
ip pim sparse-mode
ip dvmrp accept-filter dvmrp-interface-block neighbor-list
dvmrp-neighbor-block
ip igmp last-member-query-interval 100
ip igmp last-member-query-count 5
ip igmp query-max-response-time 15
ip igmp query-interval 125
-=snip=-

waarbij:
Standard IP access list pim-neighbor-filter
10 deny any (80295 matches)
Standard IP access list dvmrp-neighbor-block
10 deny any

[Pete]

Wat zeggen de show commands als show ip mroute, minfo en show ip pim _ ?

Het is vooral raar dat geen enkele router neighbour mag zijn. Hangt de streaming server in hetzelfde net?

[FabiandJ]

phsmit schreef op maandag 19 november 2007 @ 16:29:
Wat zeggen de show commands als show ip mroute, minfo en show ip pim _ ?

Het is vooral raar dat geen enkele router neighbour mag zijn. Hangt de streaming server in hetzelfde net?

Op je eerste vraag kan ik even geen antwoord geven moet ik wachten op iemand van het beheer hier op het campus.

De tweede vraag wel, de stream die komt hier binnen via een ander bedrijf die aangeleverd word via glasvezel. Een leverancier is het NOB Cross Media Facilities.
Dit komt binnen op de Cisco Catalyst 6509 router, en vanaf hier word het gemulticast.Die beschikbaar zijn voor iedereen die in de range zit van het campus.

[TrailBlazer]

hangt iedere pc direct aan die 6509 ? of zitten er nog switches tussen.

[FabiandJ]

TrailBlazer schreef op woensdag 21 november 2007 @ 07:52:
hangt iedere pc direct aan die 6509 ? of zitten er nog switches tussen.

Er zitten nog HP L2 switches tussen.

[TrailBlazer]

dan denk ik dat de multicasting op die HP dozen niet lekker is. Als je van kanaal wisselt dan stuur je een leave en een join op een groep. Als je een leave stuurt dan zal de router eerst een querry doen of er nog andere members zijn voordat hij stopt het verkeer te forwarden.

Op je switch moete moeten de cam tabellen worden aangepast door IGMP snooping en dat lijkt niet helemaal lekker te werken.

[FabiandJ]

TrailBlazer schreef op woensdag 21 november 2007 @ 09:20:
dan denk ik dat de multicasting op die HP dozen niet lekker is. Als je van kanaal wisselt dan stuur je een leave en een join op een groep. Als je een leave stuurt dan zal de router eerst een querry doen of er nog andere members zijn voordat hij stopt het verkeer te forwarden.

Op je switch moete moeten de cam tabellen worden aangepast door IGMP snooping en dat lijkt niet helemaal lekker te werken.

Op alle switches staat IGMP snooping aan en die instelling wordt dagelijks automatisch gecontroleerd.

[TrailBlazer]

het kan best wel goed geconfigureerd zijn maar nog steeds buggy zijn
Je zal echt moeten gaan debuggen en dergelijke wil je tot de oplossing komen.

[ Voor 35% gewijzigd door TrailBlazer op 21-11-2007 13:49 ]

[FabiandJ]

TrailBlazer schreef op woensdag 21 november 2007 @ 13:48:
het kan best wel goed geconfigureerd zijn maar nog steeds buggy zijn
Je zal echt moeten gaan debuggen en dergelijke wil je tot de oplossing komen.

Mja maar wat zouden we moeten debuggen
We weten wanneer het probleem optreed, alleen niet waar we moeten zoeken in de config.

[TrailBlazer]

in de config kijken is geen debugging. Ik weet niet hoe die setup precies werkt. Heb je een setup box staan of kan je het ook op je PC doen. Kan je op je PC kijken dan is het een kwestie van sniffen op IGMP join/leave messages.

[Verwijderd]

phsmit schreef op maandag 19 november 2007 @ 16:29:
Wat zeggen de show commands als show ip mroute, minfo en show ip pim _ ?

Het is vooral raar dat geen enkele router neighbour mag zijn. Hangt de streaming server in hetzelfde net?

show ip mroute geeft duizenden regels output. Om het even wat te verkleinen:

code:

UTWENTE-router#sho ip mroute act 8000
Active IP Multicast Sources - sending >= 8000 kbps

Group: 233.81.233.163, Nederland 3
   Source: 80.79.34.85 (?)
     Rate: 835 pps/8986 kbps(1sec), 8986 kbps(last 40 secs), 8956 kbps(life avg)

Group: 233.81.233.161, Nederland 1
   Source: 80.79.34.85 (?)
     Rate: 835 pps/8986 kbps(1sec), 8963 kbps(last 40 secs), 8914 kbps(life avg)

Om dan de stream van Nederland 3 er eens uit te lichten:

code:

UTWENTE-router#show ip mroute 233.81.233.163
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 233.81.233.163), 3d19h/stopped, RP 130.89.0.1, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan103, Forward/Sparse, 00:11:13/00:01:31

(80.79.34.85, 233.81.233.163), 3d18h/00:02:57, flags: MT
  Incoming interface: Vlan122, RPF nbr 130.89.254.110, Mbgp, RPF-MFD
  Outgoing interface list:
    Vlan103, Forward/Sparse, 00:11:13/00:01:31, H

De mrinfo geeft ook genoeg output, regeltje of 60. Daarvan copy/paste ik er maar een paar.

code:

UTWENTE-router#mrinfo
172.31.127.248 [version  12.2] [flags: PMSA]:
  172.31.127.248 -> 0.0.0.0 [1/0/pim/querier/leaf]
  145.145.4.2 -> 145.145.4.1 (vl2-18-1-1037.xsr01.amsterdam1a.surf.net) [1/0/pim/querier]
  130.89.254.105 -> 130.89.254.110 (if-nob-ut.routing.utwente.nl) [1/0/pim]
  145.145.4.6 -> 145.145.4.5 (VL2-18-1-2037.XSR01.Amsterdam2a.surf.net) [1/0/pim/querier]
  130.89.160.1 -> 0.0.0.0 [1/0/pim/querier/leaf]

Zeg maar wat je van PIM wil weten...

In het algemeen: een deel van de streams krijgen we via een MBGP peering met NOB; een aantal andere streams worden in ons netwerk gegenereerd maar in een ander VLAN dan waar de TS in zit.

En voor de duidelijkheid: ik ben een van de netwerkbeheerders op de UT die onvoldoende tijd heeft om dit volledig te troubleshooten.

[TrailBlazer]

je moet niet op zo'n hoog niveau gaan kijken. Sowieso hebben deze commando's geen zin. Immers na een paar seconden is de stream weer operationeel. Je zal echt moeten gaan debuggen op IGMP om te kijken wat er nou precies gebeurt bij het switchen van kanaal. Je moet dan een leave zien. De router zal dan een Group-Specific-Query doen of er nog andere clients zijn die het wel graag willen hebben. De andere clients moeten hier dan op reageren van ja ik wil hem nog. Het lijkt er een beetje op dat de router niet (lang genoeg) wacht op dit bericht en meteen stopt met forwarden van de multicast stream. Enige seconden later krijgt hij dan het host-membership report binnen en wordt het toch weer wel verstuurd.

Mischien zie je wat nuttigs met show ip igmp groups. Je kan dan kijken hoe hoog de uptime is als die inderdaad erg kort is dan lijkt elke keer bij het wisselen van kanaal de stream onderbroken te worden.

[Verwijderd]

TrailBlazer schreef op woensdag 21 november 2007 @ 15:24:
je moet niet op zo'n hoog niveau gaan kijken. Sowieso hebben deze commando's geen zin. Immers na een paar seconden is de stream weer operationeel.

Het leek me ook niet zo zinvol om de mroute info te geven, aangezien multicast routing op zich wel werkt. Maar goed, als iemand denkt iets uit die data te halen, dan post ik het wel even...

Je zal echt moeten gaan debuggen op IGMP om te kijken wat er nou precies gebeurt bij het switchen van kanaal. Je moet dan een leave zien. De router zal dan een Group-Specific-Query doen of er nog andere clients zijn die het wel graag willen hebben. De andere clients moeten hier dan op reageren van ja ik wil hem nog. Het lijkt er een beetje op dat de router niet (lang genoeg) wacht op dit bericht en meteen stopt met forwarden van de multicast stream. Enige seconden later krijgt hij dan het host-membership report binnen en wordt het toch weer wel verstuurd.

Klopt, maar dat is juist waar ik géén tijd voor heb: packetdumpen op de interfaces wat er aan IGMP verkeer langs komt...

Mischien zie je wat nuttigs met show ip igmp groups. Je kan dan kijken hoe hoog de uptime is als die inderdaad erg kort is dan lijkt elke keer bij het wisselen van kanaal de stream onderbroken te worden.

In het betreffende VLAN:

code:

UTWENTE-router#sho ip igmp groups vla 103
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.192.152.143  Vlan103                  00:18:22  00:04:15  130.89.166.27
233.81.233.30    Vlan103                  00:53:45  00:04:16  130.89.165.228
233.81.233.4     Vlan103                  01:06:36  00:04:21  130.89.162.25
233.81.233.12    Vlan103                  01:07:04  00:04:19  130.89.170.167
233.81.233.218   Vlan103                  02:38:07  00:04:16  130.89.170.230
233.81.233.249   Vlan103                  01:55:42  00:04:20  130.89.161.232
234.21.81.1      Vlan103                  00:23:00  00:04:16  130.89.188.40
233.81.233.241   Vlan103                  04:22:41  00:04:25  130.89.169.154
233.81.233.163   Vlan103                  01:08:27  00:04:20  130.89.164.54
239.255.255.255  Vlan103                  07:46:27  00:04:28  130.89.168.101
239.255.255.254  Vlan103                  5d03h     00:04:15  130.89.164.54
239.255.255.253  Vlan103                  00:30:49  00:04:16  130.89.188.131
239.255.255.250  Vlan103                  00:00:02  00:06:13  130.89.187.192
239.195.255.255  Vlan103                  07:46:27  00:04:18  130.89.168.101
224.2.127.254    Vlan103                  07:46:27  00:04:28  130.89.168.101
239.255.67.250   Vlan103                  00:00:40  00:05:34  130.89.190.59
239.192.11.6     Vlan103                  02:20:49  00:04:29  130.89.160.110
224.0.1.22       Vlan103                  1d07h     00:02:17  130.89.161.187
224.0.1.24       Vlan103                  1d18h     00:04:21  130.89.168.61
225.0.0.1        Vlan103                  1w0d      00:04:20  130.89.164.78
224.0.1.60       Vlan103                  07:56:29  00:04:19  130.89.185.134
225.0.0.42       Vlan103                  02:01:06  00:04:28  130.89.189.197

Er zitten dus wel groups tussen met hogere uptime, maar ik heb geen IGMP debug logging of packet traces om te zien wat er allemaal aan joins en leaves is langsgekomen.

De reden dat de TS dit geplaatst heeft, is afaik omdat hij hoopte op een pasklare oplossing. Ik betwijfel of dit op te lossen is zonder diep debuggen; dat is echter iets waar ik momenteel geen tijd voor heb of prioriteit voor zal krijgen.

[TrailBlazer]

Wat zit er verder nog achter ik kan me niet voorstellen dat al die subnets achter dit ene vlan interface zitten.

[Verwijderd]

TrailBlazer schreef op woensdag 21 november 2007 @ 16:08:
Wat zit er verder nog achter ik kan me niet voorstellen dat al die subnets achter dit ene vlan interface zitten.

Dat is ons grootste VLAN, 130.89.160.0/19. Er zit ongeveer 2k hosts in en daarnaast gooit een van onze VPN concentrators zijn clients in dat subnet. Voor de hosts is alles verder geswitched: HP 4000 en 5300 als access switches, 5300 en 5400 switches als distributie switches.

Het is misschien niet helemaal volgens de standaard design-regels, maar er zijn diverse redenen waarom dit VLAN zo groot is. Dat lijkt me overigens ook geen relevant punt om hierbij te betrekken.

[TrailBlazer]

tja geen idee of er een max is aan de hoeveelheid multicast clients op een LAN, maar zoals je zelf al zegt het zijn er wel heel erg veel. Dit lijkt me wel een van de 1e dingen om te gaan proberen.

[FabiandJ]

TrailBlazer schreef op woensdag 21 november 2007 @ 18:25:
tja geen idee of er een max is aan de hoeveelheid multicast clients op een LAN, maar zoals je zelf al zegt het zijn er wel heel erg veel. Dit lijkt me wel een van de 1e dingen om te gaan proberen.

Ik heb net eens even zitten zoeken, en ze zeiden dat er geen max is voor multicasting.
bron

Maar ik ga er eigenlijk ook niet vanuit dat al die 2k gebruikers IPTV gebruiken.
Misschien dat je uit een log kan halen hoeveel personen er max naar een zender kijken?

Tevens hadden jullie 1,5 maand geleden of zo iets veranderd in de settings. Voor die settings viel de stream voor 30 seconden weg ipv die max 5 seconden of zo nu.
Weet je of toen dit probleem er ook was met joinende mensen van dezelfde zender? Of had het toen ergens anders mee te maken?

[ Voor 33% gewijzigd door FabiandJ op 21-11-2007 19:03 ]