[c-nsp] FR and QoS

[Rodney Dunn]

For the record.  I have filed:

CSCsa47396
Externally found moderate defect: New (N)
Request the ability to specifiy frame-relay fragment size via MQC

with a goal of making the CLI a bit more simple when
doing MQC with FR and fragmentation by moving the
fragment parameters to the parent policy.

Before the change the configuration looks like this:

policy-map llq
 class voice
   priority percent 2
policy-map shape
 class class-default
   shape average 8000 32 32
  service-policy llq

interface Serial3/0/0/8:1.1 point-to-point
 ip address 1.1.1.1 255.255.255.0
 frame-relay interface-dlci 100   
  class fragment

map-class frame-relay fragment
 no frame-relay adaptive-shaping
 service-policy output shape
 frame-relay fragment 80


The request is to move the fragment configuration to the parent policy so now the configuration
would be much simpler and reduced to:

policy-map llq
 class voice
   priority percent 2
policy-map shape
 class class-default
   shape average 8000 32 32
   frame-relay fragment 80
  service-policy llq

interface Serial3/0/0/8:1.1 point-to-point
 ip address 1.1.1.1 255.255.255.0
 service-policy output shape
 frame-relay interface-dlci 100   


or something along those lines. This makes sense to me at least
since the fragment size is directly related to the shape value.

If you use this and would like
to see it in a similar fashion take a second and open a TAC
case and ask them to attach your case to this bug.

Rodney



On Thu, Dec 09, 2004 at 12:21:48PM -0500, Rodney Dunn wrote:
> > 
> > Do you mean the config above, though, or this one:
> > 
> > >> interface (atm|frame) x/y.z
> > >>  service-policy out shape-and-queue
> > >>  (pvc|frame-relay interface-dlci)
> > 
> > Note the indentation - one's got the service policy attached to the
> > interface-dlci, one's got it attached to the subinterface.
> 
> Sorry, I should have typed it in a router to get the order.
> 
> I tried it on a 75xx running some late 12.0S code and with
> FR it will let me put the hierarchical policy on the subint
> and not under the interface-dlci submode.
> 
> W2N-4.4-7513b#sh run int se 3/0/0/8:1.1
> Building configuration...
> 
> Current configuration : 111 bytes
> !
> interface Serial3/0/0/8:1.1 point-to-point
>  no ip directed-broadcast
>  frame-relay interface-dlci 100   
> end
> 
> W2N-4.4-7513b#confi t
> Enter configuration commands, one per line.  End with CNTL/Z.
> W2N-4.4-7513b(config)#interface Serial3/0/0/8:1.1 point-to-point
> W2N-4.4-7513b(config-subif)# frame-relay interface-dlci 100   
> W2N-4.4-7513b(config-fr-dlci)#service-policy out shape                  
> W2N-4.4-7513b(config-subif)#do sh run int se 3/0/0/8:1.1
> Building configuration...
> 
> Current configuration : 140 bytes
> !
> interface Serial3/0/0/8:1.1 point-to-point
>  no ip directed-broadcast
>  service-policy output shape
>  frame-relay interface-dlci 100   
> end
> 
> W2N-4.4-7513b(config-subif)#
> 
> Notice how it kicked me back to subif mode and applied the policy
> there.
> 
> 
> Then I tried ATM:
> 
> W2N-4.4-7513b(config-subif)#int atm 3/1/0.1
> W2N-4.4-7513b(config-subif)#service-policy output shape
> W2N-4.4-7513b(config-subif)#do sh run int atm 3/1/0.1
> Building configuration...
> 
> Current configuration : 167 bytes
> !
> interface ATM3/1/0.1 point-to-point
>  mtu 1500
>  no ip directed-broadcast
>  service-policy output shape
>  no atm enable-ilmi-trap
>  pvc 1/1 
>   vbr-nrt 200 200 10
>  !
> end
> 
> W2N-4.4-7513b(config-subif)#interface ATM3/1/0.1 point-to-point
> W2N-4.4-7513b(config-subif)#no  service-policy output shape
> W2N-4.4-7513b(config-subif)# pvc 1/1 
> W2N-4.4-7513b(config-if-atm-vc)#service-policy output shape
> W2N-4.4-7513b(config-if-atm-vc)#do sh run int atm 3/1/0.1
> Building configuration...
> 
> Current configuration : 165 bytes
> !
> interface ATM3/1/0.1 point-to-point
>  mtu 1500
>  no ip directed-broadcast
>  no atm enable-ilmi-trap
>  pvc 1/1 
>   vbr-nrt 200 200 10
>   service-policy out shape
>  !
> end
> 
> W2N-4.4-7513b(config-if-atm-vc)#
> 
> So with ATM it let me put it either under the subint or
> under the PVC.
> 
> My guess is this would be because how do you handle it when
> you have multiple PVC's under the same ATM subint with
> different rates.  You would need the ability to apply
> a policy per PVC in that configuration.
> 
> This was on a 75xx with dCEF on.
> 
> My policy was:
> 
>   Policy Map shape
>     Class class-default
>       Average Rate Traffic Shaping
>       cir 8000 (bps) bc 32 (bits) be 32 (bits)
>       service-policy llq
>   Policy Map llq
>     Class voice
>       priority 2 (%)
> 
> Rodney
> 
> 
> > 
> > Or does it, in fact, not matter?
> > 
> > > The goal of MQC is to try and make it transparent
> > > to the underlying hardware implementation.  It's
> > > not perfect but it's much better than it was before.
> > 
> > *Totally* agree - don't get me wrong, MQC is great, and a huge improvement
> > trying to hack together CAR, FRTS etc to get to where you want to be.  I've
> > just been bitten by some rather annoying failure cases.
> > 
> > >> interface (atm|frame) x/y.z
> > >>  service-policy out shape-and-queue
> > >>  (pvc|frame-relay interface-dlci)
> > >
> > > I'm not sure what you mean here but if I'm reading
> > > it right that's exactly how you should configure
> > > it.  If it doesn't work it's a bug.
> > 
> > OK, thanks, if that syntax is now supposed to work pretty much everywhere,
> > I'll look more at upgrades (and worst case TAC cases) when we hit the
> > non-workers, rather than finding the work-arounds.
> > 
> > Regards,
> > Tim.
> > 
> > --
> > ____________   Tim Franklin                 e: tim at colt.net
> > \C/\O/\L/\T/   Product Engineering Manager  w: www.colt.net
> >  V  V  V  V    Managed Data Services        t: +44 20 7863 5714
> >                                             f: +44 20 7863 5876