Enabling Multicast

[lutheran1971]

Hello,

I have a Cisco 7603 router, on which I've created a VLAN and assigned an IP address to it. I've also assigned a secondary IP since hosts on this VLAN are not all on one single IP network. The VLAN has had three gigabit ethernet ports associated with it. My question is what would I need to do to allow multicast traffic between a server on one of these ports to clients on another port? The server and clients are all on the same network as the secondary IP address assigned to the VLAN. Thank you for any assistance,

Bob Kirk

[Richard Burts]

Bob

If I have understood your description correctly you have a single VLAN and within that VLAN are several end stations. These end stations are not all in the same subnet, so you have configured secondary addresses so that the router interface can communicate with them. Within the VLAN is a server which will originate multicast and the clients who want to receive the multicast are within the same VLAN.

If I have understood correctly then there is nothing that you need to do to enable multicast between the server and the clients. Since they are all in the same VLAN they are in the same broadcast domain. Within the broadcast domain all the clients will hear the multicast directly from the server. There is nothing the router needs to do. You would only need to do things on the router if the server were in one VLAN and the clients were in a different VLAN.

HTH

Rick

[lutheran1971]

Thank you for the reply Rick.

Your summary is accurate. From my understanding I agree with you that there should be nothing required configuration-wise to allow this to work. However, when I initiate a multicast session (Symantec/Norton Ghost is the product we're using), the clients connect but the session never seem to begin when multicast is the selected mechanism. Unicast works fine, but when trying to role out software to multiple end stations, it is not practical.

I have monkeyed with just about every setting I can think of, igmp, mls, pim multicast, multicast-routing etc, to no avail. The IOS is ver 12.1(11r)E1.

Maybe I should be considering and asking whether there are any config settings that would inadvertantly disable the forwarding of multicast traffic between ports in the same VLAN? Thank you for any additional assistance you might be able to offer.

Bob Kirk

[Richard Burts]

Bob

This is a quite interesting question. And I do not have enough experience with 7603 to know the answer. I wonder if there is something you need to configure for IGMP/IGMP snooping to forward multicast within the VLAN.

HTH

Rick

[atman1]

Bob,

What is the server and the clients connected too ? a switch if so what kind ?

Does the switch have Vlan interfaces configured with Ip addresses assicated with them ?

[lutheran1971]

The multicast server and clients are connected to two ports of the third module (8 x Gigabit ethernet) of a 7603 router. There is a VLAN configured with a primary and secondary IP address, and this VLAN is associated with the ports to which the multicast server/clients are connected. The multicast server/clients are on the same ip networks as these VLAN IP's are. The clients and server can communcate with each other (ie ICMP ping) and can communicate with the VLAN address(es) as well. Any thoughts?

Bob Kirk

[Richard Burts]

Bob

Can you check and let us know the state of IGMP and IGMP snooping on the 7603?

HTH

Rick

[lutheran1971]

Certainly. Here is the output returned from 'sh ip igmp int vlan 190', vlan 190 being the one in question;

Vlan190 is up, line protocol is up

Internet address is 192.139.190.1/24

IGMP is enabled on interface

Current IGMP host version is 2

Current IGMP router version is 2

CGMP is enabled on interface

IGMP query interval is 60 seconds

IGMP querier timeout is 120 seconds

IGMP max query response time is 10 seconds

Last member query response interval is 1000 ms

Inbound IGMP access group is not set

IGMP activity: 1561 joins, 1555 leaves

Multicast routing is enabled on interface

Multicast TTL threshold is 0

Multicast designated router (DR) is 192.139.190.1 (this system)

IGMP querying router is 192.139.190.1 (this system)

Multicast groups joined (number of users):

224.0.1.40(1)

IGMP snooping is globally enabled

IGMP snooping is enabled on this interface

IGMP snooping fast-leave is disabled on this interface

IGMP snooping querier is disabled on this interface

IGMP snooping last member query interval on this interface is 1000 ms

What is particularly interesting to me is that there are a significant number of joins and leaves, and yet no multicast session (using Ghost as the app again) actually begin.

Bob Kirk

[Richard Burts]

Bob

This is a very interesting situation. From the info that you posted it sure looks like IGMP is active. My understanding is that if IGMP is active that multicast on the local VLAN should work.

I think there is a clue in what you posted that helps explain the number of joins. I see that the router has joined 224.0.1.40 which is the address for cisco-rp-discovery. So the router is attempting to discover the RP. Is there an RP configured?

HTH

Rick

[lutheran1971]

I apologize for the delay in replying, to be honest I did not know what RP referred to.

After some investigation, there is no explicit rendezvous point(s) configured. What I found from a Cisco webpage is the following;

"All PIM-enabled routers automatically join the Cisco RP discovery group (224.0.1.40) which allows them to receive all group-to-RP mapping information. This information is distributed by an entity called RP mapping agent. Mapping agents themselves join another group—the Cisco RP announce group (224.0.1.39). All candidate RPs advertise themselves in periodic multicast messages aimed at the RP announce group address."

Perhaps modifying/disabling PIM settings is my next direction? Thank you,

Bob Kirk

[Richard Burts]

Bob

If the router had joined the rp-discovery group I would assume that PIM was enabled. It might be helpful if you would post the configuration details (at least of the interface - and more if you think it might help).

HTH

Rick

[lutheran1971]

Here are some of the relevant global settings;

ip multicast multipath

no mls ip multicast aggregate

no mls ip multicast non-rpf cef

mls flow ip destination-source

mls qos statistics-export interval 300

mls qos statistics-export delimiter |

spanning-tree extend system-id

and some settings particular to the VLAN in question;

interface Vlan190

ip address 192.168.1.254 255.255.0.0 secondary

ip address 192.139.190.1 255.255.255.0

ip helper-address 192.139.190.19

no ip redirects

no ip unreachables

no ip proxy-arp

ip pim sparse-dense-mode

ip igmp snooping querier

ip cgmp

Here (to summarize the whole mess) are the IP addresses/masks/gateways of the devices;

Multicast server (has one NIC);

Primary - 192.139.190.51/24 gw 192.139.190.1

Secondary - 192.168.2.253/16 gw 192.168.1.254

Clients;

Client 1 - 192.168.2.241/16 gw 192.168.1.254

Client 2 - 192.168.2.242/16 gw 192.168.1.254

And the layout: The Server resides on module 3 port Gi3/1 and the clients are on module 3 port Gi3/4. Both ports are set as following;

interface GigabitEthernet3/x

description "xxxxx"

no ip address

switchport

switchport access vlan 190

switchport mode access

Thank you,

Bob Kirk

[lutheran1971]

I should also add (and perhaps should have mentioned prior to now, sorry), is that when I configure the clients on the 192.139.190.x/24 network, they can connect and begin the multicast session fine. However I can't keep the clients on that network due to the number of machines we support, and so at the moment I'm convinced that the issue lies in the "routing" of the multicast traffic between 192.168.1.254/16 and 192.139.190.1/24, or in other words the two IP addresses of the VLAN on which both clients and the server sit. For some reason (assuming it is possible) I have not configured something right to route the traffic, though it arguably isn't a "route" since the primary and secondary IP's are for the same interface, VLAN 190. Thanks,

Bob

[Richard Burts]

Bob

I believe that this may be a significant piece of information. Especially in light of this I believe that the multicast is propagating and the clients are receiving it. I wonder if the clients are sending some response to the server and when it does not come from an address in the same subnet that the server is expecting (the primary address on the NIC) that the sessions do not get set up right.

HTH

Rick

[lutheran1971]

I will do some additional traffic capturing with an eye to looking for responses that are not being received/acknowledged. Thank you for your time and assistance.

Bob Kirk