It would be filter toward the FEX ports on your blade switches, but not
on the FEX ports themselves. Whether you turn STP off or not on the
blades, the FEX doesn't know. Just remembering if you create a loop, you
no longer have the protection of STP; you are intentionally tricking the
FEX into not knowing there is a switch downstream.
Regards,
John Gill
cisco
On 8/5/11 9:59 AM, Matthew Melbourne wrote:
Thanks for that - that's another issue we've encountered. I am hoping
we can implement bpdufilter on the FEX ports (as well as disabling STP
on downstream switches).
On 5 August 2011 14:12, Brad Hedlund (brhedlun)<[email protected]> wrote:
Note that the FEX will disable any port that receives a BPDU, by design in
hardware. You will need to disable STP on the blade-switch-to-FEX links for
this to work. If it's Cisco blade switches you can use Flex Links.
Cheers,
Brad
http://bradhedlund.com
Sent from my iPad
(please excuse brevity, typos)
On Aug 5, 2011, at 6:08 AM, "Matthew Melbourne"<[email protected]> wrote:
Hi,
We're implementing two pairs of N5Ks (and downstream N2k FEXes) to act
as separate iSCSI SAN fabrics, with SAN heads attached directly to
N5Ks and host ports (and downstream integrated blade switches)
connecting to the FEXes. Does anyone have any real-world experience of
using N5Ks for a large iSCSI deployment. I have enabled jumbo frames
through a network-qos policy-map as an obvious first-step, but wonder
whether anything can be optimised by tuning buffer sizes to
accommodate the bursty nature of iSCSI (etc)? This switches will only
be switching iSCSI traffic.
Cheers,
Matt
--
Matthew Melbourne
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
