cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2701
Views
5
Helpful
4
Replies

Multicast issues on new 4351 Router

rsmith
Level 3
Level 3

New 4351/4331 Routers, configuring simple Multicast as currently running on other model routers.(pim sparse-dense-mode)

Stream to destination works when the Router source Gigabit port is placed directly on the MCast Source network, but fails when placed on the other side of our HP ComWare 5900 Routing switch.

We have other routers (mostly 2811) running Multicast across the 5900 with no issues.

Attached JPG of the layout, with basic MCast configuration lines.

Very limited Multicast knowledge, so want to keep this as simple as possible.

 

 

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

There are certain prerequisities that absolutely must be met by the 4351 router before the multicast can even be accepted by this router and forwarded further. Please check them; I assume that the 4351 is already connected to VLAN Y:

  1. The 4351 must have a route back to the IP network where the sources exist, and this route must point back to the HP routing switch through interface Gi0/0/1
  2. The 4351 must properly recognize the HP routing switch as a PIM neighbor in the show ip pim neighbor output
  3. Your Cisco routers are configured for PIM Sparse-Dense Mode which really means: "If I don't know the address of the Rendezvous Point (RP) router, I'll handle the multicast using Dense Mode rules". The HP, on the other hand, seems to be configured strictly for Sparse Mode. The best approach would be to decide on a RP router for your network (it can safely be the HP box) and configure all Cisco routers with the IP address of this RP router using ip pim rp-address a.a.a.a command; of course, they all must have a route back pointing to this address. The RP router must also be configured with the knowledge that it is the RP itself.

Feel welcome to ask further!

Best regards,
Peter

View solution in original post

4 Replies 4

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

There are certain prerequisities that absolutely must be met by the 4351 router before the multicast can even be accepted by this router and forwarded further. Please check them; I assume that the 4351 is already connected to VLAN Y:

  1. The 4351 must have a route back to the IP network where the sources exist, and this route must point back to the HP routing switch through interface Gi0/0/1
  2. The 4351 must properly recognize the HP routing switch as a PIM neighbor in the show ip pim neighbor output
  3. Your Cisco routers are configured for PIM Sparse-Dense Mode which really means: "If I don't know the address of the Rendezvous Point (RP) router, I'll handle the multicast using Dense Mode rules". The HP, on the other hand, seems to be configured strictly for Sparse Mode. The best approach would be to decide on a RP router for your network (it can safely be the HP box) and configure all Cisco routers with the IP address of this RP router using ip pim rp-address a.a.a.a command; of course, they all must have a route back pointing to this address. The RP router must also be configured with the knowledge that it is the RP itself.

Feel welcome to ask further!

Best regards,
Peter

Thank you for this information.. Slight update and responses to your list:


1: Yes, the Routers do have routes back to the Multicast source (OSPF, and default route)

2: The "sho ip pim nei" (and "dis pim nei" on the 5900) shown below. Note the "uplink" (VLAN y) mode only shows "G"

3: I added some "rp" information on the 5900 and 4351 (using the "Uplink" network VLAN y address on the 5900). It helped, but still not working as expected. I will explain the software process, note the repeated "sho ip igmp groups" has the "226.xxx.xxx.62" appear, but then has an "expires = now", then disappears.


VBrick/StreamPlayer multicast process:
1: StreamPlayer software starts on Client, multicast join request goes out ("Announce") using the 224.x.x.254 multicast IP.
2: VBrick sends response with available "streams" to select, populates the StreamPlayer software with these "programs"(This stage is now working, albeit VERY SLOW  to load)
3: Client selects a "program" (double-click on program name), this opens Windows Media Player with a special "StreamPlayer" codec, which sends a join request to the VBrick (the 226.x.x.62 address).
At this point, the WMP should play the stream, but gets a generic failure error instead.

It should also be noted that in step 1, in our "normal" multicast client end networks, it usually takes between 2-5 seconds to populate the "program" in the software. On this new link, it is taking over 30 seconds minimum to do the same. (38 seconds last test)

 

