QOS for SAN on 6500 based MAN network

Unanswered Question
Nov 25th, 2009
User Badges:

Hello

We are buiding a MAN between our major sites GE links and 6509/sup720-10GE with WS-X6724 SFP cards.


SAN traffic will be a major user, and has some unique qos requirements.  (SAN devices are IBM SVC replictors using FC/IP)

     - It is drop sensitive ... ie it reacts very badly to dropped packets

     - It is not jitter sensitive

     - It will use all the bandwidth we can give it... and can easily starve other applications


So we have to both protect the SAN traffic, and also protect others from it.


I'm looking at ways to implement the queuing on the 6724 cards and am considering dedicating one of the 6724 tx-queues just for SAN.

ie  .. something like ...

  1. Priority queue 25%
  2. High Priority Applications 15 %
  3. SAN 30%
  4. Regular Traffic 30 % 


Doing this means we can't have a dedicated scavenger queue,  and would need to use low thresholds within the 'regular traffic' queue for that.


How have others done this?  What did you do for wrr queue thresholds, sizing and servicing ratios?


Thanks in advance

Wes

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Edison Ortiz Wed, 11/25/2009 - 20:10
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

You are very limited in terms of QoS with regular line card. The only protection on data flow will be provided on the Priority Queue.

All other queues will round-robin the data flow in a weighted format. It sounds like this type of data qualifies as priority flow per the business requirement.

If you aren't running voice over these links, mark this type of flow at ingress with DSCP EF(46).


Regards,


Edison

Wes Smith Wed, 11/25/2009 - 20:33
User Badges:

Hi again Edison


Yes, The SAN traffic is "Voice-like" in terms of drops.. but isn't bothered much by Jitter, so I wouldn't put it in the priority queue.

Besides, there's a lot of voice and video conf that is jitter sensitive that also needs to be protocted.


My thoughts are to to give the SAN it's own queue, and allocate 25% of the bw to it, and no 'drop' thereshold.

I'm also considering using the GigE uplink on the Sup720-VSS-10GE itself... These ports have 9MB tx-queue space vs the 1MB on the 6724.

The large queue may provide a better surge buffer for the SAN without impacting other traffic. What are your thoughts?


We also have a SIP-400 with 2xGE Spa we can look at using,  which is the better solution.

That needs SXI3, and we won't be looking at that until early next year though.


Do you know if Cisco has any refguides that deal with FCIP replication over an IP WAN using 6500's as the WAN devices ?

That may be the best doc if it exists.  None of the campus guides I looked at had that detail.

Edison Ortiz Wed, 11/25/2009 - 20:43
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

[email protected]


Hi again Edison


Yes, The SAN traffic is "Voice-like" in terms of drops.. but isn't bothered much by Jitter, so I wouldn't put it in the priority queue.

Besides, there's a lot of voice and video conf that is jitter sensitive that also needs to be protocted.


My thoughts are to to give the SAN it's own queue, and allocate 25% of the bw to it, and no 'drop' thereshold.

I'm also considering using the GigE uplink on the Sup720-VSS-10GE itself... These ports have 9MB tx-queue space vs the 1MB on the 6724.

The large queue may provide a better surge buffer for the SAN without impacting other traffic. What are your thoughts?


We also have a SIP-400 with 2xGE Spa we can look at using,  which is the better solution.

That needs SXI3, and we won't be looking at that until early next year though.


Do you know if Cisco has any refguides that deal with FCIP replication over an IP WAN using 6500's as the WAN devices ?

That may be the best doc if it exists.  None of the campus guides I looked at had that detail.


If you have voice and video traversing those links then I definitely will not recommend marking this application as priority traffic.


The problem with regular line card is that you can't allocate nor protect traffic like you do with MQC on IOS routers.

You do have the SIP-400 available and I don't understand the need for going with SXI on its support - unless you have the SPA-2X1GE-V2 instead of SPA-2X1GE. SPA-2X1GE is supported with SXF and onward.


The SIP-400 will provide the requirements for this type of configuration design.


I don't know of any document regarding FCIP replication and QoS BP around this environment.


With the tools you have, I recommend doing the QoS with the SIP and it will allow you to protect multiple classes of data over the link.


Regards


Edison.

Wes Smith Wed, 11/25/2009 - 21:04
User Badges:

Yup, It's a SPA-2X1GE-V2, and is currently allocated for a different circuit..  I can steal it, but not until 2Q10. (non-technical reasons)


Re protection/ fairness.


Doesn't setting the wrr-queue bandwidth for both q1 and q2 to 25% make these two queues play nice with each other?

I thought the purpose with dwrr was to ensure that no queue was starved..


I had hoped there was some exisitng MDS9000/6500 based guidlines already.

Edison Ortiz Thu, 11/26/2009 - 07:56
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

[email protected]



Re protection/ fairness.


Doesn't setting the wrr-queue bandwidth for both q1 and q2 to 25% make these two queues play nice with each other?

I thought the purpose with dwrr was to ensure that no queue was starved..


I had hoped there was some exisitng MDS9000/6500 based guidlines already.


Yes, they will play nice with each other but so does the default setting. The trick is changing the COS on the SAN traffic from the default (COS 0) and assign this traffic to a dedicate queue and threshold. You did mention this earlier, I'm just reiterating.

The main difference between your regular MQC IOS that can be used with the SIP vs the DWRR scheduler that can be used with the regular line card is that MQC IOS only kicks in during congestion. If there isn't congestion in the line, traffic is treatly equally. With DWRR, you will always have the scheduler active and can potentially create latency on other type of traffic if queues aren't sized properly. That's the reason why we don't recommend moving away from the default unless you have a fairly good understanding of ALL type of applications running in your network.


Based on your posts, it seems you have a good handle of what's running in your network but please proceed with care.


Another option I may recommend is running this type of traffic over a dedicate link - I like the idea of using the Sup720VSS switchport for this task.

With Layer2 traffic engineering, you can allow only this type of traffic traversing this link. For instance, your normal traffic can traverse the trunk link and exclude the SAN VLAN from that trunk. Then on the Sup720VSS switchport just configure the SAN VLAN as an access port.


Regards


Edison.

Actions

This Discussion