From: asadovnikov (asadovnikov@comcast.net)
Date: Thu Jun 03 2004 - 20:46:46 GMT-3
Assuming that your core is L3 (which it really should be), for 2 gig I would
rather see you use 2 independent point-to-point L3 links. CEF loadbalancing
will be almost as effective as EtherChannel, while EtherChannel is real
difficult to troubleshoot. If you have your mind set on EtherChannel go
with L3 one.
In most today networks VTP brings no benefit, so I would recommend you to
run all you boxes in transparent mode (not in server mode). It is fine then
to use same domain name. If you think you will benefit from VTP let me know
why you need it, and I may be able to give you another recommendation.
Best regards,
Alexei
-----Original Message-----
From: LoizosCisco [mailto:david_steven2001@yahoo.com]
Sent: Wednesday, June 02, 2004 12:15 PM
To: asadovnikov
Cc: ccielab@groupstudy.com
Subject: RE: Connecting two core switches / Design
Alexei,
I have two Core 6509 and a dozen distribution 6509
MSFCs connecting to both cores. I have to configure
2GIG Etherchannel between the two cores and I am
wondering if I should configure etherchannel with
trunking (Layer 2), or Etherchannel with IP (Layer 3).
The connection between the cores and distribution
switches are Layer 3. Then there are multiple Layer 2
stacks below the Distribution which are trunked to the distribution.
I am also concern about the VTP domain assignment. Do
I configure a VTP Server at each distribution layer
with the same domain name? What should be the best
practice for VTP assignment in suck an environment?
--- asadovnikov <asadovnikov@comcast.net> wrote:
> May I ask why do you need to interconnect the core
> switches in the first
> place?
>
> I know it sounds like silly question, but let us
> look into it... Let us say
> such link is not there... I would assume that all distribution
> switches have an uplink to each core.
>
> CORE-A CORE-B
> | \ __________/ |
> | \__/_______ |
> | / \ |
> | / \ |
> Distribution-A Distribution-B
>
> Say Distribution-A has a packet to ship to
> Distribution-B, and it sends it
> to CORE-A (for the sake of example). CORE-A would
> send it to Distribution-B
> directly.
>
> So when traffic hits one of the core switches it
> would not ever go to
> another core switch, except if there was a link
> failure. Further, if only
> one distribution to core link fails, all other
> distribution switches would
> use the core box which continues to have
> connectivity to this distribution
> switch.
>
>
> CORE-A CORE-B
> | __________/ |
> | / |
> | / |
> | / |
> Distribution-A Distribution-B
>
> In this case Distribution-A would know that the best
> route to Distribution-B
> is via CORE-B, and will forward all traffic there.
>
> So only possible need for one core to need to
> forward to another is in
> situation of dual link failures, like this
>
> CORE-A CORE-B
> | |
> | |
> | |
> | |
> Distribution-A Distribution-B
>
> Even then you have then another dozen or so
> distribution switches (not shown
> on the diagram above) which the cores can use to
> route around dual failure,
> even though it will introduce suboptimal routing.
>
> Much I hate any situations of suboptimal routing I
> have to ask what are the
> chances of your network to run with 2 hardware
> failures on the core. And my
> take would be that it is real low, as each failure
> on the core should be
> promptly fixed.
>
> Having said that you may want to interconnect the
> cores just in case, but
> then since we have just demonstrated that such link
> would be almost never
> used, oversubscription question is much irrelevant.
> If you want to be on
> really safe side by all means do provide core
> crosslink, but I would not
> sweat about how large it is... may be 2-4 gig (or if
> a lot of spare money do
> 2x 10 gig).
>
> Obviously each network requirements are so unique,
> it is almost impossible
> to have one-size-fits-all answers. So do send
> additional information.
>
> Best regards,
> Alexei
>
> P.S. QOS on the crosslinks/uplinks is a good think,
> assuming you have
> classification/marking on the edge and can actually
> tell what traffic is
> more or less important. For example if you provide
> voice services, and
> voice is marked on the network entry it is real good
> idea to give it
> priority over data, and with today hardware
> implementations of QOS there is
> no performance penalty to pay.
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf Of
> Kenneth Wygand
> Sent: Tuesday, June 01, 2004 11:48 AM
> To: Group Study
> Subject: Connecting two core switches / Design
>
>
> Hello all,
>
>
>
> I was thinking about large providers that need to
> connect core switches at
> very fast speeds. For example, say I have two 6506
> core switches I wanted to
> connect in the backbone. Say each one is
> terminating 20 - 30 fiber gigabit
> speed links. I would think it would be a poor idea
> to oversubscribe the
> link between these switches to a 1GBit or even
> 10GBit link. If the link was
> oversubscribed, logic would think that QoS should be
> employed here to make
> sure critical traffic (voice, video) gets through
> first, but all design
> guides point towards keeping all QoS out of the core
> to simply switch
> packets as fast as possible...
>
>
> What is recommended and is there any documentation / experience anyone
> can contribute?
>
>
>
> Thanks!
>
>
>
> Kenneth E. Wygand
> Systems Engineer, Project Services
>
> CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design
> Specialist, MCP, CNA,
> Network+, A+
> Custom Computer Specialists, Inc.
>
> "I am not really smart. I just stick with problems
> longer." -Albert Einstein
>
>
>
> Custom Computer Specialists, Inc.
>
> "Celebrating 25 Years of Excellence"
>
> [GroupStudy removed an attachment of type image/gif
> which had a name of
> image001.gif]
>
>
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:32 GMT-3