Showing posts with label Frame Relay. Show all posts
Showing posts with label Frame Relay. Show all posts

Frame Relay Troubleshooting – the Frame Switch

Posted by Network Bulls On Tuesday, February 22, 2011 0 comments

You just cannot assume anything when you sit for your Version 4.0 CCIE R&S Lab Exam. One of the former assumptions we could make with Version 3.x was that our Frame Relay Switch is going to be just fine and dandy. Therefore, if you examined your PVC health (status) and you saw DELETED, you could immediately inspect your Frame Relay map statements, or your frame-relay interface-dlci commands for a typo in the DLCI.
But in this new exam (Troubleshooting section or Configuration section), nothing is off limits from your problem scope. OK, well, to be more accurate, most Layer 1 issues are still indeed out of scope. In fact, in the Troubleshooting section, Layer 1 really cannot be an issue since the devices we are troubleshooting are actually virtual routers. You cannot even run up against a bad cable there! But still, there is a lot more that we can be asked to troubleshoot than in the past. And if you think about the Core Knowledge section, they could even ask Layer 1 troubleshooting-related questions there instead!
In this blog post (dedicated to my current Advanced Troubleshooting Bootcamp Live Class), we will examine Frame Relay troubleshooting where the Frame Relay Switch rears its rather ugly head.
frame
I am going to carefully configure the R1 and R2 interfaces for Frame Relay in this scenario. I am going to “slow down to speed up” in these configurations and make sure they are letter for letter perfect. First, R1 and then R2:
R1:
R1(config)#interface serial 0/1
R1(config-if)#shutdown
R1(config-if)#encapsulation frame-relay
R1(config-if)#no frame-relay inverse-arp
R1(config-if)#ip address 10.20.20.1 255.255.255.0
R1(config-if)#frame-relay map ip 10.20.20.2 102 broadcast
R1(config-if)#no shutdown
R1(config-if)#
...
Mar  2 14:54:33.156: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
R2:
Rack8R2(config)#interface serial0/1
Rack8R2(config-if)#shutdown
Rack8R2(config-if)#encapsulation frame-relay
Rack8R2(config-if)#no frame-relay inverse-arp
Rack8R2(config-if)#ip address 10.20.20.2 255.255.255.0
Rack8R2(config-if)#frame-relay map ip 10.20.20.1 201 broadcast
Rack8R2(config-if)#no shutdown
Rack8R2(config-if)#
...
Mar  2 14:59:23.362: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
So far so good!I am thrilled to see the magic UP/UP system messages and I am ready to rock with a PING test.
Rack8R2#ping 10.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Rack8R2#
Not what I want to see! Let me do some further information gathering:
Rack8R2#show frame-relay pvc

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

 Active     Inactive      Deleted       Static
 Local          0            0            1            0
 Switched       0            0            0            0
 Unused         0            0            0            0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/1
Wait a minute! DELETED???? I triple-checked my DLCI configuration per the diagram. Can I access the device connecting these routers (R3 in my case)? I sure can…let me view the relevant configuration on the device.
Rack8R3#sh run
...
hostname Rack8R3
!
frame-relay switching
!
interface Serial1/2
 no ip address
 encapsulation frame-relay
 clock rate 64000
 frame-relay intf-type dce
!
interface Serial1/3
 no ip address
 encapsulation frame-relay
 clock rate 64000
 frame-relay intf-type dce
...
Rack8R3#
It looks like someone made a nice attempt at the Frame Relay Switch configuration here (note the highlighted commands), but they have forgotten the “static routes” for PVC switching on the device.
Rack8R3(config)#interface serial 1/2
Rack8R3(config-if)#frame-relay route 102 interface serial 1/3 201
Rack8R3(config)#interface serial 1/3
Rack8R3(config-if)#frame-relay route 201 interface serial 1/2 102
Rack8R3(config-if)#
Now, drum roll please, let us try that PING again.
Rack8R2#ping 10.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/61 ms
Rack8R2#
Now that is more like it!!!!!

Labels: ,

PING Thyself in Frame-Relay

Posted by Network Bulls On 0 comments

You might have a request in the Core Knowledge, Troubleshooting, or the Configuration section to have a Cisco router be able to PING its own Frame-Relay IP address. In this blog post, we will make sure we can accomplish this. Here is the topology that we will use:
ping thyself

