cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5220
Views
5
Helpful
16
Replies

3560 policy based routing problem

mukremin13
Level 1
Level 1

I have tried to make policy based routing on Cisco 3560. I use ipservices ios (SW version 12.2.(50)SE3 and SW-IMAGE C3560-IPSERVICESK9-M) 

For below configuration there is no problem and pbr is working.

“Access-list 100 permit ip host  1.1.1.1 host 2.2.2.2

Access-list 101 permit ip host  1.1.1.1 host 3.3.3.3

Route-map pbr1  permit 10

Match ip address  100

Set ip next-hop verify-availability  1.1.1.2 1 track 11

interface fasthethernet  0/1

ip policy route-map  pbr1”

But when i add another sequence to the "pbr1" with another sequence number  like that.

Route-map pbr1 permit  11

Match ip address  101

Set ip next-hop verify-availability  1.1.1.3 1 track 12”

pbr is not working. Switch gives message "PLATFORM_PBR-3-UNSUPPORTTED_RMP:Route-map pbr1 not supported for Policy Based  Routing”

"ip policy route-map pbr1" command not shown in the running config. And "show ip policy" output is blank.

Configuration guide says you have insert many sequence to the route-map with the same name. And also this command is not in the unsupported command list.

What is wrong with my configuration, i dont understand?

thanks in advance.


16 Replies 16

Hi,

Error Message    PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map [chars] not supported for 
Policy-Based Routing 

Explanation    This message means that the route-map attached to an interface for policy routing contains an action that is not supported on this platform. This is a hardware limitation. [chars] is the route-map.

Recommended Action    Use the route-map map-tag permit global configuration command and the set ip next-hop ip-address route-map configuration command to reconfigure the route map to use only these supported actions.

Did you try to use only set ip next-hop , without verify. It seams that this is the limitation.

Dan


Hi Dan;

Thanks for answer this correct my problem. But without verify availability this solution is not appropriate for my situation.

I have two next-hops and these next hops are backup of each other. With verify availabilty cisco choose the up next-hop.

But without verify availability next-hop is fix and packet is always routed to this next-hop whether it is up or down.

Am i wrong, please correct me? and is there another solution for this problem? 

Yes you are correct. I didn't said that you did wrong

You might try using L3 ports for each next hop instead of transit vlan. This will cover link to the next hop issue , also reboot of the next-hop equipment or some other issues.

Dan

I use L3 ports for next-hops but i didnt understand "reboot of the next-hop equipment", please explain it?

You current setup is vlan based , meaning that 1.1.1.x is assing on a 3560's  vlan ( SVI ). Correct me if I'm wrong.

If this is the case, let's consider you have more the 1 equipment in this vlan (beside the 3560), let's name them A (1.1.1.2) and B (1.1.1.3) as in you initial example. If you loose the physical link to A , and you are using simple PBR without verifying reachability (as you should), the switch will still forward the packtes to A - as you said, because you have at least 1 more port in UP state.

But if you are using L3 ports - lets say point to point layer 3 ports - between the 3560 and the other equipments ( A and B in our case ) If you will loose the link to A - as the precedent example -  then PBR will not route to the next hop configured because you will not have it on the routing table.

Dan

I used L3 not vlan based setup for that interface. The other things you are absolutely right.

But my situation is different.

As you said next hops names are A and B. The next hop interface name is A1 and B1. A and B has only two interfaces. And A2 and B2 linked to the C1 and D1 respectively. A and B is crypto equipment, C and D are cisco devices.

I planned to use verify availabilty for C1 and D1 interfaces for recognizing A and B device are running. And if C1 is not reachable, i understand that crypto device A is not working.

Sum up, when A1 and B1 interfaces are up is not guaranty for A2 and B2 is up and crypto devices are working.

Please for this situation, recommend another solution to me

If I understood well the encryption equipments are transparent to the layer 3 topology. If this is the case, have you tried to run a routing protocol between the C,D ( which I suppose are the WAN routers )  and the 3560 - though the encryption equipments ?

Dan

Encryption equipments are not transparent and also i have to make source based routing.

Does the encryption eq. support dynamic routing protocols ? I would run it between 3560 and encryption eq. and also encryption eq and the access routers (C/D).

Dan

unfortunately does not. sorry for negative answers but the situation is that. I think verify availability the only solutiion for my situation

If the encryption eq does not support dynamic routing protocols , yes this is the only solution.

Dan

The last question i hope. instead of using verify availability, can i use both set ip next hop and ip route command with track option.

Ex 

Encryption equipment A's ip A1: 1.1.1.1  A2 1.1.1.2

C1 ip is 1.1.1.3

And some track command for tracking C1 is up or not, track number is 123

route-map pbr permit 10

set ip next hop 1.1.1.1

set ip next-hop 2.2.2.1 (B1 ip)

ip route 3.3.3.0 255.255.255.0 1.1.1.1 track 123

For this config, if track 123 is up ip next hop 1.1.1.1 as expected. If track is down, the next hop is 1.1.1.1 again or, 2.2.2.1.

Any comment?

Yes you can do it. But you will be able to use only one encryption equipment, because in order to work the returning traffic should pass thought the same equipment that has initialy entered. So on the wan routers (C/D)  you will have to route the inside prefix to the same encryption device.

Dan

If i use the same procedure to the C and D routers (these are also 3560) is it running for more than one encryption equipment?

Review Cisco Networking for a $25 gift card