From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Sat Sep 30 2006 - 17:15:31 ART
you're right, applying priority-group actually turns on queuing
mechanisms... missed this point
don't have a first-hand production experience with this, thanks for the
references :-)
A.
Petr Lapukhov wrote:
> Hi Radoslav,
>
> First, I use the following documents as reference:
>
> DLCI Priority:
> http://www.cisco.com/warp/public/125/12.html#topic8
>
> PIPQ:
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a008007fe83.html
>
> Like I said,
>
> PIPQ is mapping of DLCIs to Intertface Priority Queue [it is a primitive
> classification
> (DLCI based) and queueing technology].
>
> DLCI Priority is mapping of PQ-queues to DLCI numbers [it's basically a
> classification technology (using PQ options) ].
> ---
>
> Now, with your task. I have mentioned that you should apply priority-group
> to interface to achieve complete QoS solution - that is, to provide local
> priority
> in addition to DLCI assignment.
>
> You apply to interface the same priority group you used to map traffic to
> DLCIs.
> As net result, you achieve interface prioritization, as well as DLCI
> assignment (and,
> hopefully, some priority treatment in FR cloud!).
>
> Next, PIPQ could be used on it's own. I even get it working in production :)
>
> You just use DLCI numbers to put packets into interface priority queue,
> that's
> all. For example, you may have voice running on one PVC, and file transfers
> on another. [In my production case i have "premium" client running over
> high-priroty queue, and every other guys on "normal"]
>
> PS
> Please note, that when PIPQ and FRF.12 are enabled at the same time,
> PIPQ takes erhh.. priority :) That is, fragmented and non-fragmented packets
> are classified via PIPQ mechanics, and not dual-FIFO (based on their size).
>
> 30.09.06, Radoslav Vasilev <deckland@gmail.com> NAPISAL(A):
>
>> Thanks Petr i Alexei!!!
>>
>> the DCLI priority levels worked, after disabling the WFQ on the interface.
>>
>> Will I be correct if I say that PIPQ could be used either with or
>> without DLCI Priority levels?
>>
>> In the case without priority levels, the task might say that multiple
>> dlci are used on an interface/subinterface and "...make sure dlci XXX
>> has absolute priority over the others...".
>>
>>
>> In the case with priority levels, the task might say that we have to
>> map one flow to dlci x, and another flow to dlci y, with default
>> (non-mapped traffic) to dlci zzz.
>>
>> For this case, I added PIPQ on se0/1 on r4:
>>
>> interface Serial0/1
>> ip address 192.168.100.5 255.255.255.0
>> encapsulation frame-relay
>> load-interval 30
>> frame-relay priority-dlci-group 1 100 101 101 101
>> frame-relay interface-queue priority
>> end
>>
>> Rack1R5#sh int se 0/1
>> Serial0/1 is up, line protocol is up
>> Hardware is PowerQUICC Serial
>> Internet address is 192.168.100.5/24
>> MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
>> reliability 251/255, txload 1/255, rxload 1/255
>> Encapsulation FRAME-RELAY, loopback not set
>> Keepalive set (10 sec)
>> LMI enq sent 77, LMI stat recvd 78, 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
>> Broadcast queue 0/64, broadcasts sent/dropped 1/0, interface broadcasts
>> 0
>> Last input 00:00:03, output 00:00:03, output hang never
>> Last clearing of "show interface" counters 00:12:57
>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>> Queueing strategy: DLCI priority
>> Output queue (queue priority: size/max/drops):
>> high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0
>> 30 second input rate 0 bits/sec, 0 packets/sec
>> 30 second output rate 0 bits/sec, 0 packets/sec
>> 138 packets input, 4779 bytes, 0 no buffer
>> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>> 1 input errors, 0 CRC, 1 frame, 0 overrun, 0 ignored, 0 abort
>> 150 packets output, 4802 bytes, 0 underruns
>> 0 output errors, 0 collisions, 3 interface resets
>> 0 output buffer failures, 0 output buffers swapped out
>> 4 carrier transitions
>> DCD=up DSR=up DTR=up RTS=up CTS=up
>>
>> you can see the queueing on the interface changed.
>> Is this the correct way of using pipq (with dlci priority levels)?
>>
>> Rado
>>
>> On 9/30/06, Petr Lapukhov <petr@internetworkexpert.com> wrote:
>>
>>> Hi Alexei :)
>>>
>>> It has some difference (interface FIFO or PQ)... Though it works in
>>>
>> both
>>
>>> cases :))
>>>
>>> #debug frame packet
>>> #debug priority
>>>
>>> With FIFO it just classifies and assigns packets to respective PVC:
>>>
>>> R4#ping 45.45.45.5
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 45.45.45.5, timeout is 2 seconds:
>>>
>>> *Sep 25 05:27:04.169: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>> *Sep 25 05:27:04.169: Serial0/1(o): dlci 100(0x1841), pkt type
>>>
>> 0x800(IP),
>>
>>> datagramsize 104.
>>> *Sep 25 05:27:06.169: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>> *Sep 25 05:27:06.169: Serial0/1(o): dlci 100(0x1841), pkt type
>>>
>> 0x800(IP),
>>
>>> datagramsize 104.
>>> *Sep 25 05:27:08.169: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>> *Sep 25 05:27:08.169: Serial0/1(o): dlci 100(0x1841), pkt type
>>>
>> 0x800(IP),
>>
>>> datagramsize 104.
>>> *Sep 25 05:27:10.169: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>>
>>> With PQ it also does PQ processing at _interface_ level:
>>>
>>> R4#ping 45.45.45.5
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 45.45.45.5, timeout is 2 seconds:
>>>
>>> *Sep 25 05:30:17.533: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>> *Sep 25 05:30:17.533: Serial0/1(o): dlci 100(0x1841), pkt type
>>>
>> 0x800(IP),
>>
>>> datagramsize 104
>>> *Sep 25 05:30:17.533: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>>
>>> *Sep 25 05:30:17.533: PQ: Serial0/1 output (Pk size/Q 104/0). <=======
>>> THIS ONE
>>>
>>> *Sep 25 05:30:19.533: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>> *Sep 25 05:30:19.533: Serial0/1(o): dlci 100(0x1841), pkt type
>>>
>> 0x800(IP),
>>
>>> datagramsize 104
>>> *Sep 25 05:30:19.533: PQ: Serial0/1: ip (s=45.45.45.4, d=45.45.45.5) ->
>>> high
>>>
>>> It probably makes sense to use interface PQ in this situation :) It's
>>>
>> QoS,
>>
>>> after all :)
>>>
>>> 30.09.06, Alexei Monastyrnyi <alexeim@orcsoftware.com> NAPISAL(A):
>>>
>>>> Works fine without one :-)
>>>> It picks priority group via "frame-relay priority-dlci-group"
>>>>
>>>> But it should be FIFO on both interfaces to have it working.
>>>>
>>>> A.
>>>>
>>>> on 9/30/2006 3:52 PM Petr Lapukhov wrote:
>>>>
>>>>> It's seems like that you forgot to put "priority-group 1" command on
>>>>> interfaces.
>>>>>
>>>>> I remember I tried that "esoteric" topic back in days :) It doesn't
>>>>>
>>> seems
>>>
>>>>> it'll
>>>>> become a popular technology :)
>>>>>
>>>>> HTH
>>>>>
>>>>> PS
>>>>> Actually, this is not called PIPQ - it's "DLCI prioritization" :)
>>>>>
>> PIPQ
>>
>>> is
>>>
>>>>> when you
>>>>> schedule different DLCIs into different priority queues.
>>>>>
>>>>> DLCI prioritization is the "reverse" case, where you put traffic
>>>>>
>> with
>>
>>>>> different
>>>>> priorities into different DLCIs.
>>>>>
>>>>> 2006/9/30, Radoslav Vasilev < deckland@gmail.com>:
>>>>>
>>>>>
>>>>>> Hi Group,
>>>>>>
>>>>>> I'm trying to separate two classes of traffic over two separate PVC
>>>>>> over a single link (back to back between two routers). The idea is
>>>>>>
>> to
>>
>>>>>> later use PIPQ and test connectivity while checking the queueing
>>>>>>
>> with
>>
>>>>>> PIPQ.
>>>>>>
>>>>>> R4 and R5 connected back-to-back over interfaces serial 0/1 on
>>>>>>
>> each:
>>
>>>>>> R4:
>>>>>>
>>>>>> frame-relay switching
>>>>>>
>>>>>> interface Serial0/1
>>>>>> ip address 192.168.100.4 255.255.255.0
>>>>>> encapsulation frame-relay
>>>>>> clock rate 128000
>>>>>> frame-relay priority-dlci-group 1 100 101 101 101
>>>>>> frame-relay intf-type dce
>>>>>> end
>>>>>>
>>>>>> access-list 100 permit icmp any any
>>>>>> access-list 101 permit tcp any any eq telnet
>>>>>> access-list 101 permit tcp any eq telnet any
>>>>>> priority-list 1 protocol ip high list 101
>>>>>> priority-list 1 protocol ip low list 100
>>>>>>
>>>>>> R5:
>>>>>>
>>>>>> frame-relay switching
>>>>>>
>>>>>> interface Serial0/1
>>>>>> ip address 192.168.100.5 255.255.255.0
>>>>>> encapsulation frame-relay
>>>>>> load-interval 30
>>>>>> frame-relay priority-dlci-group 1 100 101 101 101
>>>>>> end
>>>>>>
>>>>>> access-list 100 permit icmp any any
>>>>>> access-list 101 permit tcp any any eq telnet
>>>>>> access-list 101 permit tcp any eq telnet any
>>>>>> priority-list 1 protocol ip high list 101
>>>>>> priority-list 1 protocol ip low list 100
>>>>>>
>>>>>> As seen above, i want to use DLCI 100 for telnet traffic (two-way)
>>>>>>
>> and
>>
>>>>>> DLCI 101 for icmp traffic.
>>>>>>
>>>>>> I'm testing with pinging/telneting to R4 from R5,here's the debug
>>>>>>
>> on
>>
>>> R4:
>>>
>>>>>> while telneting from R5:
>>>>>> Rack1R4# 1 00:59:45.659: Serial0/1(i): dlci 101(0x1851), pkt type
>>>>>> 0x800, datagramsize 45
>>>>>> *Mar 1 00:59:45.763: Serial0/1(o): dlci 101(0x1851), pkt type
>>>>>> 0x800(IP), datagramsize 44
>>>>>> *Mar 1 00:59:45.767: Serial0/1(i): dlci 101(0x1851), pkt type
>>>>>>
>> 0x800,
>>
>>>>>> datagramsize 45
>>>>>> *Mar 1 00:59:45.975: Serial0/1(o): dlci 101(0x1851), pkt type
>>>>>> 0x800(IP), datagramsize 44
>>>>>> *Mar 1 00:59:45.983: Serial0/1(i): dlci 101(0x1851), pkt type
>>>>>>
>> 0x800,
>>
>>>>>> datagramsize 46
>>>>>> *Mar 1 00:59:45.983: Serial0/1(o): dlci 101(0x1851), pkt type
>>>>>> 0x800(IP), datagramsize 54
>>>>>>
>>>>>>
>>>>>> whilte pinging from R5:
>>>>>> *Mar 1 01:00: 18.099: Serial0/1(o): dlci 101(0x1851), pkt type
>>>>>> 0x800(IP), datagramsize 104
>>>>>> *Mar 1 01:00:18.115: Serial0/1(i): dlci 101(0x1851), pkt type
>>>>>>
>> 0x800,
>>
>>>>>> datagramsize 104
>>>>>> *Mar 1 01:00: 18.115: Serial0/1(o): dlci 101(0x1851), pkt type
>>>>>> 0x800(IP), datagramsize 104
>>>>>> *Mar 1 01:00:18.131: Serial0/1(i): dlci 101(0x1851), pkt type
>>>>>>
>> 0x800,
>>
>>>>>> datagramsize 104
>>>>>> *Mar 1 01:00: 18.131: Serial0/1(o): dlci 101(0x1851), pkt type
>>>>>> 0x800(IP), datagramsize 104
>>>>>> *Mar 1 01:00:18.151: Serial0/1(i): dlci 101(0x1851), pkt type
>>>>>>
>> 0x800,
>>
>>>>>> datagramsize 104
>>>>>>
>>>>>> So it looks like the normal priority queue is selected...
>>>>>>
>>>>>> Rack1R5#sh frame-relay map
>>>>>> Serial0/1 (up): ip 192.168.100.4 dlci 100(0x64,0x1840), dynamic,
>>>>>> broadcast,, status defined, active
>>>>>> Priority DLCI Group 1, DLCI 100 (HIGH), DLCI 101 (MEDIUM)
>>>>>> DLCI 101 (NORMAL), DLCI 101 (LOW)
>>>>>>
>>>>>> Any ideas?
>>>>>> Thaks
>>>>>> Rado
>>>>>>
>>>>>>
>>>>>>
>>> _______________________________________________________________________
>>>
>>>>>> Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>
>>>>
>>> _______________________________________________________________________
>>>
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>
>>> --
>>> Petr Lapukhov, CCIE #16379
>>> petr@internetworkexpert.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.InternetworkExpert.com
>>> Toll Free: 877-224-8987
>>> Outside US: 775-826-4344
>>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:42 ART