06-04-2012 06:37 AM - edited 03-07-2019 07:03 AM
Hi All,
I would like to get some clarrification on the below points.
1) I am planning to do trunking between a Multicast running Cisco Catalyst 3500 series switch to a Dell power connect 6248(no multicast running here). only a vlan to be allowed over the trunk. muticast source vlan is not allowing over trunk. but still will there be any multicast traffic from Cisco Catalyst 3500 series to dell flow automatically ?
2) Can i allow multicast traffic over a trunk between two Cisco Catalyst Switches? basically source vlan will be in one switch and receiver vlan will be on the other switch. can the receivers get source over trunk link?
Thanks in advance for any help and advise
Shibu
Solved! Go to Solution.
06-04-2012 10:25 AM
Hello Shibu,
one possible option is to to have multicast running only on switchA as you noted.
However, running multicast on both switches would provide some redundancy not only increased complexity.
Generally speaking multicast routing should be enabled also if a switch has only connected receivers, your scenario may be simple enough to work with only SwitchA running multicast.
Hope to help
Giuseppe
06-04-2012 06:50 AM
Hello Shibu,
for moving traffic from a vlan to another you need a L3 device performing routing and multicast routing.
A L2 trunk allows only to carry frames with a vlan tag between switches, but it does not provide inter vlan services of any kind.
if the Cisco switch acts also as multicast router multicast receivers on the permitted vlan will trigger the sending of multicast traffic (after multicast routing) over the L2 trunk with the DELL switch regardless of the vlan to which the multicast source belongs to.
But generally speaking all multicast unknown unicast and broadcast traffic can travel over the trunk.
Hope to help
Giuseppe
06-04-2012 09:55 AM
Hello Giuseppe,
Thanks for your reply. Since i did not get you properly here again i am writing for further clarrification.
1) I am planning to do trunking between a Multicast running Cisco Catalyst 3500 series switch to a Dell power connect 6248(no multicast running here). Trunking is planning to extend one vlan from Dell switch to Cisco 3500 switch for storage purpose. ex: vlan 2 ( 10.10.1.0/24). After allowing this vlan in trunk locally we will configure L2 vlan (vlan 2) in cisco switch then configure port in vlan 2 and assign to pcs. Vlan 2 SVI interface still remain in Dell Switch.
There is no mulitcast traffic is required between these two switch .
At any cost no Multicast traffic would be flowing to dell switch over the trunk created from cisco switch. though we have not assigned any vlan over trunk will the multicast automatically flow over to dell? is it required to put any blocking or ?
2. Two Cisco switch( Switch A and Switch B) are trunk together to extend some vlans. All vlans gateway are being configured in Switch A ,configured multicast routing and allowed all vlans (10,20.30.& 40) over trunk.
In Switch B all L2 vlans have been configured, configured multicast routing and assiged ports to servers and pcs respectively.
Vlan 20 ( 10.20.1.0/24) is carrying Multicast source which is connected in Switch A. Now i would like to get receivers from vlan 40 ( 10.20.2.0/24) from Switch B to access the sources in Switch A. will i it get ? is there anything else to be configured inorder to achive this.
Hope i made it more clear to you.
thanks for u r understanding
06-04-2012 10:07 AM
Hello Shibu,
I see there are two different scenarios.
1) If L3 interface is defined only on DELL and DELL is not running multicast I agree that the involved Vlan 2 will not see multicast traffic on it. And the trunk carries only vlan2. You will have only broadcast traffic related to ARP activity on the trunk but no multicast.
2) between cisco switches
if SwitchA is configured for multicast and SwitchB is configured for multicast and both are multicast active on Vlan40, one of them is elected PIM DR on segment vlan40 and will try to join the sources in vlan20. You need PIM running on at least one vlan between switchA and switchB and you should be fine. You can also force PIM DR election to SwitchA in vlan40 if you like.
Hope to help
Giuseppe
06-04-2012 10:19 AM
Thank you so much for the quick reply.
between cisco switches
if SwitchA is configured for multicast and SwitchB is configured for multicast and both are multicast active on Vlan40, one of them is elected PIM DR on segment vlan40 and will try to join the sources in vlan20. You need PIM running on at least one vlan between switchA and switchB and you should be fine. You can also force PIM DR election to SwitchA in vlan40 if you like
Do we require to enable multicast routing in SWITCH B since we have only receivers ( Vlan 40) there in the switch? i guess no need ..vlan 40 should be able to get souces on vlan 20. pl comment
Thanks
06-04-2012 10:25 AM
Hello Shibu,
one possible option is to to have multicast running only on switchA as you noted.
However, running multicast on both switches would provide some redundancy not only increased complexity.
Generally speaking multicast routing should be enabled also if a switch has only connected receivers, your scenario may be simple enough to work with only SwitchA running multicast.
Hope to help
Giuseppe
06-04-2012 10:52 AM
Thank you such for the clarrifications..really appreciated.
Meanwhile while configuring i got a point which i thought i will share with to you get clear idea. please find below the switch config.
Here i have enabled multicast routing with PIm sparse-mode..but no RP. Multicast Source and receivers are same vlan 10. everything is working and i am able to get streams from the source.
PIM sparse mode setup RP should be mandatory to configure to make it working but here i have only ip igmp snooping querier configured in the switch ... why RP is not required?
Please comment... hope i am not streching to another question... if you want me to open a new discussion kindly let me know.. thanks
=======================================================
sh run
Building configuration...
Current configuration : 4041 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$DLpG$htwewMXbCBToA5KBH.4bX1
!
no aaa new-model
system mtu routing 1500
vtp domain OTT
vtp mode transparent
ip subnet-zero
ip routing
!
!
ip multicast-routing distributed
ip igmp snooping querier
!
!
!
!
!
!
spanning-tree mode pvst
spanning-tree portfast bpduguard default
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
vlan 10
name video
!
!
!
!
!
interface GigabitEthernet0/1
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/2
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/3
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/4
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/5
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/6
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/7
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/8
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/9
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/10
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/11
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/12
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/13
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/14
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/15
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/16
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/17
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/18
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/19
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/20
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/21
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/22
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/23
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/24
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/25
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/26
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/27
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface GigabitEthernet0/28
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface Vlan1
no ip address
!
interface Vlan10
description video
ip address 10.11.12.200 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
ip classless
ip http server
!
!
06-04-2012 11:22 AM
Hello Shibu,
ip igmp snooping querier is automatically disabled when PIM is enabled on the interface.
in your case all your multicast routing domain is collapsed on switchA and so the multicast tree is just made of SwitchA SVIs.
I think that you had multiple switches involved (multiple multicast routers I mean) you should have seen that missing the RP configuration could be an issue in pure sparse mode as there would be no way to join the shared tree rooted at RP.
Notice also that there is the concept of PIM Dense mode fallback that should be on by default in sparse-dense mode configuration
see
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