HP 5900:
(ADDED, under "pim")
static-rp 172.y.y.1
(Neighbor)
dis pim nei
Neighbor Interface Uptime Expires DR-Priority Mode
172.y.y.6 VlanY 00:15:49 00:01:41 1


Cisco4351:
(ADDED)
ip pim rp-address 172.y.y.1

sho ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.a.a.68 GigabitEthernet0/0/0 05:21:39/00:01:27 v2 1 / DR S P G
172.y.y.1 GigabitEthernet0/0/1 00:15:36/00:01:41 v2 1 / G

 


4331-BnyShf#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.xxx.xxx.250 GigabitEthernet0/0/0 08:40:05 00:02:16 172.xxx.xxx.50
224.xxx.xxx.254 GigabitEthernet0/0/0 00:17:42 00:02:19 172.xxx.xxx.50
232.xxx.xxx.233 GigabitEthernet0/0/0 08:40:18 00:02:21 172.xxx.xxx.50
224.xxx.xxx.40 GigabitEthernet0/0/0 08:40:46 00:02:19 172.xxx.xxx.1

4331-BnyShf#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.xxx.xxx.250 GigabitEthernet0/0/0 08:40:14 00:02:08 172.xxx.xxx.50
224.xxx.xxx.254 GigabitEthernet0/0/0 00:17:50 00:02:11 172.xxx.xxx.50
232.xxx.xxx.233 GigabitEthernet0/0/0 08:40:27 00:02:13 172.xxx.xxx.50
226.xxx.xxx.62 GigabitEthernet0/0/0 00:00:01 00:02:59 172.xxx.xxx.50 <-- stream appears
224.xxx.xxx.40 GigabitEthernet0/0/0 08:40:55 00:02:10 172.xxx.xxx.1

4331-BnyShf#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.xxx.xxx.250 GigabitEthernet0/0/0 08:40:19 00:02:02 172.xxx.xxx.50
224.xxx.xxx.254 GigabitEthernet0/0/0 00:17:56 00:02:05 172.xxx.xxx.50
232.xxx.xxx.233 GigabitEthernet0/0/0 08:40:33 00:02:07 172.xxx.xxx.50
226.xxx.xxx.62 GigabitEthernet0/0/0 00:00:06 00:00:00 172.xxx.xxx.50 <--expires timer drops from 3 minutes to zero!
224.xxx.xxx.40 GigabitEthernet0/0/0 08:41:00 00:02:05 172.xxx.xxx.1

4331-BnyShf#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.xxx.xxx.250 GigabitEthernet0/0/0 08:40:20 00:02:02 172.xxx.xxx.50
224.xxx.xxx.254 GigabitEthernet0/0/0 00:17:56 00:02:05 172.xxx.xxx.50
232.xxx.xxx.233 GigabitEthernet0/0/0 08:40:33 00:02:07 172.xxx.xxx.50
226.xxx.xxx.62 GigabitEthernet0/0/0 00:00:07 now 172.xxx.xxx.50  <-- Stream "ends"
224.xxx.xxx.40 GigabitEthernet0/0/0 08:41:00 00:02:04 172.xxx.xxx.1

4331-BnyShf#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.xxx.xxx.250 GigabitEthernet0/0/0 08:40:20 00:02:01 172.xxx.xxx.50
224.xxx.xxx.254 GigabitEthernet0/0/0 00:17:57 00:02:04 172.xxx.xxx.50
232.xxx.xxx.233 GigabitEthernet0/0/0 08:40:34 00:02:06 172.xxx.xxx.50
224.xxx.xxx.40 GigabitEthernet0/0/0 08:41:01 00:02:04 172.xxx.xxx.1

Further update:

Stage 1 still the same (35-40 seconds to populate the "announce")

Stage 3: If selected repeatedly (after acknowledge of WMP error message, keeping the WMP window open), eventually it will "CATCH" the stream and start playing...

It appears the path is there, but possibly a timing issue or a forced "leave" going on? (for both stages)

What other commands, at which locations, may resolve this?

 

rsmith
Level 3
Level 3

Found main issue was with the HP Comware 5900, software revision installed has multicast bugs. Added work-around, fixed some Firewall configuration issues, and all multicast is now working through the Routers.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card