From: Larry Roberts (larryr@netbeam.net)
Date: Sat Aug 30 2003 - 03:46:28 GMT-3
Larry,
I would say most likely the backup traffic is occurring between the same two
hosts or the same source on different sides of the Etherchannel. This is the
way Etherchannel frame distribution works. EtherChannel distributes frames
across the links in a channel by reducing part of the binary pattern (the
last 2 bits) formed from the mac addresses in the frame to a numerical value
that selects one of the links in the channel. This is configurable on most
switches to use either MAC addresses or IP addresses, and either source or
destination, or both source and destination addresses. The selected mode
applies to all EtherChannels configured on the switch. It is recommended to
use the option that provides the greatest variety in your network
environment to avoid the exact problem you are describing. For example, if
the traffic on a channel is only going to a single MAC address, using the
destination MAC address always chooses the same link in the channel; using
source mac addresses or IP addresses will result in better frame
distribution in this scenario.
Depending on the type of switch there are different defaults. Most use src
mac-address and src-dest IP addresses by default. Older 6500s can only use
source and destination mac-addresses and no other options are available. You
can do a show module command for the Supervisor Engine to determine if
EtherChannel frame distribution is configurable on your 6500. If the display
shows the "Sub-Type" to be "L2 Switching Engine I WS-F6020," then
EtherChannel frame distribution is not configurable on your switch; it uses
source and destination MAC addresses only. EtherChannel frame distribution
is configurable with all other switching engines.
Configuring Etherchannel Load Balancing on the 3550:
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12114ea1/3550scg/s
wethchl.htm#1020401
Configuring Etherchannel Load Balancing on the 6500:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_1/confg_gd/
channel.htm#1020899
Looks like the 6500 can also do Etherchannel load-balancing based on Layer 4
information now.
As far as why both links are being shown utilized at 90% I don't know if
that is a bug or the way it is normally reported on Etherchannel.
HTH,
Larry Roberts
CCIE #7886 (R&S / Security)
----- Original Message -----
From: "Larry Letterman" <lletterm@cisco.com>
To: "'Larry Roberts'" <larryr@netbeam.net>; "'Brian McGahan'"
<bmcgahan@internetworkexpert.com>; "'MMoniz'" <ccie2002@tampabay.rr.com>;
"'James Stewart'" <j_t_s_stewart@hotmail.com>; <ccielab@groupstudy.com>
Sent: Friday, August 29, 2003 10:23 PM
Subject: Utilization...take a look..
> List members...thought you might like to see what most of us
> Assumed wouldn't happen...below is the sh int g8/6 command on
> A data center router that is moving data between data centers
> For a backup....not the drops and the load 249/255...
>
> Brian and others,
> This is an ether channel port, and both interfaces in the port channel
> Show the same as below, I am assuming that this should be a 2gb link. I
> am wondering
> Why both links show utilized at 90%+ when the load is about 930 M/s..is
> this
> A flaw in the IOS reporting, since the port channel should be using both
> links ?
>
> sjc5-dc1-gw1#sh int g8/6
> GigabitEthernet8/6 is up, line protocol is up (connected)
> Hardware is C6k 1000Mb 802.3, address is 00d0.0093.f40a (bia
> 00d0.0093.f40a)
> Description: to sjc5-rowe-sw1
> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> reliability 255/255, txload 249/255, rxload 8/255
> Encapsulation ARPA, loopback not set
> Keepalive set (10 sec)
> Full-duplex mode, link type is autonegotiation, media type is SX
> output flow-control is unsupported, input flow-control is unsupported,
> 1000M
> s
> Clock mode is auto
> input flow-control is off, output flow-control is off
> ARP type: ARPA, ARP Timeout 04:00:00
> Last input 00:00:01, output 00:00:21, output hang never
> Last clearing of "show interface" counters 00:00:15
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
> 11864
> Queueing strategy: fifo
> Output queue :0/40 (size/max)
> 5 minute input rate 34935000 bits/sec, 67423 packets/sec
> 5 minute output rate 977391000 bits/sec, 87046 packets/sec
> L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
> L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
> L3 out Switched: ucast: 0 pkt, 0 bytes
> 1366536 packets input, 88670462 bytes, 0 no buffer
> Received 50 broadcasts, 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> 0 input packets with dribble condition detected
> 9656723 packets output, 13556200214 bytes, 0 underruns
> 0 output errors, 0 collisions, 0 interface resets
> 0 babbles, 0 late collision, 0 deferred
> 0 lost carrier, 0 no carrier
> 0 output buffer failures, 0 output buffers swapped out
> sjc5-dc1-gw1#
>
> Larry Letterman
> Cisco Systems
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Larry Roberts
> Sent: Wednesday, August 20, 2003 2:30 PM
> To: Brian McGahan; 'MMoniz'; 'James Stewart'; ccielab@groupstudy.com
> Subject: Re: QoS on Router or Switch
>
>
> Brian,
>
> I would use this more in a peer-to-peer file sharing scenario. If you
> are in a scenario like some universities that cannot block Kazaa and the
> others because the students will complain to the administration, I would
> simply allow Kazaa, but only give them a certain percentage of bandwidth
> and never anything about that. With this scenario the service works, but
> I never have to worry about it taking up my whole pipe. This may or may
> not be James' dilemma, but it is one option. The great thing about QoS
> on Cisco gear is that you have multiple options to accomplish your goal,
> so either one of our suggestions will work, James just needs to do some
> research and decide which one is the best for his environment.
>
> - Larry
>
>
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "'Larry Roberts'" <larryr@netbeam.net>; "'MMoniz'"
> <ccie2002@tampabay.rr.com>; "'James Stewart'"
> <j_t_s_stewart@hotmail.com>; <ccielab@groupstudy.com>
> Sent: Wednesday, August 20, 2003 2:19 PM
> Subject: RE: QoS on Router or Switch
>
>
> > Larry,
> >
> > If the link is not congested, then why limit the traffic?
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-334-8987
> > Direct: 708-362-1418 (Outside the US and Canada)
> >
> >
> > -----Original Message-----
> > From: Larry Roberts [mailto:larryr@netbeam.net]
> > Sent: Wednesday, August 20, 2003 4:15 PM
> > To: Brian McGahan; 'MMoniz'; 'James Stewart'; ccielab@groupstudy.com
> > Subject: Re: QoS on Router or Switch
> >
> > Brian,
> >
> > By rate-limiting the FTP traffic, I mean using CAR to limit FTP to say
>
> > 512k. This action is in effect even when the link is not congested. I
> > would recommend this or WRED as suggested by phong. I wouldn't
> > recommend LLQ or PQ
> > for web traffic as it is not interactive and doesn't care about
> dropped
> > packets or delay and jitter.
> >
> > -Larry
> >
> >
> >
> > ----- Original Message -----
> > From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> > To: "'Larry Roberts'" <larryr@netbeam.net>; "'MMoniz'"
> > <ccie2002@tampabay.rr.com>; "'James Stewart'"
> > <j_t_s_stewart@hotmail.com>; <ccielab@groupstudy.com>
> > Sent: Wednesday, August 20, 2003 2:03 PM
> > Subject: RE: QoS on Router or Switch
> >
> >
> > > Larry,
> > >
> > > Rate-limiting the FTP traffic would not have any effect since the
> > > link is not congested. The only QoS mechanism that is constantly
> > in
> > > effect even when there is no congestion is the priority queue. The
> > > priority queue includes the legacy priority queue, the low latency
> > > queue, and RTP.
> > >
> > > Another consideration when trying to answer this question is the
> > > direction of the FTP flow. Are clients receiving the FTP data or
> > > sending the FTP data? If we assume that the clients are downloading
> > FTP
> > > data from the internet, and trying to access web services from the
> > > internet, the most effective place to apply a priority queue would
> > > be upstream, which in this case is R2.
> > >
> > > If you configure a low latency queue to prioritize web replies
> > > (source of TCP 80 not destination) from servers on the internet,
> > > this solution should be effective. You could also configure a
> > > legacy priority queue on R2, however then you run the risk of
> > > completely starving the FTP transfers if web replies are
> > > consistently in the
> > higher
> > > queues.
> > >
> > >
> > > HTH,
> > >
> > > Brian McGahan, CCIE #8593
> > > bmcgahan@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com
> > > Toll Free: 877-334-8987
> > > Direct: 708-362-1418 (Outside the US and Canada)
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> > > Larry Roberts
> > > Sent: Wednesday, August 20, 2003 3:43 PM
> > > To: MMoniz; James Stewart; ccielab@groupstudy.com
> > > Subject: Re: QoS on Router or Switch
> > >
> > > That is why I recommended rate-limiting the FTP traffic instead. :-)
> > >
> > > -Larry
> > >
> > > ----- Original Message -----
> > > From: "MMoniz" <ccie2002@tampabay.rr.com>
> > > To: "Larry Roberts" <larryr@netbeam.net>; "James Stewart"
> > > <j_t_s_stewart@hotmail.com>; <ccielab@groupstudy.com>
> > > Sent: Wednesday, August 20, 2003 1:39 PM
> > > Subject: RE: QoS on Router or Switch
> > >
> > >
> > > > Jim,
> > > >
> > > > To me this sounds more like a WCCP solution. Since the link isn't
> > > congested
> > > > QOS will not really come into play, except of course for like
> > > bandwidth
> > > > amounts and such.
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> > > > Behalf
> > Of
> > > > Larry Roberts
> > > > Sent: Wednesday, August 20, 2003 3:01 PM
> > > > To: James Stewart; ccielab@groupstudy.com
> > > > Subject: Re: QoS on Router or Switch
> > > >
> > > >
> > > > James,
> > > >
> > > > QoS is much easier to implement on a router as opposed to a
> > > > switch.
> > I
> > > would
> > > > also look at rate-limiting the FTP traffic so that it can only use
> > up
> > > a
> > > > certain percentage of the bandwidth. Rate-limiting can be done
> > either
> > > > inbound or outbound on the router, shaping can only be done
> > outbound.
> > > >
> > > > HTH,
> > > > Larry Roberts
> > > > CCIE #7886 (R&S / Security)
> > > >
> > > > ----- Original Message -----
> > > > From: "James Stewart" <j_t_s_stewart@hotmail.com>
> > > > To: <ccielab@groupstudy.com>
> > > > Sent: Wednesday, August 20, 2003 11:52 AM
> > > > Subject: QoS on Router or Switch
> > > >
> > > >
> > > > > Hi
> > > > >
> > > > > Not sure where to apply the QoS.
> > > > >
> > > > > Users on a LAN on R1 complain that www access is slow. R1 is
> > > > > connected to the internet via a FR link to R2, which is not
> > > > congested.
> > > > > Users on the LAN are also backing up several servers using FTP
> > over
> > > the
> > > > > same link.
> > > > >
> > > > > Should the QoS giving priority to www over ftp be implemented on
> > the
> > > 3550
> > > > > switch egress port, ingress port of R1 or the egress of R1?
> > > > >
> > > > > Any ideas?
> > > > >
> > > > > Thanks Jim
> > > > >
> > > > > ________________________________________________________________
> > > > > _
> > > > > Sign-up for a FREE BT Broadband connection today!
> > > > > http://www.msn.co.uk/specials/btbroadband
> > > > >
> > > > >
> > > > >
> > >
> > ______________________________________________________________________
> > _
> > > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > Group.
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > > >
> > >
> > ______________________________________________________________________
> > _
> > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > > > Group.
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > > >
> > >
> > ______________________________________________________________________
> > _
> > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > > > Group.
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > ______________________________________________________________________
> > _
> > > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > ______________________________________________________________________
> > _
> > > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:54:10 GMT-3