From: Larry Letterman (lletterm@cisco.com)
Date: Sat Aug 30 2003 - 04:28:36 GMT-3
Larry
Thanks for the insight into the echannel...after some more looking
It appears that the DC that is being backed up across the network is
Sending 800m/s on both links to the other DC gateways. The 800m/s on
One link goes to the redundant etherchannel to the switch for the backup
Frames. The graphs actually show that the Etherchannel is splitting the
Load at 45% each..
The other link brings 800m/s to that switch thru the ether channel and
probably
Gets balanced at 45% each, but the switch also gets backup data from
servers on
In the DC that the backup system sits in, and all that data goes thru
these links
That show 100% due to the hsrp active gateway for those servers being on
that side of the
Switch...
Again thanks for the time and the explanation...
Larry Letterman
Cisco Systems
-----Original Message-----
From: Larry Roberts [mailto:larryr@netbeam.net]
Sent: Friday, August 29, 2003 11:46 PM
To: Larry Letterman; 'Brian McGahan'; 'MMoniz'; 'James Stewart';
ccielab@groupstudy.com
Subject: Re: Utilization...take a look..
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/3550s
cg/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
> > > > >
> > > > >
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:54:10 GMT-3