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?
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...