The first order of business here is to ensure that R5 can PING the remote device of R3.
Rack9R5#ping 173.9.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 173.9.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
Rack9R5#
Excellent! Now let us see if R5 can PING itself. I am hoping this fails or it is going to be my shortest blog post ever! :-p
Rack9R5#ping 173.9.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 173.9.0.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Rack9R5#
OK. As expected, it does not work. But why? Well, let us debug frame-relay packets and see if we can determine why.
Rack9R5#debug frame-relay packet
Frame Relay packet debugging is on
Rack9R5#ping 173.9.0.5          

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 173.9.0.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Rack9R5#
Dec  2 14:05:50.399: Serial0/0/0:Encaps failed--no map entry link 7(IP)
Dec  2 14:05:52.399: Serial0/0/0:Encaps failed--no map entry link 7(IP)
Dec  2 14:05:54.399: Serial0/0/0:Encaps failed--no map entry link 7(IP)
Dec  2 14:05:56.399: Serial0/0/0:Encaps failed--no map entry link 7(IP)
Dec  2 14:05:58.399: Serial0/0/0:Encaps failed--no map entry link 7(IP)
Rack9R5#
There is the answer. Frame-Relay does not know what DLCI to use for this destination IP address. We need to add a Frame-Relay mapping for our own IP address pointing to the DLCI of our neighbor.Let us do that now and then perform our verifications:
Rack9R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack9R5(config)#int s0/0/0
Rack9R5(config-if)#frame map ip 173.9.0.5 503
Rack9R5(config-if)#do sh run int s0/0/0
Building configuration...

Current configuration : 198 bytes
!
interface Serial0/0/0
 ip address 173.9.0.5 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 173.9.0.5 503
 frame-relay map ip 173.9.0.3 503 broadcast
 no frame-relay inverse-arp
end

Rack9R5(config-if)#do ping 173.9.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 173.9.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/118/124 ms
Would I engage in this extra configuration unless I was asked to do so in the exam? No way…but at least now we fully understand this under-documented little nuance.

Labels: ,

That Pesky Frame-Relay Interface-DLCI Command!

Posted by Network Bulls On Friday, February 4, 2011 0 comments

