0

We have a campus with 2 different building with few floors on each building and 100's of systems in different VLANS at each floor. At the Access layer we have Layer 2 switches at each floor connecting to an L3 Aggregation switch using VSS design at each building acting as a distribution layer and then connecting to the core layer WAN Routers. Note, that L3 aggregation switches from each building don't have connectivity instead any packet from 1 building to other has to got through core layer and come back.

We have an application that uses UDP multicast packets to communicate across all the systems across all floors. The application server can run on any 1 machine from any floor and the clients will listen on all the systems. Our network team had enabled multicast support in the aggregation switches but not on the Core routers.

The problem we are facing is that the multicast packets goes through different floors in 1 building but not across the building to the other floor in the other building because core switch is not enabled for multicast.

The network team says they will not enable multicast on core and say it's NOT the standard , not sure why, any reason that they might be thinking not to do enable provided the only traffic flow is through core ?

Any other design we can do to achieve our needs this with the existing VSS design or any recommendations ?

I asked to add a trunk between 2 Aggregation switches but they said a L2 link between two VSS AGG/Aggregation domains will not be stable and introduce STP loop because their current design had eliminated STP and don't want to introduce again.

Any help/pointers in this matter is greatly appreciated ?

user1370642
  • 1
  • There could be a variety of reasons for not enabling multicast. But in any event, we're not here to help you bypass your organizations policies. – Ron Trunk Feb 08 '19 at 15:05
  • It's easy to hide behind the "standard" & "organizational policies" without giving the specific reasons as to why it can't work, a typical stubborn network engineer mentality who they haven't caught up to the Application team in terms of applying new and effective ways of doing things, who can only think that connecting cables and creating VLANS with base standards considered as a big achievement. – user1370642 Feb 09 '19 at 18:23
  • It's quite possible you're just dealing with a stubborn network engineer. They're almost as common as stubborn software developers ;p . Without knowing the network, it's just impossible to say why, and speculation is off-topic here. Perhaps the networking team doesn't have the time or skills to support it. Perhaps the hardware or software doesn't support it well. Multicast can add a number of security vulnerabilities, and maybe they're concerned about that. There could be other reasons too. We just don't know. And I'll freely admit, "Because I don't feel like it" is also a possibility. – Ron Trunk Feb 09 '19 at 19:56
  • I don't know how we can help in any of those possibilities. – Ron Trunk Feb 09 '19 at 19:56
  • I did some more research , the concern is about multicast traffic flooding at the core routers level, if so, then this can be easily mitigated using the PIN snooping with PIM-sparse mode (PIM-SM) https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snooppim.pdf to prevent multicast from sending unnecessary multicast traffic to other routers and only see traffic if they previously indicated interest through a PIM join or prune message. An upstream router only sees traffic if it was used as an upstream router during the PIM join or prune process. – user1370642 Feb 14 '19 at 20:07

0 Answers0