Hi Arne,
If all the links in this diagram are 10G until we get to the 2148 host
interfaces, then the 2148 is likely dropping as it is responsible for
buffering the speed mismatch.
You should look into changing the buffer allocation on the 2148 with the
no queue-limit and no buffer-threshold commands. These will you give
you the maximum amount of buffer available, and then you can tune them
from here if you don't like the idea of shared buffering:
fex <id>
no hardware n2148t queue-limit
no hardware n2148t buffer-threshold
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/qos/421_n2_1/Cisco_Nexus_5000_Series_NX-OS_Quality_of_Service_Configuration_Guide_Rel_421_N2_1_chapter3.html#task_3F368F3C5E394547BCBA1AC70291DB29
John Gill
cisco
On 5/29/11 7:09 AM, Arne Larsen / Region Nordjylland wrote:
Hi John.
The topology is like this.
The EMC san is connected to 1 5K's of a pair with 10G trunk carrying 2 vlans.
The client is connected to another 5K dual setup trough an 2K extender.
The 2 5K are connected to an 6500-VSS with an vpc for each pair carrying 40G.
The odd thing is that I don't see any packet being dropped.
I'm planning on tomorrow, installing to servers with 10G intefaces's to verify
what trough put I get, and to see if I can provoke packet drop.
There was an other suggestion on the faq, that it could be something that's not
supporting pause framed on 802.3x.
We don't use a gw.addr on the peer link, just pointing the other out directly.
We are using the mng interface for the peer-link.
6500-vss
| |
Vpc links | | Vpc links
| |
5010-1/5010-2 5010-3/5010-4
| |
orphan- | |
port | | vpc link
| |
EMC-san extender 2148
|
|
Client
Hopefully this will give you a clue.
/Arne
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
