PBR on contents AND next-hop of incoming packets?

[rogelioalvez]

hello team.

I want to redirect incoming packets to a specific next-hop (another NH than the expected by routing table) if

condition 1: packets lie within a certain category

AND

condition 2: the next-hop (in the routing table) of these packets is a certain IP address

So I would build the following sentences:

interface g0/0

ip policy route-map REDIRECT

route-map REDIRECT permit 10

  match ip address 100

  match ip next-hop 1

  set ip next-hop a.b.c.d

whereby 100 es the ACL that detects the candidate packets and 1 is the ACL that specifies the next-hop according to the routing table.

¿ Is this a supported configuration? I have not seen anything in the documentation that would prevent this scenario from working, but I would appreciate your helpful hints.

Thanks in advance

Rogelio Alvez

ARGENTINA

[Harold Ritter]

Hi Rogelio,

The second condition is not supported. Please refer to the following documentation to see which match conditions are supported.

http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800a4409.shtml#wp14040

Regards

[rogelioalvez]

Hello Harold, thanks a lot for your quick answer!!

I checked your URL, and what I see is that STD ACLs can be used in checking source addresses and Extended ACLs can be used in checking other fields like source, destination or layer 4 information.

However, the URL does not say that they can not be used to feed the "match ip next-hop" clause.

Since my idea did not work in a testbed, I believe you are right, but I would like to double check again. ¿ is there any specific source of documentation that mentions lack of support of the "match ip next-hop" sentence for PBR?

Thank you very much in advance again!

Best regards, rogelio

[Harold Ritter · Accepted solution]

Hi Rogelio,

"match ip next-hop" can only be used when the route-map is used for routing protocol redistribution. It is not allowed in the PBR context.

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfindp1.html#wp1018782

Regards

[rogelioalvez]

So I am screwed

thank you very much for your helpful answer. I will have to work this around in some other way.

Best regards, Rogelio

[Harold Ritter]

Hi Rogelio,

Maybe we can help if you explain the requirements in details.

Regards

[rogelioalvez]

Hello Harold:

The customer is waiting for new (more powerful) Internet firewalls to replace the present ones, but the new ones will arrive in three months. He asked me to insert a 2nd firewall in parallel to the existing Internet firewalls, because the present firewall custer is running out of resources.

He asked me to schedule traffic distribution among the present cluster and the temporary extra firewall, so I am thinking to PBR some of the (many internal segments in the company).

I need my PBR routine to "know" that packets are driven to the Internet in order to make the proper redirection. This is a complex company with besides RFC1918 addresses, they also have lots of internal segments that happen to be public (and legal) IP addresses, so it is quite cumbsersome to get rid of the "next hop" concept and make a list of IP addresses for which i must not redirect.

I also have to take care not to redirect packets to DMZs protected by the current firewall cluster.

The following picture shows (more or less) the topology I have to take care of:

[rogelioalvez]

Harold:

I am thinking on a much better and simpler workaround. Let me know please your opinion:

To the former default route, pointing to the former firewall cluster, I should add another default route, pointing to the parallel firewall.

The router should install the new default route in the routing table. And balance the outgoing sessions on a (source,destination) basis with its corresponding FIB. I would not need any PBR whatsoever!

I could also add some tracking capabilities to both default routes to guarantee some availability of the paths across the firewalls

¿Am I right?

[Harold Ritter · Accepted solution]

Hi Rogio,

This is a much better approach. It is both simple and effecive compared to what a PBR solution might have been in the current context.

The idea of using tracking is also good. The other way to do it if there are routers between the Internet and the FWs would be to run bgp between the internal and external routers. This would make sure that the default route is learned dynamically and that convergence would take place when one of the paths fail.

Regards

[rogelioalvez]

Thank you very much again. I will follow this advice.

regards, Rogelio