WAN QOS Issue : shaper dropping out of map class after reload

Hi All,

I'm having a problem with the QOS policy between sites over Frame-relay. I am using back-to-back WIC-1T.

My config is as follows with the frame-relay map class applie to the subinterface:


class-map match-all VOICE-SIG
 match  dscp cs3  af31
class-map match-all VOICE-RTP
 match  dscp ef

policy-map LLQ
 class VOICE-RTP
    priority 96
 class VOICE-SIG
    bandwidth percent 1
  set dscp cs3
 class class-default
    fair-queue

policy-map SHAPE
 class class-default
    shape average 729600 7296 0
   compress header ip rtp
  service-policy LLQ

map-class frame-relay FRF
 service-policy SHAPE <-------------------------this disappears after reload.
 frame-relay fragment 960
 frame-relay fair-queue

interface Serial0/1/0.1 point-to-point
 description == FR To Branch1-R2
 bandwidth 768
 ip address 177.1.101.1 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 201
  class FRF

The policy seems to work, unitl I reload R1 and then when I look at the map-class the shaper has dropped out?

map-class frame-relay FRF <----------------service-policy gone!
  frame-relay fragment 960
 frame-relay fair-queue

Looks like a bug but has anyone seen it before and whats the workaround please?

Thanks

Comments








  • Are you specifying the direction of the policy?



    --- Original Message ---



    From: "walt" <[email protected]>

    Sent: 21 October 2013 18:23

    To: [email protected]

    Subject: [CCIE Voice] WAN QOS Issue : shaper dropping out of map class after reload





    Hi All,

    I'm having a problem with the QOS policy between sites over Frame-relay. I am using back-to-back WIC-1T.

    My config is as follows with the frame-relay map class applie to the subinterface:



    class-map match-all VOICE-SIG

     match  dscp cs3  af31

    class-map match-all VOICE-RTP

     match  dscp ef

    policy-map LLQ

     class VOICE-RTP

        priority 96

     class VOICE-SIG

        bandwidth percent 1

      set dscp cs3

     class class-default

        fair-queue

    policy-map SHAPE

     class class-default

        shape average 729600 7296 0

       compress header ip rtp

      service-policy LLQ

    map-class frame-relay FRF

     service-policy SHAPE <-------------------------this disappears after reload.

     frame-relay fragment 960

     frame-relay fair-queue

    interface Serial0/1/0.1 point-to-point

     description == FR To Branch1-R2

     bandwidth 768

     ip address 177.1.101.1 255.255.255.0

     snmp trap link-status

     frame-relay interface-dlci 201

      class FRF

    The policy seems to work, unitl I reload R1 and then when I look at the map-class the shaper has dropped out?

    map-class frame-relay FRF <----------------service-policy gone!

      frame-relay fragment 960

     frame-relay fair-queue

    Looks like a bug but has anyone seen it before and whats the workaround please?

    Thanks








    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx



  • Hi thanks for response. Yes there is a typo above. I am applying outbound. Any other ideas?

    Thanks




  • Try removing the frame-relay fair-queue and don't think the Bandwidth command under the point-to-point is required for MQC based Shaping.
     

    From: [email protected]
    To: [email protected]
    Date: Tue, 22 Oct 2013 06:16:16 -0700
    Subject: Re: [CCIE Voice] RE: WAN QOS Issue : shaper dropping out of map class after reload

    Hi thanks for response. Yes there is a typo above. I am applying outbound. Any other ideas?

    Thanks



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • T hanks again but no luck. The fair-queue command is added aautomatially when u add the fragment command. The same commands work fine on the branch router so wondering if its because I have multiplevsub interfaces at hq. Do I need some config on the other subint? 

  • Hi 

    Did some testing
    and it looks like a new “feature” from our beloved Cisco developers.

    Expected behavior
    QoS Command Reference

    http://www.cisco.com/en/US/docs/ios-xml/ios/qos/command/qos-d1.html#wp2000044779

    "However,
    if you enable custom queueing or priority queueing for a qualifying link, it
    overrides fair queueing, effectively disabling it. Additionally, fair queueing
    is automatically disabled if you enable the autonomous or silicon switching
    engine mechanisms."
     

     

    Looks like
    when applying CB queuing, fair-queuing on the physical interface should be
    disabled and this process somehow removes the "no fair-queue" command
    on the Serial interface.

     

    During a reboot the router parses the startup-config
    sequentially, computes the default values for the fair-queue command since the
    command "no fair-queue" is not there to prevent it from doing so and
    moves on.

     

    When it
    reaches the map-class command it rejects the service-policy command with the
    following message:

    DRAM
    configuration is 64 bits wide with parity enabled.

    239K
    bytes of non-volatile configuration memory.

    62720K
    bytes of ATA CompactFlash (Read/Write)

     

    Remove Fair/Custom queueing from main
    interface before

    adding MQC hierarchical policies.

     Dspfarm profile 3 :: Resource provider not
    registered

    SCCP
    operational state bring up is successful.

     

    The service-policy output
    command is rejected (i.e. it is removed from the frame-relay map-class) and the
    router moves on.  End-result :  you could lose the QoS points for not knowing
    this great feature.  

     

    Did anyone find a workaround for this problem? I'm running 12.4(22)T5.

     

    Thanks.

    Ovidiu

     

     

     

  • Update:

     

    Yeah, it’s definitely a bug. Following some pertinent
    remarks from walt I did more tests with the following results:

     

    • A router with the following configuration works
      fine:

     

    LLQ + CB shaping + FRF.12 in map-class
    + class attached to a DLCI in subinterface configuration. The physical
    interface does not have RSVP configured.

     Following a reboot the shaper remains attached
    to the map-class.

     

    • A router with the following configuration does not work correctly after a reboot

     

    LLQ + CB shaping + FRF.12 in map-class
    + class attached to a DLCI in subinterface configuration. The physical
    interface has  “ip rsvp bandwidth”
    configured. During a reboot the service policy is detached from the map-class
    with the error message mentioned in the previous post “Remove Fair/Custom
    queueing from main interface before adding MQC hierarchical policies.”

     

     

    The only difference between the configurations is the”ip rsvp bandwidth” command that is
    applied before the reload.

     

    Following this behavior I asked myself if fair-queue on the
    physical interface is not somehow required for rsvp and it turns out that as
    long as the map-class has frame-relay fair-queue command we’re good to go:

    http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/12-4/rsvp-config-rsvp-for-fr.html#GUID-31902B41-C3DC-4B38-8D49-CA270C5DB512

     

    So this leads me to the following questions:

    Q1 : What should we do in the real lab if the requirement
    states the following? (requirement taken from one of INE’s mock labs):

    a)     
    RSVP between all sites

    b)     
    LLQ between site A and C with fragmentation and
    interleaving

    If we configure the router correctly it will work but if for
    some reason the router reloads before the proctor grades the lab the
    configuration will be incorrect.

    Will the proctor take the time to look in the
    startup-config to see if our configuration is correct? My guess is no, so we're back the original question: what should we do in the real lab to get the points?

    Q2 : is this a know bug ? I have not been able to find anything
    related to this problem. More importantly is there a workaround that does not
    break the requirements in Q1?

     

    Mark, care to pitch in ?

     

    Thanks,

     

    Ovidiu

Sign In or Register to comment.