From: MADMAN (dmadlan@qwest.com)
Date: Wed Jun 02 2004 - 14:18:44 GMT-3
I usually configure an L2 channel, let spanning tree do it's job
except that I configure who is primary and secondary root, load share
over uplinks and such. Though yesterday I was involved in a STP
meltdown involving two 6509 with sup720s on which the etherchannel
errored, it was ugly. Still investigating why...
Dave
LoizosCisco wrote:
> 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]
>>
>>
>
> _______________________________________________________________________
>
>>Please help support GroupStudy by purchasing your
>>study materials from:
>>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>
>
> _______________________________________________________________________
>
>>Please help support GroupStudy by purchasing your
>>study materials from:
>>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367"Emotion should reflect reason not guide it"
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:31 GMT-3