12-23-2009 05:40 AM - edited 03-06-2019 09:03 AM
Hello,
I have some difficulty to used multicast with the C 3560 version 12.2(53) ipbase.
I don't know if it's my fault or a configuration problem.
I would like to send a multicast flow in several vlan.
I have 3 vlan in the switch :
Vlan1 to product data and multicast source.
Vlan2 to other users.
Vlan3 to communicat with a firewall, cypher and the other part of us network.
I use Pim in specific configuration because I'm use a specific cipher mode. But I can see the RP point and the multicast group/member in the router RP.
But the multicast flow don't go out the Vlan1.
The source use IGMP V3 and the TTL of the flow is 64.
NB : For different reason I can't use trunk mode :).
First question: Can I send a multicast flow into several vlan with the ipbase 12.2(53) version?
If yes: Where is the mistake?
192.168.3.2 is the firewall address.
192.168.3.4 is the cipher helper igmp protocol.
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
system mtu routing 1500
authentication mac-move permit
ip subnet-zero
ip routing
!
ip dhcp pool SWITCHA
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
!
!
ip multicast-routing distributed
no ip igmp snooping
!
!
spanning-tree mode pvst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0/1
speed 100
duplex full
!
/////// Same interface conf for 0/1 to 0/20
!
interface FastEthernet0/20
speed 100
duplex full
!
interface FastEthernet0/21
switchport access vlan 2
switchport mode access
speed 100
duplex full
!
interface FastEthernet0/22
switchport access vlan 2
switchport mode access
speed 100
duplex full
!
interface FastEthernet0/23
switchport access vlan 2
switchport mode access
speed 100
duplex full
!
interface FastEthernet0/24
switchport access vlan 3
switchport mode access
speed 100
duplex full
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface Vlan1
ip address 192.168.1.1 255.255.255.0
ip pim passive
ip igmp helper-address 192.168.3.4
ip igmp version 3
no ip mroute-cache
!
interface Vlan2
ip address 192.168.2.1 255.255.255.0
!
interface Vlan3
ip address 192.168.3.1 255.255.255.0
ip pim passive
!
ip default-gateway 192.168.3.2
ip classless
ip route 192.0.0.0 255.0.0.0 192.168.3.2
ip http server
ip http secure-server
ip pim rp-address 192.168.3.1
!
ip sla enable reaction-alerts
!
end
If you have some idea …
Thanks
NicoBe
Solved! Go to Solution.
12-23-2009 07:34 AM
Hello Nicolas,
according to 12.(2)52SE config guide:
>>To use the IP multicast routing features, the switch must be running the IP services image. To use the PIM stub routing feature, the switch can be running the IP base image.
see
so your doubts are not out of context.
Hope to help
Giuseppe
12-23-2009 07:34 AM
Hello Nicolas,
according to 12.(2)52SE config guide:
>>To use the IP multicast routing features, the switch must be running the IP services image. To use the PIM stub routing feature, the switch can be running the IP base image.
see
so your doubts are not out of context.
Hope to help
Giuseppe
12-23-2009 08:26 AM
ok
I have some problem to understand what is exactly the "PIM stub routing" compare to "multicast routing".
I will check the doc
Thank for your answer.
01-15-2010 02:14 AM
Hello,
I found the solution of my problem. In fact it isn't a problem of IPBASE or IPSERVICES but a misunderstanding of the ciphering multicast mode (specific development).
In the black world the RP is ok, but not in the red one. The receiver can be subscribed but in the source part the first switch isn't informing because the IGMP is only transmit in one direction (red to black). I need to force the multicast outgoing to add this command to my outgoing Vlan in the source switch. "ip igmp join-group 239.0.0.11"
Best regards,
Nicolas
01-15-2010 03:25 AM
Hello Nicolas,
be aware that by using the ip igmp join-group command you are making the switch itself a member of the multicast group. Packets of the multicast group will be sent to main cpu and processed.
see
http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_02.html#wp1043596
so the workaround is acceptable if traffic volume on the group is not high
Hope to help
Giuseppe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide