Re: Design issue

Fast Hellos is where it's at!
JB

On Tue, May 3, 2011 at 1:07 AM, Travis Niedens <niedentj_at_hotmail.com> wrote:
> Regarding VSS --
>
> There are three DAD methods - PaGP+, BFD and Fast Hellos. You really should
> look at what SXI 4+ introduced - the ability to have more than one sup in a
> chassis (only one can handle the control plane though). If a failure were to
> occur, say all the VSLs go down, the primary switch would continue
> forwarding whereas the other switch would shut down all of its non VSL
> ports. This action allows the control and forwarding plane to be stable. As
> to what this does to redundancy, you need to make sure you have links to
> both as much as possible. I prefer the use of Fast Hello over the others as
> it is quicker and does not rely on exterior devices to help the core decide
> what to do.
>
> Some would argue that this approach was a sloppy attempt to do what the
> Nexus series does with VPCs.
>
> Links:
>
> http://www.cisco.com/web/DK/assets/docs/presentations/VSS_0109.pdf
>
> http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_c
> h3.html
>
> Quad VSS Sups:
>
> Virtual Switching System (VSS) Quad-Supervisor Uplink Forwarding
>
> Cisco IOS Software Release 12.2(33)SXI4 introduces support for
> dual-supervisors in each of the active and standby VSS chassis, together
> forming a quad-supervisor VSS system. These secondary supervisors can also
> be used to forward traffic on the uplink ports thereby enabling all four
> supervisors in a VSS system to actively forward traffic under normal
> conditions. Furthermore, the additional supervisors can act as standby
> supervisors within each chassis to provide resilient network connectivity to
> single-homed devices and maximum bandwidth availability to both upstream and
> downstream connected devices
>
> Nexus vPCs:
>
> http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/interfaces/
> configuration/guide/if_vPC.html
>
> Travis
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of JB
> Poplawski
> Sent: Monday, May 02, 2011 8:35 PM
> To: Kiran Parashare
> Cc: Ahmed; Cisco certification; Cisco certification
> Subject: Re: Design issue
>
> You're losing me on the module failing. You lose the SUP on one of your
> switches and you lose that switch. If you have a port channel and lose a
> port, the other one should work. If you lose connectivity to both cores
> non-VSS... I'm not really sure. If the core is tied together with trunked
> switches, one core would "find it's way back to root" via BPDUs riding an
> access switch. If you're running VSS, it's recommended to run Dual Active
> Detection, in which case VSS (port
> channel) link would go down, the ports on one of the switches would all get
> set to admin down.
>
> Note, there's a lot smarter dudes on this forum than me, I just happened to
> be one to stick my neck out and offer some advice.
> Obviously, no one knows your environment better than you, white board it out
> and try and break it.
>
> Cheers!
> JB
>
> On Mon, May 2, 2011 at 10:24 PM, Kiran Parashare <kiran.ccie_at_gmail.com>
> wrote:
>> Hi,
>>
>> What if one of the module fail which has connection between core1-core2.
>> Still the server redundacy works ?
>>
>> HTH
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue May 03 2011 - 09:47:39 ART