Thanks for your reply.

We have tried Advanced mode on QoS and assigned Queue 4 to CoS priority 7 and assigned port e1 to Queue 4.

All other ports are on Q1 and CoS prioirty 0.

What about G1? Is there any setting for this?

We enabled advanced QoS but have not created any policy etc. on advanced QoS Tab.

I understand that IP traffic is bursty but if audio is on Q4 and all others in Q1 with strict priority I suppose pass audio with out any delay.

The max. delay could be an audio pkt behind a 1500 byte IP pkt but at 1G speed -  so 12 microsec to transmit IP pkt.

That is very small delay and we can tolerate much more for audio traffic.

BTW, we had similar problem with out even connecting IP traffic with firmware version 1.2.1b. After we upgraded to 1.2.2b, problem got fixed with audio only across GbE link.

Is there a way you can post your Qos settings of the setup that you say that is working on your lab?

Thanks again for your help.

Unfortunately I do not have this gear anymore and it is not running; I do not have any configs to share.  Any chance you can attach your configs?

Yes, the serialization delay on a 1G link is next to nothing ... However, queuing and buffering due to packets getting in the wrong queue may make for some jitter.  Also, if the specific queue gets overrun, then you will have some packet loss.

I am not sure the CoS configs are the way to go here ... after all, the CoS settings would normally be derived from the dot1x tags aka 802.1p.  I realize that you can set the default CoS value based on the port when there is not a VLAN tag.

For outgoing traffic which is traversing the uplinks, unless you are tagging the outgoing packets, the COS values will not respected on the next device.  Not to make a simple point but ... QoS is a hop by hop consideration, and so we need to ensure that the traffic receives the correct prioritization from each end to end.

After thinking about this some more, I think it might be best to try another.

Do you know if the audio traffic has a DSCP value assigned to it?  If so, then this is good.

The switch can be configured to trust the DSCP values.  You would have to configure this specifically as this is not the default.  If the switch will trust the DSCP values, then you can view the default DSCP to queue mappings.  You can also modify the DSCP to queue maps.

You can perform this within basic mode QoS.

A caveat to using and trusting the DSCP values is that the switch will trust these as they are.  This means that in most situations this is fine, no problems, however … what if a user or non-critical application would have these set at a high value?  This switch would trust these also.  On the same web page that you would configure the switch to trust the DSCP, you can disable trust for any ports which are not sending audio.  

If you want additional granularity, then advanced QoS is the way to go.  You can configure the switch to provide a minimum bandwidth for the audio traffic.  Do you know how much this should be?   You can give a specific amount to the audio and then leave all the other traffic to the default (non-defined) queue.

If you want to try this, then you will need to create a class map which matches the audio traffic.  It might be easiest to match based on the sender IP, however additional parameters can be matched such as source or destination port numbers.

Once you have done so, then you can configure the policy map and define the appropriate service for this queue.  After this, then you would apply this to an interface.  

Do you think you can perform a quick test to prove the needed queuing method?  Many times this is not possible on a production network during service hours.

Also, If you would like to speak with our support team, please find the link below.  Please use this link to find the correct phone number for your country:

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

I hope this helps, kindest regards,

Andrew Lee Lissitz

Good point Dave as always!  LAG would provide redundancy and additional throughput.

I mentioned RSTP since the initial question was related to redundancy only, however in light of the throughput issues ..., LAG is a good option as well.  Good comment Dave!

Thanks for all the reply.

We did some more testing...

1. when we send IP traffic between 2 devices (that can send and receive IP pkts on its own) connected on each end of the SRW, our audio traffic is not affected. So, we assume it is not Qos or queue delay etc. The IP traffic is about 50 Mbps or so and total traffic is about 150 Mbps on GbE link.

2. However, when we connect a drop from our LAN (Internet router), then we see that the audio traffic is affected. Is there some STP or other setup going on that affects the traffic on audio port?? Is it possible that some switch config? messages (pkts) are being sent to the audio traffic port?