Can you please help me understand use of Frame-Relay Interface-dlci command. It’s getting mysterious for me day by day as I am studying FR. The reason being is I earlier thought that I should only use this command on FR point to point subinterface. As Point to Point subinterface don’t allow us to put Frame relay map statements. Also in such case Inverse arp should be turned off. But while I was going through Cisco’s FR documentation on website I saw that in almost all examples they used interface dlci command on interface not on sub interface and also without turning off inverse arp. So the question now is if inverse arp is turned on then as per my understanding we need not to put this command as it will discover dlci settings through lmi signals automatically.
Kindly explain Interface Dlci command to me…
When I saw this post, I got to thinking a little bit.  Mostly about the fact that the interface-dlci appears to be a much more misunderstood command than I ever gave it credit for!  (poor thing…)
The quick answer is that the “frame-relay inteface-dlci” command simply says “This DLCI goes here” to the router.
On a physical interface, this command is largely irrelevant (more in a minute) because ALL DLCIs are assigned to the physical interface by default.  If you are ever interested, concerned or otherwise bored, just check out “show frame-relay pvc” and you will see where they are assigned.
So in the case of sub-interfaces, there is no automagical assignment of DLCI numbers.  Even if your subinterface number and DLCI number are the same.  That’s just a sign of being anal-retentive (or as we consultants call it, “good at documentation”) or a little OCD.  But you can technically have DLCI 100 on subinterface Serial 0/0.223.  Kinda strange, but perfectly workable!
So whenever you have a subinterface, you need to do SOMETHING to tell the router “this DLCI goes here”.
So now let’s look at the next portion:  Mapping.  Layer3 to Layer2 mapping in particular.   We can learn about L3-L2 mapping via Inverse ARP.  This is on by default, but frowned upon in the CCIE Realm!  “Show frame-relay map” will let you know if you have learned any addresses dynamically or not.
So if we DID allow Inverse ARP, whether our subinterfaces were point-to-point or multipoint ones, we COULD just use the “frame-relay interface-dlci” command and nothing else.  (Yes, I know inverse ARP requests are not sent by default on subinterfaces, but responses still are.  Watch your debugs!)  :)
So the Interface-DLCI command assigned the PVC to a subinterface.  Inverse ARP then took care of the mapping.  What if we aren’t allowed to use Inverse ARP?  Like for the CCIE lab?  Ok, what are our options?  Well, the “frame-relay map” command is the most obvious and well known.  That works very well.  The “frame-relay map” command both assigned L3-L2 mapping AND says “this DLCI goes here” all in one command!
Unless of course you are on a point-to-point subinterface.  As you pointed out, you can’t use the map command there!  But that’s ok, it’s not needed anyway!  Point-to-point links have a different way of thinking.  They view the world as “If it’s not my address it must be yours” and sends things out.
So that covers our two primary issues with PVC operations in Frame Relay.  #1 is assigning the DLCI to an interface (no magic).  #2 is the L3-L2 mapping to make IP actually work!
The last part I want to add (re: my “more in a minute” above) was that the “frame-relay inteface-dlci” command also serves another purpose which sometimes gets confusing in terms of where we just got through with things!
So where we left things with “frame-relay interface-dlci” commands:
1.  Definitely used on point-to-point subinterfaces
2.  Can be used on multipoint subinterfaces if Inverse ARP works
3.  Not used on physical interfaces because all DLCIs belong there by default.
Now, just to mess with that logic a bit.  When studying frame-relay, and particularly by the time you get into QoS configurations you will become familiar with frame-relay map-classes.  Map classes can be assigned to an interface or subinterface without any problem.  When this occurs, the information in the map-class gets appled to EVERY DLCI on that interface or subinterface.
So what happens if you have different QoS parameters for different PVCs that just happen to be on the same interface/subinterface?  Hmmmm…  Well, in comes the “frame-relay inteface-dlci” command again!  See, it really IS a cool command!
The “frame-relay map” command does not have any parameter for adding a map-class.  After you hit enter on your “frame-relay interface-dlci” command though, you’ll get a new sub-command prompt.  Try using “?” here.  You’ll see that you have the opportunity to specify a separate map-class for each and every DLCI that you have.
So if you see “frame-relay interface-dlci” commands on a physical interface.  Or if you see them AND a “frame-relay map” command under a multipoint subinterface, this is the reason why.  If you use the “frame-relay inteface-dlci” command AND the “frame-relay map” command for the same PVC, you will need to make sure the “frame-relay map” command comes first.  Otherwise the router will express its displeasure!
So there are some very simple, but also some very powerful things the little “frame-relay interface-dlci” command does.  Hopefully that will help you take some of the mystery out of things!

Labels: ,

Understanding Frame Relay Mappings to 0.0.0.0

Posted by Network Bulls On Thursday, February 3, 2011 0 comments

I ran into these nasty frame relay mappings during an initial lab set-up and was wondering why they are there, (even with inverse-arp disabled), and what they are actually doing. I was able to remove them only after writing my configuration to memory, and then performing a reload of the router.
Router(config-if)#do show frame map
Serial0/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10)
              broadcast,
              CISCO, status defined, inactive
Serial0/0 (up): ip 0.0.0.0 dlci 105(0x69,0x1890)
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 0.0.0.0 dlci 104(0x68,0x1880)
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 0.0.0.0 dlci 103(0x67,0x1870)
              broadcast,
              CISCO, status defined, active
This is actually an error relating to AutoInstall over Frame Relay. When the router boots up and does not have a configuration file saved in NVRAM, it attempts to run autoinstall to automatically find an IP address and download a config. The first thing the router does is to detect the encapsulation on its WAN interfaces, which in this case is Frame Relay. Once the router finds that it’s running Frame Relay, it attempts to send a config request via TFTP. In order to do this it needs an IP address, so it sends a BOOTP request out all DLCIs. Since the router doesn’t know what the unicast IP addresses are on the other ends of the circuits, it creates IPv4 mappings to 0.0.0.0 for all circuits and includes the “broadcast” keyword on them. This allows the router to encapsulate the BOOTP request out all DLCIs.
If you haven’t actually configured IP helper-address or a BOOTP server, the operation will fail. The result of this that we see is that when Frame Relay is re-enabled on the interfaces the mappings to 0.0.0.0 reappear. In some versions of IOS this can be fixed by removing Frame Relay and re-applying it, for example:
router#config t router(config)#interface s0/0 router(config-if)#encapsulation ppp router(config-if)#encapsulation frame-relay router(config-if)#end router# In most versions however this does not work. Therefore the way to fix this is just to have the router not do autoinstall on bootup. Since the router does autoinstall because it doesn’t have a config saved in memory, the only way to 100% fix it is to save your config to NVRAM (wr m), and to reload.
 

