1

Topic: Cobranet & Layer 3 routing/switching

A recent project of mine encountered some problems with Cobranet and the use of Layer 3 switches. Scott mentioned that he has encountered similar problems and was interested in our solution. What follows is a description of the system, the problem and solution in hopes that it may be helpful to anyone who experiences similar difficulties.

The network is comprised of three VLANs, two of which are for Cobranet and the third for control only. The physical layout was composed of typical edge switches at each of the rack rooms all linked back to frame based core switches in the data center. All of the control protocols utilized IP so the core switches were configured to provide Layer 3 switching(routing) amongst the three VLANs. This kept the Cobranet multicast traffic isolated from the control hosts whilst allowing control traffic to devices which utilized the same LAN port for both Cobranet and control. To provide this Layer 3 switching, the core switch was configured with a Layer 3 interface in each VLAN which acted as the default gateway for each associated VLAN. As opposed to a traditional, distinct routing device which would typically have a real physical interface for each network, these interfaces were virtual, within the core switch itself.

As usual, broadcast and unknown multicast/unicast traffic is forwarded to every port on a VLAN. This includes both real physical ports and virtual interfaces as described above. This exposed the Layer 3 interfaces within the core switch to the multicast Cobranet traffic in their respective VLAN regardless of the fact that said traffic has no Layer 3 information and therefore cannot be routed. The internal routing processor still processed each frame if only to drop it. The internal routing processor is a software entity and has far less bandwidth than the Layer 2 switching fabric that is implemented in hardware. We were seeing consistent 99% cpu utilization in the core switches, causing performance degradation on other networks(this was a single integrated, facility wide network) which were running applications that required the services of the routing processor. The Cobranet traffic however, being native Layer 2 and therefore forwarded by hardware, was not affected.

Here is the solution that we came up with. The Layer 3 interfaces in each VLAN were removed. This immediately solved the CPU utilization problem, but at the same time prohibited control communication to devices on the Cobranet VLANs. For each VLAN a 'proxy' VLAN was created in the core switch. These new VLANs do not need to be propagated to the edge switches. The Layer 3 interfaces which were previously assigned to the original VLANs were moved to each respective proxy VLAN. Each VLAN, both normal and proxy, was given a new physical access(non-trunking) port on the core switch. Now each original VLAN was connected to its proxy via these six new ports with patch cables. Finally, each proxy VLAN was configured with a hardware based traffic filter that dropped all Cobranet traffic, based on Ethernet type values of 0x8819. Cobranet traffic, and any other intrasubnet traffic flowed as before within each original VLAN, however any that was forwarded to the proxy VLAN was subject to the filter before it reached the routing processor. Traffic needing to leave the VLAN, which by definition is IP(Ethernet type 0x0800), passed unhibited through the traffic filter to the Layer 3 interface for normal routing.

2

Re: Cobranet & Layer 3 routing/switching

Jason,

When you did this were you still able to use Disco to discover devices on the CobraNet VLans from PC's running on the Layer 3 segments?
I would think not.
WhHat kind of filtering can you use on the proxy segments? Can you drop all 0x8819 EXCEPT 0x8819 that has an 0x01 in the first data byte field?

This would allow the low frequency multicast reservation packets through, which are used for Discovery, but block 99% of the other Cobranet traffic.

Nihilism is best done by professionals

3

Re: Cobranet & Layer 3 routing/switching

No, as you expect Disco, and any other(IP or otherwise) communications with the Cobranet interface itself will not work across a router. As I understand it, the CM-1 has a limited IP stack that does not implement routing tables, segmentation, etc. Such limitations do not necessarily apply to traffic passed via the packet bridge up to the host device.

The filter in the proxy VLAN blocks all 0x8819 frames. The only purpose of the proxy VLAN is to isolate the Layer 3 routing interface from the Cobranet traffic. Since Cobranet traffic would never be of use to such an interface, there is no need to make exceptions. The only traffic needing to traverse the proxy is IP unicast traffic outbound from the regular(non-proxy) VLAN to the routing interface, inbound IP unicast traffic from a foreign VLAN coming from the routing interface and ARPs. None of which are inhibited by the filter.

4

Re: Cobranet & Layer 3 routing/switching

I have a similar problem regarding to Layer 3 routing switch. In our system, four VLAN are created. Three of them are used to transfering Cobranet data, the rest is for control network. Each edge switch is linked to core switch by trunk port, various Cobranet VLAN data are routed within core switch by gateways. Sometimes, scheduled messages in Q-Host, broadcast to various paging zones within different VLANs,  are truncated. I doubt the problem is caused by the switch CPU utilization. It takes a long time to send Cobranet data to each port, so the first part of message is lost.

Despite of removing layer 3 interfaces in each VLAN and prohibiting control communication to devices on the Cobranet VLANS, what else can I set in switch? Please correct me if sth is wrong.

5

Re: Cobranet & Layer 3 routing/switching

You'll have to describe your setup and network layout a little more. How are your bundles set up to receive the message? You may want to look at what the reservation frames are doing at the beginning of the message.

BTW Cobranet data is not routed. Routers work at Layer 3(IP).

6

Re: Cobranet & Layer 3 routing/switching

Let me describe what the problem is. Our system has one control network , three conbranet VLANs (A, B & C). The core switch is H3C S5600 series switch. Each VLAN has three NIONs to handle audio processes and a number of QSC922 audio processors. Various QSC922 audio processors connect different power ampifiers to control a number of paging zones. Q-Host is located in VLAN A. It seems that the message file should be sent to VLAN B & C for processing.

When some routined messages are scheduled to be broadcast in a number of paging zones, we realize that the messages are truncated sometimes, for instance, no chime or lost words of the message. This is a rare case, it happens on some paging zones which are not configured in same VLAN of Q-Host. Now, we are seeking how to get rid of the problem.

7

Re: Cobranet & Layer 3 routing/switching

Do you have four VLANs?Have you been open the third level of switch?If that true, Your Q-host LAN port must connect to control network, Q-host cobranet port (It's not for audio, it's to catch the control message of stations from cobranet packet and  configure the S560 bundles) connect to cobranet Vlans.

Do you have do this testing that send message use S560 play?I think maybe problem is in S560 configure.
First,your send number of message to different zone at the same time.
Second,your must confirm every S560 channel whether can play the message and heared  the message from loadspeakers.