ISR 4K NBAR

[LynK]

Here is a fun QoS problem I have run into.

Lets say a router has a shared MPLS + Internet circuit (100/100mbps). Both are going out the same external interface but in VRFs and sub interfaces.

You can't apply the NBAR policy on the parent External interface because it does not see any protocols in the NBAR protocol analyzer (unless this is a bug). This then forces me to apply the service policy on the sub-interfaces.

Would it be safe to apply the QoS policy to both sub-interfaces (100mbps), and have them aggregate?

My fear is that I have 50% allocated for voice + video. It would then use 50% on vrf A sub interface A and 50% on vrf B sub interface B.

Thoughts?

here is my current QoS design. This was however assuming percentages based on a single interface policy. I am not sure if sub-interfaces are aggregates of the parents bandwidth. Or am I really going to have to shape out a specific amount of bandwidth for internet, and a separate share for MPLS (example: 80 mbps for internet, 20 mbps for mpls).

Code Select Expand


class-map match-any REALTIME
match protocol rtp audio
match protocol rtp video
match protocol cisco-phone-audio
match protocol webex-meeting
match protocol webex-app-sharing
match protocol webex-media
match protocol telepresence-media
match protocol sip
match protocol sip-tls
match protocol skinny
match protocol sip
match protocol h323
match protocol rtcp
match protocol telepresence-control
match protocol cisco-phone
match protocol cisco-jabber-audio
match protocol cisco-jabber-video
match protocol attribute category voice-and-video
!
class-map match-any MISSION_CRITICAL
match protocol mgcp
match protocol bgp
match protocol smtp
match protocol vmware-view
match protocol vmware-vmotion
match protocol vmware-vsphere
match protocol radius
match protocol ssh
match protocol attribute category netadmin
!
class-map match-any BUSINESS_CRITICAL
match protocol attribute category consumer-internet
match protocol attribute category consumer-file-sharing
match protocol attribute category browsing
match protocol attribute category email
match protocol http
match protocol https
!
class-map match-any STANDARD
class class-default
!
!
!
!
policy-map QOS
class REALTIME
set dscp ef
priority percent 50
!
class MISSION_CRITICAL
set dscp af41
bandwidth percent 25
!
class BUSINESS_CRITICAL
set dscp af21
bandwidth percent 20
!
class STANDARD
bandwidth percent 5
fair-queue


[wintermute000]

1.) You'd typically employ NBAR ingress on the LAN side and mark there. You wouldn't employ NBAR on egress. Traffic incoming should already be marked EGRESS from WAN sites and preserved by carrier QoS schema.

2.) Typically you'd QoS on physical and the schema would be inherited for all sub-interfaces. Alternatively you COULD put the service policy on sub-interfaces. I'm unsure of the BW behaviour in this case.

3.) Your QoS config looks wrong at first glance - where is the parent and child structure? Without that how is the bandwidth statements going to do anything? Typically you'd shape on the parent interface to 99% of the 'real' circuit speed (as your circuit speed is typically not hte actual interface speed). Then apply the child policy to th default class, and within the child policy you do the per-class per-BW behaviour.

[LynK]

@winter

1) I know about marking on the LAN side (which is what we intend to do, this is all theoretical right now). I actually left out a snippet about the LAN section

2) I know that you typically put on physical, but could put it on sub-interfaces. I am not certain about the BW behavior either.

3) It looks wrong because I'm an idiot and didn't copy and paste everything, just enough to show you guys the policies. Here is the parent snippet:

[deanwebb]

here is the parent snippet:

Where did it go? I can't find it! Oh jeez!

[LynK]

lol... idiot x2:

Code Select Expand


policy-map SHAPE_INTERFACE
class class-default
  shape average 99000000
   service-policy QOS


[LynK]

To add to this, the goal is to not set individual shaping policies on each sub interface. If MPLS wants to use 80Mbps out of 100 let it. I do not want to set it to a maximum of X, that kills the diversity.

What I am worried about is if I set the policy above on both sub interfaces, each link is going to think they have 99mbps capacity, and while QoS may kick in for the internet VRF it will not kick in for the MPLS vrf causing SIP traffic to be dropped over that VRF.


I'm just going to give it a go with marking on ingress, and shaping on physical interface and see how it looks. will keep you updated.

[wintermute000]

look what I found


https://www.cisco.com/c/en/us/td/docs/ios/qos/command/reference/qos_book/qos_a1.html#wp1027485


I've never used this, so test it out


Also this old reference - basically you have to parent/child each subinterface to cause the shaping / queueing to trigger as logical subinterfaces have no concept of bandwidth so effectively you're hard reserving BW per subinetrface which is inefficient coimpared to doing it for the whole available bandwidth on the whole physical interface


https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/10104-qos-subint.html

[LynK]

@Winter,

yeah I read that already. The NBAR policy is working great for outbound. No issues.

My question now is in regards to inbound traffic shaping (think internet). How do you guys shape users to limit their download bandwidth? The only things I can think of is on FW, and possibly working with ISP or running a shaping policy out the router LAN side. The problem with this is you need the limiting to happen where the original circuit shaping is happening else the traffic is already using you internet pipe...

How do you stop 1 user from downloading something and killing your entire circuit. srr does not work because of 10% of a 1G is still too much. QoS only works on access switches for inbound.

[icecream-guy]

@Winter,

yeah I read that already. The NBAR policy is working great for outbound. No issues.

My question now is in regards to inbound traffic shaping (think internet). How do you guys shape users to limit their download bandwidth? The only things I can think of is on FW, and possibly working with ISP or running a shaping policy out the router LAN side. The problem with this is you need the limiting to happen where the original circuit shaping is happening else the traffic is already using you internet pipe...

How do you stop 1 user from downloading something and killing your entire circuit. srr does not work because of 10% of a 1G is still too much. QoS only works on access switches for inbound.

you can't shape inbound,  there is nowhere for the router to put packets.  (in a buffer?  not),  have to shape outbound upstream..


fire the 1 user, make 'em the model for playing nice with the network bandwidth.
there are many tools such as limiting the tcp window size for file transfers.
or crushing users finger with vise grips.

[LynK]

@ristau,

There is nothing the ISP can do? I find it hard to believe that they could not sell that as a service.

[deanwebb]

@ristau,

There is nothing the ISP can do? I find it hard to believe that they could not sell that as a service.

They can now...

[wintermute000]

You get a shaper, it goes inline and shapes both directions.
They're usually tied in with URL filtering and visibility etc. functions, can assign queues and quotas etc.
Bluecoats, exindas, sinefa, to name 3 vendors (WAN op gear can also do it in a pinch but that's using a sports car to tow a boat so to speak)


Cloud proxy services may also have some of this functionality but you'd have to DYOR (Zscaler etc.)

You can do ghetto outbound QoS on your LAN side of your edge router, but obviously that is static configs, no granularity. Ditto with NGFWs but with more functionality than a router (but less than a proper shaper) e.g. I also have customers doing stuff like shaping egress (LAN side) general web browsing (of course that's a NGFW that can classify at L7 properly so it doesn't interfere with business critical internet traffic)