From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Tue Aug 31 2004 - 13:45:53 GMT-3
Yes,
it used to be the case that all less than fragment size traffic went to
the priority interface queue, and the to be fragmented to the other.
Now, all the LLQ/Priority traffic goes to the priority interface queue,
and the rest go to the other.
BTW, priority queue size is twice the size of the normal queue. (Set
with hold-queue xx)
Also, there is still the possibility of having priority queues at the
interface (second stage).
And to add to the mess, the broadcast queue is still sitting there :-)
gladston@br.ibm.com wrote:
> Without Fragment
>
> r3#sh int ser 0
> Serial0 is up, line protocol is up
> Hardware is HD64570
> MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
> reliability 255/255, txload 1/255, rxload 1/255
> Encapsulation FRAME-RELAY, loopback not set
> Keepalive set (10 sec)
> LMI enq sent 49515, LMI stat recvd 49515, LMI upd recvd 0, DTE LMI up
> LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
> LMI DLCI 1023 LMI type is CISCO frame relay DTE
> FR SVC disabled, LAPF state down
> Broadcast queue 0/64, broadcasts sent/dropped 0/1, interface broadcasts 0
> Last input 00:00:03, output 00:00:03, output hang never
> Last clearing of "show interface" counters 5d17h
> Queueing strategy: fifo
> Output queue 0/40, 0 drops; input queue 0/75, 0 drops
> 5 minute input rate 0 bits/sec, 0 packets/sec
> 5 minute output rate 0 bits/sec, 0 packets/sec
> 126422 packets input, 5709168 bytes, 0 no buffer
> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 79423 packets output, 2259649 bytes, 0 underruns
> 0 output errors, 0 collisions, 1 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 2 carrier transitions
>
>
> With Fragment
>
> r3#sh conf
>
> interface Serial0
> no ip address
> encapsulation frame-relay
> ip ospf network point-to-point
> frame-relay traffic-shaping
> frame-relay lmi-type cisco
> !
> interface Serial0.32 multipoint
> ip address 172.16.23.3 255.255.255.0
> frame-relay class Frame
> frame-relay map ip 172.16.23.2 302 broadcast
> !
> map-class frame-relay Frame
> no frame-relay adaptive-shaping
> frame-relay fair-queue
> frame-relay fragment 80
>
> r3#sh int ser 0
> Serial0 is up, line protocol is up
> Hardware is HD64570
> MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
> reliability 255/255, txload 1/255, rxload 1/255
> Encapsulation FRAME-RELAY, loopback not set
> Keepalive set (10 sec)
> LMI enq sent 49521, LMI stat recvd 49521, LMI upd recvd 0, DTE LMI up
> LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
> LMI DLCI 1023 LMI type is CISCO frame relay DTE
> FR SVC disabled, LAPF state down
> Broadcast queue 0/64, broadcasts sent/dropped 0/1, interface broadcasts 0
> Last input 00:00:03, output 00:00:03, output hang never
> Last clearing of "show interface" counters 5d17h
> Queueing strategy: dual fifo
> Output queue: high size/max/dropped 0/256/0
> Output queue 0/128, 0 drops; input queue 0/75, 0 drops
> 5 minute input rate 0 bits/sec, 0 packets/sec
> 5 minute output rate 0 bits/sec, 0 packets/sec
> 126438 packets input, 5709892 bytes, 0 no buffer
> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 79433 packets output, 2259941 bytes, 0 underruns
> 0 output errors, 0 collisions, 2 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 2 carrier transitions
> DCD=up DSR=up DTR=up RTS=up CTS=up
>
> As you can see, I configured fragment on the subinterface 0.32; considering this, does the priority traffic from the subinterface 0.134 will go to the priority FIFO queue?
>
> _______________________________________________________________________
> 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
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:50 GMT-3