PBR for int vlan on 4507

[Ven Diesel]

Hi All

I am planning to implement PBR on our core switch, so basically idea is we are having checkpoint connected to isp1 and asa connected to isp2, I got a default route on core towards checkpoint and all internet access is being provided via isp 1  at the moment however we want to get rid of isp1 and checkpoint and start using isp2 and asa. we are having many int vlans on the switch and I am going to create a test int vlan and config as follows

access-list 40 permit ip 10.40.1.0 0.0.0.255

route-map test permit 40

match ip address 40
set ip next-hop 10.40.5.x

int vlan 11
ip policy route-map test

so after applying this what will happen to all the remaining subnets will they use the routing table default route or acl will deny all the traffic?

Please let me know am I doing it right and evetually i want all other vlan ip ranges to be following same path, please help me in sorting this out

Thanks

Ven

[Reza Sharifi]

Hi,

If you are trying to get rid of ISP1 and the Checkpoint firewall all together, then you only have one way out and that is using the ASA.  So, why are you deploying PBR since all vlans will go out via ASA.

Since the 4507 is layer-2/3 you just need a /30 between the 4507 and the ASA and default route pointing twards the ASA.

I am understanding you scenario correctly?

HTH

[Ven Diesel]

Hi

Sorry if I confused you

We are planning to decomission the checkpoint, so it will take time and I want to make use of PBR untill the complete migration is done

Let me know if anymore info required

Cheers

[Reza Sharifi]

Ok, I see.  So, if you apply the above policy, only vlan 11 will be routed based on the policy.  The rest of the vlans will go out using the next hop in the routing table.  They will not use PBR.

HTH

[Ven Diesel]

That is exactly what I am looking for so is the pbr config acceptable and can be implemented for testing?

[Reza Sharifi]

It is supported on the 4500.  You may want to read this doc before implementing it to make sure it does not effect anything in your production.

The scale of hardware-based PBR is determined by  TCAM size and the time required for the CPU to flatten the ACL before  programming into hardware.  The latter will noticeably increase if a PBR  policy requires a considerable number of class-maps. For example, a PBR  policy of 1,200 class-maps may require 60-90 minutes of "flatten" time  before programming into hardware.  This process may repeat if an  adjacency change requires PBR reprogramming.

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/53SG/configuration/pbroute.html

Good Luck

HTH

[Rolf Fischer · Accepted solution]

Ven,

I think you don't want to overwrite the next-hop in any case but rather overwrite the default-route (pointing to ASA instead of Checkpoint)?

If so, the "set ip default next-hop " clause would be the better choice.

Then, if the source IP matches the ACL, VLAN-11 traffic is forwarded to as long as no more specific route exists.

One more thing:

If you want to enable PBR for the SVIs too (for testing purposes, e.g. extended ping),  you need the additional (global) command

ip local policy route-map

HTH

Rolf

[Ven Diesel]

Hi

Rofl you made a valid point and thanks a lot so I made modifcation and please give your feedback

PBR Testing:

My aim with the new additional PBR config is to use different default hop instead of the exsisiting default route and I want rest of the routing for this subnet range to be routed via exsisiting routing table and we are using static routing on 4507

Please let me know if I am going in the right diretion and much apprecaite for all your time and assisitance

SAMPLE Final CONFIG:

access-list 25 permit ip 10.40.125.0 0.0.0.255 ?(any)
route-map test permit 25
match ip address 25
set ip default next-hop 10.40.5.1

SW01
int vlan 125
ip add 10.40.125.0 255.255.255.0
ip address 10.40.125.231 255.255.255.0
ip helper-address 10.40.1.208
standby 125 ip 10.40.125.251
standby 125 priority 140
standby 125 preempt
ip policy route-map test

exsisiting Default route on sw01 is
0.0.0.0 0.0.0.0 10.40.3.1

Cheers

[Rolf Fischer]

I'm running a very similar setup on a SUP IV which works without any problem so far.

The 10.40.5.0 network is directly connected, right?

Please let us know if everything works like expected.

Regards,

Rolf

[mahmoodmkl]

Hi

this should be fine check the return traffic as well

Sent from Cisco Technical Support iPhone App

[Ven Diesel]

I will sure update you very shortly,
thanks again

[Ven Diesel]

Hi Guys

The above solution working perfectly and thanks again for your assitance

[Rolf Fischer]

Great. Thanks for rating and marking as solved.


Sent from Cisco Technical Support Android App