SRW224G4 VLAN and G1/G2 failover issues

Unanswered Question
Dec 2nd, 2009

Our SRW224G4 details

HW ver: 00.03.00

Boot ver: 1.0.2

FW ver: 1.2.2b

Here is a picture of our back 2 back setup. We are trying to send a time sensitive audio traffic and IP traffic over a GbE link,

We assigned audio traffic (port e1) to VLAN 2 and all other ports 2-24 are in default vlan 1.setup

srwissue.jpg

issue 1:

As long as we dont connect IP traffic, audio traffic is good. The moment, we connect IP traffic the audio traffic latency increases beyond acceptable level.

The total bandwidth we use is well below 200 Mbps of 1Gbps.

How do we make sure that VLAN2 (audio traffic on e1) gets high priority so regardless of IP traffic present or not present

on other ports, the latency would remain same for audio traffic?

We tried following with QoS.

1. Assigned CoS 7 (highst priority) to Q4

2. E1 (audio traffic VLAN 2) assigned CoS 7

3. All other ports on CoS 0

Queue priority tried for strict and WRR - no luck

Bandwidth - we tried to assign E1 for ingress 100 Mbps - no luck

We tried to assign E7 - IP traffic for 25 Mbps ingress and egress - no luck

It would be great if some one can show how to do VLAN based QoS settings (if it is supported?). Basically, we would like to

have the audio traffic on VLAN 2 - highest priority and all other ports (VLAN 1) lowest priority.

Issue 2:

We have assigned VLAN 1 and 2 to both G1 and G2. We are trying to accomplish a cable redundancy with G1 and G2.

G1 and G2 are configured as trunk and tagged on VLAN setup.

How do we confgure G1 and G2 ports in such a way that only one is active at any time. If the active port fails, then the other port should take over the traffic?

Thanks in advance for any help.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
alissitz Wed, 12/02/2009 - 20:04

Hello and good evening,

Here is the link to the user guide:

http://www.cisco.com/en/US/docs/switches/lan/csbms/srw2048/administration/guide/SRW-US_v10_UG_A-Web.pdf

IP traffic is bursty, and as such it sounds like it is causing jitter and additional queuing delays as you mention.

For issue #1: If the audio must get through, be the first out, and never wait behind the IP traffic, then you should configure priority queuing.  It sounds as though you have already tried to enable strict priority.  Have you also enabled "Advanced QoS"?

I would be careful that the IP traffic is not being placed into the same queue with the audio traffic.  With the priority queue, your audio should come first, everytime.  I have used this in my lab and have customers doing the same ... I have not heard of a problem yet.  Do please let me know what you find.

Page 40 of the link starts the QoS section.

For issue #2, just enable STP and then Rapid STP (RSTP).  RSTP will see that there are two links, and only enable forwarding on one link.  This ensures that there is a loop free environment.  

Also, RSTP provides for fast failover, so this would be the best choice.  You can use ping and perform some failover tests between the ports in order to see this in action.

Page 44 of the user guide gets into STP.

Also, lastly do please implement these steps when the production network is not in service.  STP and QoS changes will cause brief outages while the network and switches converge / reconfigure.

HTH and have a great night,

Andrew Lee Lissitz

networksound Thu, 12/03/2009 - 10:09

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.

alissitz Thu, 12/03/2009 - 20:53

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

David Hornstein Thu, 12/03/2009 - 21:36

Hi Andrew,

What do you reckon Andrew, seems to have two links between switches.. sure makes sense to run Link aggregation with LACP to bond those two Gig uplinks together.

That would make better use of the links between switches using 2Gbit/sec full duplex between switches rather than using RSTP to block one of the uplinks.

I have to admit to Andrew, I have only SGE2000P and SRW2008P and not a SRW224G4, but will be interesting to check out his config, if he was to post it after setting up link aggregation.

Regards Dave

alissitz Thu, 12/03/2009 - 21:47

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!

networksound Fri, 12/04/2009 - 10:52

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..

David Hornstein Fri, 12/04/2009 - 21:21

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

networksound Mon, 12/07/2009 - 11:39

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...

Alejandro Gallego Tue, 12/08/2009 - 07:44

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.

alissitz Tue, 12/08/2009 - 10:52

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

Actions

This Discussion