Which brings us back to our VLAN. We have the audio traffic on a separate VLAN than IP traffic. We thought VLAN should protect other VLAN pkts mixed on ports?..

So, we think that some thing is not right when we connect a drop from our internal router... Any comments on help with this issue would be appreciated..

We haven't really identified what exactly is going wrong or what is causing a issue with the traffic flows.

We both have assumed up to now that it is  a QOS issue, but lets step back and have a look at the traffic running through the SRW224G4.

Just to get a feel for the packets and what's happening, and maybe speed up to a resolution.  If the information is not sensitive, it would be most interesting to see two wireshark packet captures;

1. a few seconds of audio,

2. a few seconds of audio mixed with data at a point when you are having trouble with audio.

Use the port mirroring function to capture both received and transmitted traffic on the switch uplink.

What would be really nice to see  would be to start the mirror traffic and capture of the forwarding switch uplink ports on both switches, for comparison purposes. :-)  This will tell us what happening to the packets when the packets leave one switch and enter another switch. The questions that come up are could the packets  out of sequence, lost packets, errors.

If you feel that leaving the captures on this site may cause you an issue, I am happy for you to direct those captures to my community email address.

Lastly, what about trying as suggest, link aggregation with LACP enabled on the uplink ports, it provides maybe 2Gbits/sec full duplex with link redundancy.

regards Dave

Thanks for your pointers. Not sure if this is do with bandwidth issue. Since, when we send unicast IP traffic between 2 devices between switches, no problem at all. Audio traffic is affected only when I connect a drop from local router.

As for as failover between 2 GbE ports, can some one tell us the steps so only one GbE port (either G3 or G4) is active one time and if that active port fails then the next port becomes active. We tried to enable STP and port based STP, it became worst..

Thanks again for the answers...

So connected switch to switch, your devices have no problem; connect the router and you begin to have audio problems? A few posts earlier it was suggested to use DSCP rather than CoS, were you able to apply these settings, and were they applied to both devices (switches)?

As for the G1/G2 failover question, there no function on the switch that would work as you describe; however, creating a LAG (Ether-Channel) does exactly that, just in a slightly different manner. If you can, enable RSTP rather than STP and also make all your client ports "PortFast". Make sure you do not PortFast an uplink switch port (that would be bad). Not suggesting Spanning Tree has anything to do with main problem, but it is interesting that when you enabled STP the problem was worse. The "hellos" are sent every two seconds by default, but this a very small packet. If the introduction of this extra traffic has made the problem worse, I would seriously begin to packet capture as Dave suggested. This may be as simple as a bad NIC sending erroneous information or just broadcasting for no reason.

Keep us posted.

Yes, it sounds as though it is related to the router since it only happens when you plug in the router.

Can we assume that the router is linking another active network into this one?  Does this network become transit for other parts of your network when the router connects?  Probably a few places to go with this line of questioning ... what type of router are you plugging in?

If it is a Cisco router then there are some show commands which might help you determine what is occurring when the router is plugged in. Dave also suggested a capture, and this might be something to look at if you are not sure of what traffic is traversing when the router is plugged in and when the problem occurs.

As for multiple links and failover, this is what STP does.  You can plug in two links and only one will be active at any one time.  Failover will occur when the primary link goes down, leaving the secondary link as the only connection.

You mentioned things got worse with this, hummm ...

Were things worse for longer than ~ 50 seconds?  Did things finally get better afterwards? 

If things got better then this sounds like classic STP convergence.

If things got worse and stayed worse, then it sounds a little like STP was off and you introduced a loop. Do please check the configs and verify STP is configured the same on both ends.  I do suggest running RSTP.

When you reconfigure STP or add / remove links between switches you may notice a brief outage, however, the network should recover.

As mentioned, LAG would allow for redundancy and load balancing.  Sounds like you are mainly concerned with only redundancy, and this is what STP does best. 

Do please provide us an update, I am standing by. 

Andrew