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,
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.
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.
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.
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 ?
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?
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 184.108.40.206/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 220.127.116.11 (this system)
IGMP querying router is 18.104.22.168 (this system)
Multicast groups joined (number of users):
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.
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 22.214.171.124 which is the address for cisco-rp-discovery. So the router is attempting to discover the RP. Is there an RP configured?
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 (126.96.36.199) 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 groupthe Cisco RP announce group (188.8.131.52). 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,
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).
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;
ip address 192.168.1.254 255.255.0.0 secondary
ip address 184.108.40.206 255.255.255.0
ip helper-address 220.127.116.11
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-dense-mode
ip igmp snooping querier
Here (to summarize the whole mess) are the IP addresses/masks/gateways of the devices;
Multicast server (has one NIC);
Primary - 18.104.22.168/24 gw 22.214.171.124
Secondary - 192.168.2.253/16 gw 192.168.1.254
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;
no ip address
switchport access vlan 190
switchport mode access
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 126.96.36.199/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,
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.
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.
It would be very interesting to compare a traffic capture from a client in the same subnet which works with a capture from a client in a different subnet which does not work.
Please let us know what, if anything, you find.