No. The FEX has BPDU Guard logic running in hardware. The moment a BPDU is received on the port it will be disabled.
On the blade switches you can implement: 1) Flex Links (safe) 2) Egress BPDU filter (risky) 3) Disable STP (dangerous) For #2 and #3, a misconfigured or missing LACP config can cause a loop. For #3, a misconfigured server NIC teaming can cause a loop. Cheers, Brad http://bradhedlund.com Sent from my iPad (please excuse brevity, typos) On Aug 5, 2011, at 9:49 AM, "Matthew Melbourne" <[email protected]> wrote: > Can P prevent a FEX port being disabled by implementing bpdufilter, or > do we need to ensure that BPDUs aren't receiving on FEX ports? > > We were hoping to use LACP between the downstream switch and the FEXes > as a poor-man's loop prevention mechanism. > > Cheers, > > Matt > > On 5 August 2011 15:17, John Gill <[email protected]> wrote: >> 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/ >> > > > > -- > 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/
