From: Larry Letterman (lletterm@cisco.com)
Date: Sat Aug 30 2003 - 02:23:34 GMT-3
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
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:54:10 GMT-3