I just tried it and I got the dual-fifo by applying the frf.12 to the interface.
I just asked him again. I was mistaken. Enabling frame-relay traffic-shaping brings up PVC priority, not dual-fifo. ""Steven A. Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I didn't get dual-fifo on my serial, with either a frf.12 nor frame-relay > traffic-shaping and I have 12.2.6a. I have seen dual-fifo though > > STeve > ""John Neiberger"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > I'll make it easy on you. :-) Take a look at this output: > > > > RNRTH#sho run int s0/0 > > Building configuration... > > > > Current configuration : 244 bytes > > ! > > interface Serial0/0 > > no ip address > > encapsulation frame-relay > > no ip mroute-cache > > tx-ring-limit 14 > > tx-queue-limit 14 > > no fair-queue > > frame-relay traffic-shaping > > end > > > > RNRTH#sho int s0/0 > > Serial0/0 is up, line protocol is up > > Hardware is PowerQUICC Serial > > Backup interface Async65, failure delay 10 sec, secondary disable > > delay 60 sec, > > kickin load not set, kickout load not set > > MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, > > reliability 255/255, txload 21/255, rxload 22/255 > > Encapsulation FRAME-RELAY, loopback not set > > Keepalive set (10 sec) > > LMI enq sent 25752, LMI stat recvd 25752, 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 179841/0, interface > > broadcasts 166963 > > Last input 00:00:00, output 00:00:00, output hang never > > Last clearing of "show interface" counters 2d23h > > Queueing strategy: fifo > > Output queue 0/40, 851 drops; input queue 0/75, 0 drops > > 5 minute input rate 137000 bits/sec, 124 packets/sec > > 5 minute output rate 133000 bits/sec, 125 packets/sec > > 21463756 packets input, 2759646235 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 > > 21591969 packets output, 2815036977 bytes, 0 underruns > > 0 output errors, 0 collisions, 0 interface resets > > 0 output buffer failures, 0 output buffers swapped out > > 0 carrier transitions > > DCD=up DSR=up DTR=up RTS=up CTS=up > > > > RNRTH# > > > > > > This is with 12.2(3) code, as I mentioned before. During testing, if I > > turned on FRF, the Queueing strategy would change to dual FIFO. Without > > FRF, it remains as a single FIFO queue. > > > > John > > > > >>> "Steven A. Ridder" 1/28/02 3:23:32 PM > > >>> > > I had my weekly meeting with Cisco, and according to them, it does. > > Now I'm > > going to have to do it for myself to see. I'll let you know. > > ""John Neiberger"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > I don't think this is entirely true, but it might depend on the > > software > > > release. We're using 12.2(3) and you definitely have to turn on FRF > > to > > > get the dual FIFO queue; FRTS alone doesn't do it. We have several > > > routers using FRTS with no fragmentation and they only have a single > > > FIFO queue. When I did some testing with this, adding FRF created > > the > > > dual FIFO queue but then our voice calls sounded worse, even though > > we > > > weren't actually fragmenting packets! > > > > > > Weird. Oh well, we've canned our VoIP project anyway. At the > > moment > > > it just isn't feasible, and no, it doesn't have a feasible > > successor, > > > either. :-) > > > > > > John > > > > > > >>> "Steven A. Ridder" 1/28/02 2:20:01 PM > > > >>> > > > Fragmenting above a serialization problematic size doesn't create > > the > > > dual-FIFO queue as certain CCO pages say. It's the frame-relay > > > traffic-shaping command that does. > > > ""Steven A. Ridder"" wrote in message > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > It seems way off. You don't frag a packet above the MTU. As for > > > the > > > subnet > > > > mask as an IP, I can't imagine the router taking it. Why can't he > > > put the > > > > real IP in there? It's been a while since I've seen a customer do > > > FRF.11 > > > C, > > > > though. I'd do his config right and also add the map classes to > > > both > > > > routers. Furthermore, unless he has about 60 or so calls going > > > across, > > > I'd > > > > reduce the reserved BW from 720K to a more reasonable number. > > > > > > > > > > > > ""Erich Kuehn"" wrote in message > > > > news:[EMAIL PROTECTED]... > > > > > I have a customer that we provide frame-relay service to. He is > > > trying > > > to > > > > do > > > > > VoIP over Frame-Relay, while I have quite a bit of experience > > with > > > IP > > > and > > > > > Frame-Relay, once you put voice into it I get lost. > > > > > > > > > > His problem is that if his circuit goes down at location A, Once > > > Loc B > > > > comes > > > > > back up (to my frame-relay switch) Loc A will not come back up. > > The > > > only > > > > way > > > > > to force Loc A back up is to shut the interface on the > > frame-switch > > > to > > > > which > > > > > Loc A connect and then open it back up. Strange I know. He is > > > running > > > > > similar routers at both locations (3660's on 12.2xt code) and > > the > > > config > > > > are > > > > > nearly identical. With exception > > > > > > > > > > At Loc B under the serial subinterface he has > > > > > > > > > > frame-relay inte.5 255.255.255.252 > > > > > > > > > > Never seen this can anyone explain??? > > > > > > > > > > He also has this in his config at both Loc A and B > > > > > > > > > > Map-class Frame-relay VoIP_FR > > > > > frame-relay fragment 1600 > > > > > frame-relay ip rtp priotity 16384 16383 720 > > > > > no frame-relay adaptive-shaping > > > > > frame-relay fair-queue > > > > > > > > > > At Loc A he makes reference to the map-class under the serial > > subif > > > at > > > Loc > > > > B > > > > > he does not. > > > > > > > > > > Anyone with some input?? > > > > > > > > > > Thanks > > > > > > > > > > > > > > > Erich Kuehn > > > > > Network Engineer > > > > > Backbone Communications Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=33516&t=32968 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
