Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

Policy based routing problem - not done in hardware ?

Hello,

I am having a problem with PBR done on a 7604-S router - It seems like it is not done in harware. I have an Iperf client and an Iperf server, and would like to test the performance of 7600 router for PBR, supervisor is RSP720-3C-G and used interface card is 7600-ES20-GE3C ESM20G.

I have read  numerous discussions about PBR that is supposed to happen in hardware when you use it with matching access-list and set ip next-hop.

Although, when I start the iperf, the 7600 cpu is hitting the 80-90 % boundary, and transfer bandwidth can't go over 120-130 Mbit/s.

The IP Policy is applied on an interface part of vrf ONE maybe this is casing the problem... ?

Any suggestions are welcomed.

The diagram and configuration follows:

pbr2.png

Configuration:

c7604#sh run

boot system flash disk0:c7600rsp72043-advipservicesk9-mz.122-33.SRE2.bin

!

ip vrf one

rd 1:1

!

vlan 100

name users2

!

!interface GigabitEthernet4/0/0

ip vrf forwarding one

ip address 192.168.30.1 255.255.255.0

ip flow ingress

ip policy route-map 1

load-interval 30

no mls qos trust

!

interface GigabitEthernet4/0/1

mac-address 2222.2222.2222

ip vrf forwarding one

ip address 192.168.31.2 255.255.255.252

speed 1000

no mls qos trust

!

interface GigabitEthernet4/0/2

ip address 192.168.31.1 255.255.255.252

ip nat inside

speed 1000

no mls qos trust

!

interface GigabitEthernet4/0/3

ip address 91.x.x.x 255.255.255.252

ip nat outside

speed 1000

no mls qos trust

!

interface GigabitEthernet4/0/4

description Internal to SMC p24

ip address 192.168.20.46 255.255.255.0

ip nat outside

speed 100

no mls qos trust

!

interface GigabitEthernet4/0/10

switchport

switchport access vlan 100

switchport mode access

speed 1000

no mls qos trust

!

interface Vlan100

ip address 192.168.40.1 255.255.255.0

!

access-list 10 permit 192.168.30.0 0.0.0.255

!

route-map 1 permit 10

match ip address 10

set ip next-hop 192.168.31.1

!

8 REPLIES
New Member

Policy based routing problem - not done in hardware ?

Nothing changes when I configure the ip route-cache policy on the PBR Interface Gi4/0/0.

Results are as before:

CPU utilization for five seconds: 89%/40%; one minute: 20%; five minutes: 5%

PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process

216      631296     2894561        218 47.59% 10.25%  2.29%   0 IP Input        

........    

Hall of Fame Super Bronze

Policy based routing problem - not done in hardware ?

Post the output from typing:

show tcam interface gig4/0/0 acl in ip


New Member

Policy based routing problem - not done in hardware ?

Here is the output:

c7604#sh tcam interface gigabitEthernet 4/0/0 acl in ip

* Global Defaults shared

Entries from Bank 0

Entries from Bank 1

    permit       ip any 224.0.0.0 15.255.255.255

    punt         ip 192.168.30.0 0.0.0.255 any

    permit       ip any any

c7604#

Hall of Fame Super Bronze

Policy based routing problem - not done in hardware ?

This

punt         ip 192.168.30.0 0.0.0.255 any

indicates the traffic that matches this entry will be punted to the CPU.

I believe it has to do with the fact the 'ip next-hop' in your PBR is set to the router itself.

It must point to a device attached to this router.

New Member

Policy based routing problem - not done in hardware ?

Seems like PBR in VRF is causing the problem, as I moved the VRF ONE from the Iperf client side to Iperf Server side of the setup - Gi4/0/0 and Gi4/0/1 to Gi4/0/2 and Gi4/0/10.

Now I am able to reach nearly 900 Mbit/s with 3 iperf sessions and the 7606 cpu stays below 1 %..

Freaky thing is when I issue the debug ip policy, I am not getting policy routed packets showing as expected, the ACL doesn't have a sigle match and route-map counters are not incrementing...seems very stange to me.

In the global routing table there is no route to 192.168.40.0 network so traffic must be policy-routed... no other way for the packets go...and in VRF ONE I have a default-route pointing to gi4/0/1's ip 192.168.31.2 for the way back.

Hall of Fame Super Bronze

Policy based routing problem - not done in hardware ?

Ruslan Nikolov wrote:

Freaky thing is when I issue the debug ip policy, I am not getting policy routed packets showing as expected, the ACL doesn't have a sigle match and route-map counters are not incrementing...seems very stange to me.

In the global routing table there is no route to 192.168.40.0 network so traffic must be policy-routed... no other way for the packets go...and in VRF ONE I have a default-route pointing to gi4/0/1's ip 192.168.31.2 for the way back.

When a service is running in hardware, you won't be able to capture information via debugs. Only when a service runs in software, the debugging feature will show output and the route-map counter will increment.

BTW, per your original config, 192.168.40.0 is in the Global Routing Table with SVI 100.

Regards,

Edison

Cisco Employee

Policy based routing problem - not done in hardware ?

I am pretty sure to get this to work in your original configuration in hardware you would need to do it like this:

route-map 1 permit 10

match ip address 10

set ip vrf one next-hop 192.168.31.1

-Matt

New Member

Policy based routing problem - not done in hardware ?

Thanks Matt,

with the addition of the vrf keyword in the route-map all works fine, PBR is done in hardware and everything seems OK.

Thanks to all that gave suggestions.

Greets,

Ruslan

935
Views
0
Helpful
8
Replies
CreatePlease to create content