From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Sat Sep 30 2006 - 13:30:12 ART
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 >
-- Petr Lapukhov, CCIE #16379 petr@internetworkexpert.com
Internetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:41 ART