4

I have been testing a scenario which involves multicast routing for multicast traffic the scenario is pretty simple.

I have two L3 switches with OSPF running in between them, two computers are connected on both ends of the switches, one acts as the multicast server the other as the multicast client.

Multicast is enabled on both switches as well as multicast routing using PIM DM. I am also using VLC on both ends for the multicast traffic using the multicast group address 225.1.1.1; however, this setup does not seem to work as intended.

network diagram: enter image description here

Client Switch configuration:

sysname CLIENT-SW
#
vlan batch 5 10
#
stp enable
#
multicast routing-enable
#
telnet server enable
telnet ipv6 server enable
#
undo http server enable
undo http secure-server enable
#
undo management-port isolate enable
undo management-plane isolate enable
#
dhcp enable
#
aaa
 authentication-scheme default
 authorization-scheme default
 accounting-scheme default                
 domain default
 domain default_admin
 local-user admin password irreversible-cipher 
 local-user admin service-type http
#
interface Vlanif5
description CLIENT-NETWORK
ip address 192.168.0.254 255.255.255.0
pim dm
igmp enable
dhcp select interface
dhcp server dns-list 172.16.1.1 172.16.1.3
#
interface Vlanif10
description TO-SW-2
ip address 10.1.1.2 255.255.255.252
pim dm
#
interface MEth0/0/1
#
...

interface GigabitEthernet0/0/22
#
interface GigabitEthernet0/0/23
 description TO-MULTICAST-CLIENT
 port link-type access
 port default vlan 5                      
 stp edged-port enable
#
interface GigabitEthernet0/0/24
 description TO-SW-2
 port link-type trunk
 undo port trunk allow-pass vlan 1
 port trunk allow-pass vlan 10
#
interface NULL0
#
ospf 2
 import-route direct type 1
 area 0.0.0.0
 network 10.1.1.0 0.0.0.3 description TO-SW-2
#  
igmp
#
ssh server compatible-ssh1x enable
#
user-interface con 0
user-interface vty 0 4
protocol inbound telnet
user-interface vty 16 20
protocol inbound telnet

Server Switch Configuration:

sysname SERVER-SW
#
vlan batch 5 10
#
stp enable
#
multicast routing-enable
#
telnet server enable
telnet ipv6 server enable
#
undo http server enable
undo http secure-server enable
#
undo management-port isolate enable
undo management-plane isolate enable
#
dhcp enable
#
aaa
 authentication-scheme default
 authorization-scheme default
 accounting-scheme default                
 domain default
 domain default_admin
 local-user admin password irreversible-cipher 
 local-user admin service-type http
#
interface Vlanif5
 description SERVER-NETWORK
 ip address 192.168.1.254 255.255.255.0
 pim dm
 dhcp select interface
 dhcp server dns-list 172.16.1.1 172.16.1.3
#
interface Vlanif10
 description TO-SW-1
 ip address 10.1.1.1 255.255.255.252
 pim dm
#
 interface MEth0/0/1
#
interface GigabitEthernet0/0/23
 description MULTICAST-SERVER
 port link-type access
 port default vlan 5
 stp edged-port enable
#
interface GigabitEthernet0/0/24
 description TO-SW-1
 port link-type trunk                     
 undo port trunk allow-pass vlan 1
 port trunk allow-pass vlan 10
#
interface NULL0
#
ospf 2
 import-route direct type 1
 area 0.0.0.0
  network 10.1.1.0 0.0.0.3 description TO-SW-1
#
igmp
#
pim
#
ssh server compatible-ssh1x enable
#
user-interface con 0
user-interface vty 0 4
 protocol inbound telnet
user-interface vty 16 20
 protocol inbound telnet
#
return

EDIT:

The output related to multicast from Client SW are as follows:

<CLIENT-SW>display  igmp group 
Interface group report information
 Vlanif5(192.168.0.254): 
  Total 1 IGMP Group reported
   Group Address   Last Reporter   Uptime      Expires     
   239.255.255.250 192.168.0.253   00:01:45    00:01:42    

   =======================================================================

<CLIENT-SW>display  pim routing-table 
 VPN-Instance: public net
 Total 1 (*, G) entry; 2 (S, G) entries

 (*, 239.255.255.250)
     Protocol: pim-dm, Flag: WC 
     UpTime: 00:01:59
     Upstream interface: NULL
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif5
             Protocol: igmp, UpTime: 00:01:59, Expires: never

 (192.168.0.253, 239.255.255.250)
    Protocol: pim-dm, Flag: LOC ACT 
     UpTime: 00:02:02
     Upstream interface: Vlanif5
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif10
             Protocol: pim-dm, UpTime: 00:02:02, Expires: never

 (192.168.1.252, 239.255.255.250)
     Protocol: pim-dm, Flag: ACT 
     UpTime: 00:03:17                     
     Upstream interface: Vlanif10
         Upstream neighbor: 10.1.1.1
        RPF prime neighbor: 10.1.1.1
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif5
             Protocol: pim-dm, UpTime: 00:01:59, Expires:  - 

 ===============================================================================

