Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Working around NBAR limitation with crypto

I have a 1721 with ADSL WIC, and have a ppp dialer that connects through an ATM VC. For this dialer I have a crypto map for my VPN tunnels. I am running c1700-k9o3sy7-mz.124-9.T.bin - the latest at the time of writing.

In the product configuration guide for NBAR it states:

"You cannot use NBAR to classify output traffic on a WAN link where tunneling or encryption is used. Therefore, you should configure NBAR on other interfaces of the router (such as a LAN link) to perform input classification before the traffic is switched to the WAN link."

I take it this applies to my setup? I want to use NBAR to classify voice and P2P traffic and apply appropriate policy for dequeing out the WAN, using LLQ for voice and delaying/policing the P2P.

Now we come to my question - do I need to apply a service policy to the LAN ingress and perhaps mark packets (changing the DS/TOS field) and then match on those fields on the WAN interface, or is just running NBAR protocol discovery enough? I'm hoping that the router 'remembers' what application type a packet belongs to when it discovers it on the LAN side, for when said packet gets switched to the WAN side and hit the service policy applied to the egress (because this policy uses CBWFQ, and the classes use the 'match protocol' statement exclusively).

Put another way, is everything fine if I only run 'ip nbar protocol-discovery' on my LAN interface (F0/0) and have my one and only service policy (which makes use of classes and NBAR functionality) on the WAN interface?

Secondary question. Should I apply to my 'service policy output' to my dialer interface, or the ATM sub-interface?

Thanks in advance!


Re: Working around NBAR limitation with crypto

NBAR is not configurable on logical interfaces where tunneling or encryption is used. It also is not supported on any physical interface configured with a crypto map. Thus, you cannot use NBAR to classify traffic based on higher-layer packet information such as a URL or Web server hostname for any QoS policy where GRE and/or IPSec are being used. This restriction results from the number of bytes of the packet header that the pre-classify feature saves and then refers. Specifically, QoS preclassification calls an API in IOS before a packet is encapsulated. This API takes a copy of the original packet header information. When the packet eventually hits the egress QoS function, QoS can be applied to the packet based on any of the saved information such as TCP port or real destination IP address.

CreatePlease to create content