From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Sat Jan 14 2006 - 01:33:02 GMT-3
Chris, have you thought to do a special doc for QoS. Sure I'll be one of the
first in the list to read your explanations
Thanks for your help here man..
Victor.
_____
De: Chris Lewis [mailto:chrlewiscsco@gmail.com]
Enviado el: viernes, 13 de enero de 2006 23:46
Para: Victor Cappuccio
CC: ccielab@groupstudy.com
Asunto: Re: Frame relay DE-bit
Hi Victor,
Regards ECN, the univercd link you have is all you need to know I believe.
Regarding the why, well ECN is a way to try to avoid congestion happening in
the first place. WRED does this by selectively discarding the packets,
assuming the traffic consists of TCP or TCP like flows and that dropped
packets will cause hosts to slow down their transmission. ECN goes one step
further in trying to avoid congestion without any packet loss. Once the ECN
bits (called ECT and CE) get set (due to the presence of congestion), hosts
see this and slow down transmission, thus avoiding further congestion. It
does not get much use as not enough devices support the ECN mechanism.
One of the arguments in academic circles against WRED is that by definition
a packet is dropped prior to the queue being completely filled up, therefore
you are dropping a packet that could be transmitted, which some people see
as a bad thing. There is plenty of research that shows the trade off of
dropping a packet early by WRED rather than relying on tail drop and
suffering the effects of host TCP synchronization is worth it. ECN is a good
idea, it is just not widely available enough.
Chris
On 1/13/06, Victor Cappuccio <cvictor@protokolgroup.com> wrote:
I'm wondering why about that?
Could be because the PIM Traffic is treated like a broadcast?
Anyway you can use the multicast rate-limiting tools to control the traffic
feed right?
Hey Chris, I know you are a QoS Guru, what books / links could you recommend
us to read to understand about ECN..
I have this 2 http://en.wikipedia.org/wiki/Network_congestion_avoidance
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
t/122t8/ftwrdecn.htm
But I still have some deal about the Why
Thanks
Victor.
-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de Chris
Lewis
Enviado el: viernes, 13 de enero de 2006 18:56
Para: Chris Atkins
CC: ccielab@groupstudy.com
Asunto: Re: Frame relay DE-bit
PIM should not be marked DE, all other should. You can see the effect by
looking at the show frame-relay pvc output send a few pings, see DE go up,
then enable PIM and it should not increase the counters by the number of PIM
packets (can confirm number of PIM packets with an ACL )
Router1>sho frame pvc
PVC Statistics for interface Serial2/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 0 0 0 0
Switched 0 0 0 0
Unused 3 0 0 0
DLCI = 122, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial2/0
input pkts 0 output pkts 0 in bytes 0
out bytes 0 dropped pkts 0 in pkts dropped
0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 * in DE pkts 0 out DE pkts 0 *
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
switched pkts 0
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 0 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
On 1/13/06, Chris Atkins < <mailto:chris_atkins@blueyonder.co.uk>
chris_atkins@blueyonder.co.uk> wrote:
>
> Hi all
> Still bit lost on this, if i could put a sniffer on would. Any sugestions
> most
> appreciated.
>
> Cheers
>
> Chris
> ----- Original Message -----
> From: Chris Atkins
> To: ccielab@groupstudy.com
> Sent: Friday, January 13, 2006 2:37 PM
> Subject: Frame relay DE-bit
>
>
> Hi all
> Quick question, would the config below ensure that PIM is not marked with
> the DE bit set, or should I just have the permit IP any any statement so
> only
> IP traffic is marked ? bit confused :o)
>
>
> frame-relay de-list 10 protocol ip list 100
> !
> access-list 102 deny pim any any
> access-list 102 permit ip any any
> !
> interface Serial0/0
> ip address 172.16.23.2 255.255.255.248
> encapsulation frame-relay
> ip ospf network point-to-point
> ip ospf priority 0
> frame-relay de-group 10 403
> frame-relay map ip 172.16.23.1 403 broadcast
> no frame-relay inverse-arp
>
>
> Thanks in advance.
>
> Chris
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:49 GMT-3