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

PBR and service-policy on the same interface with 4948

I am researching to find a solution to allow monitoring (ideally via SNMP) of bandwidth/traffic per QoS class while at the same time having PBR configured on the interface. The Cisco QoS mib offers snmp oids to monitor based on a service-policy on the interface, however I can't find a way to have the service-policy configured at the same time as PBR - can anyone confirm whether PBR and service-policy are supported simultaneously on the same 4948 switch interface? I am also keen for suggestions on an alternative solution - eg PBR can be used to do qos but how can bandwidth/class data be gathered for PBR - I couldn't find any mibs for PBR for the 4948.




Re: PBR and service-policy on the same interface with 4948

For PBR, the following are not supported:

- Matching cannot be performed on packet lengths

- IP precedence, TOS, and QoS group are fixed

- ACL or route-map statistics cannot be updated

For more details please find the below link:

Hall of Fame Super Silver

Re: PBR and service-policy on the same interface with 4948

Hello David,

are you using PBR for marking traffic only or do you change the next hop ?

if you use PBR only for marking you can configure a service policy that can do the same using the police action with the right actions.

So you could use the MIBs for Class based QoS.

If instead you need to modify routing of incoming packets this requires PBR but in this case you cannot at the same time mark the traffic and change the next hop, multiple set actions are allowed inside a single route-map block but not on this platform.

On a device like 4948 PBR is implemented by creating an ad hoc entry on the TCAM table.

So could be an idea to monitor via SNMP the TCAM counters for each entry and you could get the statistics you want.

In this second case I would investigate this possibility.

See the following:

Understanding PBR Flow Switching

The Catalyst 4500 switching engine supports matching a "set next-hop" route-map action with a packet on a permit ACL. All other route-map actions, as well as matches of deny ACLs, are supported by a flow switching model. In this model, the first packet on a flow that matches a route-map is delivered to the software for forwarding. Software determines the correct destination for the packet and installs an entry into the TCAM so that future packets on that flow are switched in hardware. The Catalyst 4500 switching engine supports a maximum of 4096 flows.

Hope to help


CreatePlease to create content