Labels: ,

Resolving Reachability Between Spokes in a Hub and Spoke Frame-Relay Network

Posted by Network Bulls On Wednesday, February 2, 2011 0 comments

A common question that I get from students in class is what are the options to resolve spoke to spoke reachability in a Frame-Relay network. Below are your “standard” choices in order of preference:
1) Use point-to-point subinterfaces on the spokes.  This option is preferred as all IP addresses on the subnet will automatically be mapped to the DLCI that is bound to the subinterface.
2) Multipoint interfaces (physical or multipoint subinterfaces) on the spokes with Frame-Relay mappings pointing to the hub’s DLCI to reach the other spokes.
3) Multipoint interfaces on the spokes along with using the OSPF point-to-multipoint network type on all routers on the subnet. Each end point will advertise out a /32 and this advertisement will be relayed to the other spokes by the hub. This is exactly what the OSPF point-to-multipoint network type was designed for (full layer 3 reachability in a network that doesn’t have full layer 2 connectivity.
4) Use PPP over Frame-Relay (PPPoFR). By using PPPoFR IP will now be running over PPP and not directly over Frame-Relay. This means that IP sees everything as point-to-point links and no layer 3 to layer 2 mappings are needed.
5) Static /32 routes on the spokes point to the hub to reach the other spokes. Not a pretty solution but it will resolve the reachability issue.

Labels: ,

Frame Relay Traffic Shaping with GTS

Posted by Network Bulls On 0 comments

As first and very basic option, you may use Generic Traffic Shaping to implement FRTS. This is a common technique, not unique to Frame-Relay, with the following properties:
- Configured by using traffic-shape interface command
- As with standard GTS, internal shaper queue is basic WFQ
- Configured per inteface/subinteface (no PVC granularity)
- GTS may adapt to BECNs & reflect FECNs (BECN received at any interface/subinteface PVC will cause shaper rate to throttle back to minCIR)
- FECN reflection activates sending BECNs in responce to incoming FECN frames. Note, that FECN/BECN responce requires provider to mark frames with FECN/BECN bits
- You can configure Fancy-Queueing (WFQ/PQ/CQ) at physical interface level with GTS.
Example:
!
! Physical Interface, fancy-queueing may apply here
!

interface Serial 0/0/0:0
 no ip address
 encapsulation frame-relay
 fair-queue

!
! Subinterface, apply GTS here
!

interface Serial0/0/0:0.1 point-to-point
 ip address 177.0.112.1 255.255.255.0
 !
 ! Shaping rate
 !
 traffic-shape rate 512000
 !
 ! "MinCIR", adapt to BECNs
 !
 traffic-shape adaptive 256000
 !
 ! Reflect FECNs as BECNs
 !
 traffic-shape fecn-adapt
 frame-relay interface-dlci 112
Verification:
Rack1R1#show traffic-shape 

Interface   Se0/0/0:0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
-             512000    3200   12800     12800     25        1600      BECN

Rack1R1#show traffic-shape statistics
                  Acc. Queue Packets   Bytes     Packets   Bytes     Shaping
I/F               List Depth                     Delayed   Delayed   Active
Se0/0/0:0.1             0     157       10500     0         0         no

Rack1R1#show traffic-shape queue
Traffic queued in shaping queue on Serial0/0/0:0.1
  Queueing strategy: weighted fair
  Queueing Stats: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/0/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 512 kilobits/sec

Labels: ,

Legacy Frame-Relay Traffic Shaping

Posted by Network Bulls On 0 comments

