From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Tue Oct 17 2006 - 15:43:07 ART
Hi there Chee, since there is no taker, I'm sending myself to the emptiness
with this answer.
See the difference between PQ and frame-relay PIPQ is the way on how the
packets get classified, and send to the distinct Queues (as we all know
High, Medium, Normal and Low)
In PQ packet classification are based on packet contents, the thing you can
match with a normal and vulgar Extended | Standar ACL.
IN PIPQ prioritization is based on the destination PVC, instead of the
packet contents.
Now for the other parts of your question, I'm 100% sure that if you see a
router configuration it would help you understand the situation.
@R1:
access-list 101 permit tcp any any eq www
!
route-map WEB_TRAFFIC permit 10
match ip address 101
set ip next-hop 172.16.2.2
!
route-map WEB_TRAFFIC permit 20
interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
ip policy route-map WEB_TRAFFIC
!
map-class frame-relay MEDIUM
no frame-relay adaptive-shaping
frame-relay interface-queue priority medium
!
map-class frame-relay NORMAL
no frame-relay adaptive-shaping
!
map-class frame-relay LOW
no frame-relay adaptive-shaping
frame-relay interface-queue priority low
!
map-class frame-relay HIGH
no frame-relay adaptive-shaping
frame-relay interface-queue priority high
interface Serial4/0
no ip address
encapsulation frame-relay
frame-relay interface-queue priority
!
interface Serial4/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
frame-relay interface-dlci 102
class HIGH
!
interface Serial4/0.103 point-to-point
ip address 172.16.2.1 255.255.255.252
frame-relay interface-dlci 103
class MEDIUM
!
interface Serial4/0.104 point-to-point
ip address 172.16.1.5 255.255.255.252
frame-relay interface-dlci 104
class LOW
!
interface Serial4/0.105 point-to-point
ip address 172.16.2.5 255.255.255.252
frame-relay interface-dlci 105
class NORMAL
!
Assuming that only web traffic and VOIP Traffic is the only traffic that is
passing in my network then Web traffic is given the Medium priority. Also
dedicated Frame Relay PVC is provisioned to transport the delay-sensitive
VoIP traffic on DLCI 102.
Hope that helps for something
Victor.-
-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de Chee
Chew Leong
Enviado el: Lunes, 16 de Octubre de 2006 12:10 a.m.
Para: Cisco certification
Asunto: Re: Frame-relay DLCI priority levels
I am sorry to bring this question up again. I have some problem
undertanding the FR DLCI prioritization as on the example pointed.
1) How can a point-to-point fr interface can have multiple dlci? Must it
be point-to-point interface?
2) Is the traffic split across the dlci automatically according to the its
priority level define in the priority group.
3) How come the priority-group command is applied on the physical
interface? What will happen if serial0 have other subinterface that should
not involve in prioritization?
In PIPQ,
1) Just to understand correctly, there isn't any traffic classification.
As long as the traffic go in to particular dlci, it will have the assign
priority over the other dlci. Is my understanding correct?
Sorry for too many questions.
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_guid
e09186a008007fe83.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
>>>>>>
>>>>>>
>>>>>>
>>>
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:05 ART