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.

wsmith@ca.ibm.com
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.

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.

wsmith@ca.ibm.com
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.