<CLIENT-SW>display  pim neighbor 
 VPN-Instance: public net
 Total Number of Neighbors = 1

 Neighbor        Interface           Uptime   Expires  Dr-Priority  BFD-Session
 10.1.1.1        Vlanif10            05:59:11 00:01:35 1            N     

 ===========================================================================

<CLIENT-SW>display pim interface
 VPN-Instance: public net
 Interface           State NbrCnt HelloInt   DR-Pri     DR-Address
 Vlanif10            up    1      30         1          10.1.1.2        (local)
 Vlanif5             up    0      30         1          192.168.0.254   (local)

The output related to multicast from SERVER SW are as follows:

<SERVER-SW>display  pim routing-table 
 VPN-Instance: public net
 Total 2 (*, G) entries; 3 (S, G) entries

 (*, 239.1.1.1)
     Protocol: pim-dm, Flag: WC 
     UpTime: 00:05:48
     Upstream interface: NULL
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif5
             Protocol: static, UpTime: 00:05:48, Expires: never

 (192.168.1.252, 239.1.1.1)
     Protocol: pim-dm, Flag: LOC ACT 
     UpTime: 00:02:57
     Upstream interface: Vlanif5
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
     Downstream interface(s) information: None

 (*, 239.255.255.250)
     Protocol: pim-dm, Flag: WC 
     UpTime: 00:05:45
     Upstream interface: NULL
         Upstream neighbor: NULL
         RPF prime neighbor: NULL         
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif5
             Protocol: igmp, UpTime: 00:05:45, Expires: never

 (192.168.0.253, 239.255.255.250)
     Protocol: pim-dm, Flag: 
     UpTime: 00:04:21
     Upstream interface: Vlanif10
         Upstream neighbor: 10.1.1.2
         RPF prime neighbor: 10.1.1.2
     Downstream interface(s) information:
     Total number of downstreams: 1
         1: Vlanif5
             Protocol: pim-dm, UpTime: 00:04:21, Expires:  - 

 (192.168.1.252, 239.255.255.250)
     Protocol: pim-dm, Flag: LOC ACT 
     UpTime: 00:05:43
     Upstream interface: Vlanif5
         Upstream neighbor: NULL
         RPF prime neighbor: NULL
    Downstream interface(s) information:
     Total number of downstreams: 1       
         1: Vlanif10
             Protocol: pim-dm, UpTime: 00:04:24, Expires: never

  =========================================================================

<SERVER-SW>         display  pim interface 
 VPN-Instance: public net
 Interface           State NbrCnt HelloInt   DR-Pri     DR-Address
 Vlanif5             up    0      30         1          192.168.1.254   (local)
 Vlanif10            up    1      30         1          10.1.1.2       

 ==========================================================================

<SERVER-SW>display  pim neighbor 
 VPN-Instance: public net
 Total Number of Neighbors = 1

 Neighbor        Interface           Uptime   Expires  Dr-Priority  BFD-Session
 10.1.1.2        Vlanif10            06:00:48 00:01:28 1            N
Improve this question
9
  • You should not be using a multicast group in the reserved range of 225.0.0.0/8. If your application does not have a registered multicast group, you want to use a group from the Organization-Local Scope (239.0.0.0/8). I also do not see where you have enabled IGMP, which is used for host-to-multicast-router communication.
    – Ron Maupin ♦
    Jul 12, 2018 at 13:13
  • @RonMaupin according to huawei documentation the command multicast routing-enable enables all multicast features globally, and if you look at the configuration of the client switch IGMP is enabled on interface vlan 5 which is the network segment for hosts, regarding the multicast group IP I have seen examples over the internet that use 225.1.1.1 for multicast, however when i enable IGMP on vlan 5 of the client switch my switch shows a multicast group with IP address 239.255.255.250, does that meant that i should advertise streams to that group IP?
    – BulBul
    Jul 13, 2018 at 17:55
  • IGMP is different than multicast routing. IGMP is a way for a host to tell the multicast router to start sending traffic for a multicast group to the host network. It is a separate protocol than multicast routing, e.g. PIM. It really has nothing to do with a switch, but a switch may be able to snoop (IGMP snooping) on the request to the router in order to only send traffic for a multicast group to the switch interfaces where a host wants to receive the traffic. If you look at the link in my previous comment, You will see that the 225.0.0.0/8 range is RESERVED, and it should not be used.
    – Ron Maupin ♦
    Jul 13, 2018 at 18:02
  • In fact, the entire 225.0.0.0 to 231.255.255.255 range is RESERVED and should not be used.
    – Ron Maupin ♦
    Jul 13, 2018 at 18:06
  • @Ron thats what huawei documentation and examples says, to enable igmp i should type that command globally then enable igmp inside the interfaces that requires igmp, i checked the link you shared unfortunately i will not be able to test until sunday. But i will try to change the multicast IP and update the post here at sunday
    – BulBul
    Jul 13, 2018 at 18:08

