PfR:Solutions:NBAR2

From DocWiki

Jump to: navigation, search

Pfr-banner-solutions.png



PfR NBAR2 Based Application Control


Navigation


Contents




Problem Statement

While the current version of Performance Routing (PfRv2) supports Application Network Based Application Recognition (NBAR) - Cisco's Deep Packet inspection engine - it only supports a very small subset of all application supported in the newer version NBAR2. Therefore it is recommended to use NBAR2 with QoS on ingress to mark the DSCP and then re-use the DSCP value within PfR to define the policies.

As a summary, the following steps are used here:

  • Mark the traffic on ingress on all BR internal interfaces. Classification is based on NBAR2, NBAR2 is enabled with a match protocol <name> in the class-map.
  • Define DSCP based learn-list on the Master Controller (MC)
  • Define PfR DSCP based Policies on the Master Controller (MC)


Using NBAR2 with QoS on ingress

To mark the DSCP value on ingress based on NBAR2, a QoS service-policy is applied on all internal interfaces on the Border Router. An example would be:

class-map match-all marking-video
 match protocol rtp video 
class-map match-all marking-voice
 match protocol rtp audio 
class-map match-all marking-critical
 match protocol exchange
!
policy-map marking-policy
 class marking-voice
  set dscp ef
 class marking-video
  set dscp af41
 class marking-critical
  set dscp af21
!
interface GigabitEthernet0/0.40
 description == LAN ==
 service-policy input marking-policy
!
 


Configuration on the Border Router

NetFlow and QoS

When PfR is enabled on a Border Router (BR), Traditional NetFlow (TNF) is activated by default:

  • on ingress on the internal interfaces
  • and on egress on external interfaces.

Traditional NetFlow is used to learn the traffic and also to collect the performance measurements in PfR.


The objective is to be able to learn the traffic and classify this traffic into learn-lists (groups of Traffic Classes) based on the DSCP value. NBAR2 is used here within a policy-map/class-map on ingress on the Border Router.

But by default NetFlow is used before QoS marking on the feature path on ingress and therefore will not get the remarked DSCP value when DSCP re-marking is done in ingress on the Border Router. That means the default behavior of NetFlow with PfR has to be changed when QoS marking is applied on the BR internal interfaces.

  • This is done by default on IOS-XE starting from XE 3.9 (ASR1k and 4451-X)
  • This needs to be manually configured on IOS (ISR-G2)


Configuration on ISR-G2

When QoS is applied on ingress on the BR to mark the traffic, the following configuration should be applied on the BR:

pfr border
 no netflow
!
interface GigabitEthernet0/1
 description -- WAN –
 ip flow ingress
 ip flow egress
!


Configuration on the Master Controller

All packets are remarked on ingress with a specific DSCP value and PfR will make use of the DSCP to apply policies on Traffic Classes. A recommended configuration is described in the Enterprise WAN solution guide.


Conclusion

Deep Packet Inspection (NABR2) and Performance Routing (PfR) can be used together to provide a more flexible and powerful definition of application policies. The integrated version of NBAR in the current PfR only support a small subset of all applications currently supported in NBAR2, and it is therefore recommended to use NBAR2 and QoS to mark the DSCP value and then define DSCP based policies in Performance Routing.


Rating: 0.0/5 (0 votes cast)

Personal tools