This is the most well-known FRTS method, which has been available for quite a while on Cisco routers. It is now being outdated by MQC configurations.
The key characteristic is that all settings are configured under map-class command mode, and later are applied to a particular set PVCs. The
same configuration concept was used for legacy ATM configuration mode (map-class atm).
Legacy FRTS has the following characteristics:
- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it’s CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)
Example: Shape PVC to 384Kbps with minimal Tc (10ms) and WFQ as interface queue
map-class frame-relay SHAPE_384K
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 !
 ! Adaptive shaping: respond to BECNs and interface congestion
 !
 frame-relay adaptive-shaping becn
 frame-relay adaptive-shaping interface-congestion
 !
 ! Per-VC fancy-queueing
 !
 frame-relay fair-queue
!
interface Serial 0/0/0:0
 frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
 ip address 177.0.112.1 255.255.255.0
 frame-relay interface-dlci 112
  class SHAPE_384K
Verification: Check FRTS settings for the configured PVC
Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

  cir 384000    bc 3840      be 0         byte limit 480    interval 10   <------ Shaping parameters
  mincir 192000    byte increment 480   Adaptive Shaping BECN and IF_CONG <---- Adaptive Shaping enabled
  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair  <---- WFQ is the per-VC queue
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0
The other PVC, with no class configured, has CIR set to 56Kbps and uses FIFO as per-VC queue:
Rack1R1#show frame-relay pvc 113

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2

  cir 56000     bc 7000      be 0         byte limit 875    interval 125 <---- CIR=56K
  mincir 28000     byte increment 875   Adaptive Shaping none
  pkts 74        bytes 5157      pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo <------------------ FIFO
  Output queue 0/40, 0 drop, 0 dequeued
Check the physical interface queue:
Rack1R1#show interfaces serial 0/0/0:0 | inc Queue
  Queueing strategy: fifo
- Interface queue could be changed to PIPQ (PVCs are assigned to 4 pririty groups, with PQ being physical interface queue)
- PIPQ stands for PVC Interface Priority queueing
Example: Map PVC 112 traffic to high interface queue, and PVC 113 to low interface queue, with WFQ being per-VC queueing
!
! Shape to 384K an assign to high interface level queue
!
map-class frame-relay SHAPE_384K_HIGH
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 !
 ! Per-VC fancy-queueing
 !
 frame-relay fair-queue
 frame-relay interface-queue priority high

!
! Shape to 256k an assign to low interface level queue
!
map-class frame-relay SHAPE_256K_LOW
 frame-relay cir 256000
 frame-relay bc 2560
 frame-relay be 0
 !
 ! Per-VC fancy-queueing
 !
 frame-relay fair-queue
 frame-relay interface-queue priority low

!
! Enable PIPQ as interface queueing strategy
!
interface Serial 0/0/0:0
 frame-relay traffic-shaping
 frame-relay interface-queue priority
!
interface Serial 0/0/0:0.1
 ip address 177.0.112.1 255.255.255.0
 frame-relay interface-dlci 112
  class SHAPE_384K_HIGH
!
interface Serial 0/0/0:0.2
 ip address 177.0.113.1 255.255.255.0
 frame-relay interface-dlci 113
  class SHAPE_256K_LOW
Verfication: Check PVC interface-level priorities
Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1

  cir 384000    bc 3840      be 0         byte limit 480    interval 10
  mincir 192000    byte increment 480   Adaptive Shaping none
  pkts 1687      bytes 113543    pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0
  priority high
  ^^^^^^^^^^^^^

Rack1R1#show frame-relay pvc 113

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2

  cir 256000    bc 2560      be 0         byte limit 320    interval 10
  mincir 128000    byte increment 320   Adaptive Shaping none
  pkts 1137      bytes 79691     pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0
  priority low
  ^^^^^^^^^^^^
Verify interface-level queue:
Rack1R1#show interfaces serial 0/0/0:0 | inc (Output|high)
  Output queue (queue priority: size/max/drops):
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0
- With FRF.12 fragmentation configured per any PVC, physical interface queue is changed to dual-FIFO
- This is due to the fact that fragmentation is ineffective without interleaving
- Fragment size is calculated based on physical interface speed to allow minimum serialization delay
Example: Enable FRF.12 fragmentation for PVC DLCI 112 and physical interface speed 512Kbps
!
! PVC shaped to 384Kbps, with physical interface speed 512Kbps
!
map-class frame-relay SHAPE_384K_FRF12
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 !
 ! Per-VC fancy-queueing
 !
 frame-relay fair-queue

 !
 ! Enable FRF.12 per VC. Fragment size = 512Kbps*0,01/8 = 640 bytes
 !
 frame-relay fragment 640