3 Answers 3

Reset to default
3
+100

Multicast is clearly working for group 239.255.255.250:

  • Both Server and Client PCs have joined the group (through IGMP)
  • Both are sending to the group, can see (S,G) entries:
    • (192.168.1.252, 239.255.255.250) - Server sending to group
    • (192.168.0.253, 239.255.255.250) - Client sending to group
  • These (S,G) entries have correct Upstream and Downstream interfaces on both switches to allow end-to-end forwarding

So, 239.255.255.250 apears to be working.

The group in question (239.1.1.1) shows an (S,G) entry on the Server switch:

  • (192.168.1.252, 239.1.1.1)

So, the Server PC is sending to the group.

The Client PC has not joined the group (no IGMP entry). This is a problem and needs investigating as the traffic will not forward end-to-end if Client PC is not requesting the group. Investigate the Client PC application and get it to join the group.

I would usually expect on a Cisco device to see a Pruned Downstream interface for the (192.168.1.252, 239.1.1.1) entry on Server Switch and would also expect to see the same (S,G) entry on the Client Switch with no Downstream interfaces, and the entry marked as Pruned. This may be due to the way Huawei reports pruned groups, or as Benjamin mentions, could be issue with TTL VLC is setting on stream.

Investigate the Client issue first. Mirror the port on the Client Switch and run Wireshark and see if it is sending IGMP joins for 239.1.1.1. If it isn't then this is an application problem.

Edit: OP confirms, the following fixed the issue:

  • Faulty Client PC fixed (not joining group)
  • Increased TTL to 200 on Server PC
  • Enabled IGMP snooping on Client side
Improve this answer
6
  • thanks for the useful information you provided, today i fixed the issue there were three main factors that contributed to the problems with this diagram, the first was a faulty client PC :), second i enabled igmp-snooping on the client side vlan, third increased the VLC ttl to 200, it is obvious that you mentioned the two technically possible causes for the problem, i would kindly like you to edit your answer with the causes that i wrote down here so that people would know the solution for this problem, thank you again for your help
    – BulBul
    Jul 17, 2018 at 20:30
  • @BulBul Good to hear the problem is fixed. Do you mean IGMP Snooping (not Spoofing)?
    – user27899
    Jul 17, 2018 at 20:34
  • sorry for that, i already fixed that :D
    – BulBul
    Jul 17, 2018 at 20:36
  • Could you confirm, was IGMP snooping required to fix the problem or have you just enabled it for efficiency? I'd recommend enabling it, but would be surprised if it was part of the fix? Could you try temporarily removing to see if it still works? Just want to make sure I only add pertinent information to the solution.
    – user27899
    Jul 17, 2018 at 20:38
  • 1
    OK, I will add to the solution, must be something Huawei specific
    – user27899
    Jul 17, 2018 at 20:46
4

It’s been a while since I used VLC, but when you set up the server end, check to make sure that the TTL of your stream isn’t set to 1 (which used to be the default), otherwise the stream will never traverse both hops in your topology.

Improve this answer
3
  • That's an important one! However, it doesn't quite match the observation that the client-side L3-switch (currently) doesn't seem to have any registered subscribers to 239.1.1.1 in the client subnet.
    – Marc 'netztier' Luethi
    Jul 16, 2018 at 9:47
  • actually that was one of the three factors that contributed to this issue, the two others were a faulty client PC and i enabled igmp-snooping on the client side vlan, thanks for your support :)
    – BulBul
    Jul 17, 2018 at 20:32
  • no problem! - glad you got it sorted
    – Benjamin Dale
    Jul 18, 2018 at 1:00
3

225.1.1.1 is reserved by IANA so quite possibly the 5300 filters this cast.

You should try using an address from one of the ad-hoc blocks 224.0.2.0 - 224.0.255.255, 224.3.0.0-224.4.255.255, or 233.252.0.0-233.255.255.255.

Improve this answer
2
  • 1
    I would recommend using a range from RFC 2365 (239.0.0.0 to 239.255.255.255) for usecases like these. This range is as close as you can get to private IP addressing (RFC 1918) with multicast.
    – RobinG
    Jul 16, 2018 at 7:56
  • OP has already moved to group 239.1.1.1 (although not clear in the original post), see comments attached to original post
    – user27899
    Jul 16, 2018 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.