!
!
!
interface Serial 0/0/0:0
 frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
 ip address 177.0.112.1 255.255.255.0
 frame-relay interface-dlci 112
  class SHAPE_384K_FRF12
Verfication: Check PVC settings
Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1

  fragment type end-to-end fragment size 640
  cir 384000    bc   3840      be 0         limit 480    interval 10
  mincir 192000    byte increment 480   BECN response no  IF_CONG no
  frags 1999      bytes 135126    frags delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0
Look at physical interface queue:
Rack1R1#show interfaces serial 0/0/0:0 | inc Queu|Output q
  Queueing strategy: dual fifo
  Output queue: high size/max/dropped 0/256/0
  Output queue: 0/128 (size/max)
- You can map up to 4 priority queues to 4 different VCs (inverse PIPQ)
- This scenario usually implies multiple PVCs running between two sites (e.g. PVC for voice and PVC for data)
Example: Map voice packets to high interface-level priority queue and send them over PVC 112
!
! Voice bearer
!
access-list 101 permit udp any any range 16384 32767

!
! Simple priority list to classify voice bearer to high queue
!
priority-list 1 protocol ip high list 101

interface Serial 0/0/0:0
 ip address 177.1.0.1 255.255.255.0
 !
 ! We apply the priority group twice: first to implement queueing
 !
 priority-group 1
 !
 ! Next to map priority levels to DLCIs
 !
 frame-relay priority-dlci-group 1 112 112 113 113
Verfication:
Rack1R1#show queueing interface serial 0/0/0:0
Interface Serial0/0/0:0 queueing strategy: priority

Output queue utilization (queue/count)
 high/217 medium/0 normal/1104 low/55 

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

  pvc create time 3d01h, last time pvc status changed 3d01h
  Priority DLCI Group 1, DLCI 112 (HIGH), DLCI 112 (MEDIUM)
  DLCI 113 (NORMAL), DLCI 113 (LOW)
- You can change per-VC queue to CBWFQ/LLQ, and still shape with FRTS
- Note that available bandwidth will be calculated from minCIR value, which is CIR/2 by default
Example: Implement CBWFQ Per-VC
!
! Classify voice using NBAR
!
class-map VOICE
 match protocol rtp

!
! Simple LLQ
!
policy-map CBWFQ
 class VOICE
  priority 64
 class class-default
  bandwidth 64

!
! Use CBWFQ as queueing strategy
! Note that MinCIR = 384/2=192Kbps
!
map-class frame-relay SHAPE_384K_CBWFQ
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 service-policy output CBWFQ
!
!
!
interface Serial 0/0/0:0
 frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
 ip address 177.0.112.1 255.255.255.0
 frame-relay interface-dlci 112
  class SHAPE_384K_CBWFQ
Verfication: Check PVC queueing strategy
Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

  cir 384000    bc 3840      be 0         byte limit 480    interval 10
  mincir 192000    byte increment 480   Adaptive Shaping none
  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  service policy CBWFQ
 Serial0/0/0:0: DLCI 112 -

  Service-policy output: CBWFQ

    Class-map: VOICE (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol rtp
      Queueing
        Strict Priority
        Output Queue: Conversation 40
        Bandwidth 64 (kbps) Burst 1600 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      32 packets, 2560 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Output Queue: Conversation 41
        Bandwidth 128 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
  Output queue size 0/max total 600/drops 0
To verify that only MinCIR of bandwidth is allocated to CBWFQ under map-class do the following:
Rack1R1(config)#policy-map CBWFQ
Rack1R1(config-pmap)# class VOICE
Rack1R1(config-pmap-c)#  priority 64
Rack1R1(config-pmap-c)# class class-default
Rack1R1(config-pmap-c)#  bandwidth 192
I/f Serial0/0/0:0 DLCI 112 Class class-default requested bandwidth 192 (kbps) Only 128 (kbps) available

Labels: ,