Policy Based Routing on Cisco 3650G switch

[Anand Narayana]

Hi,

  I need to configure Policy Based Routing on Cisco 3650G switch. I have the existing IOS c3560-ipservicesk9-mz.122-58.SE.bin. Can you please let me know how to configure. Requirement is, i have VLAN 10 - 172.16.0.0/24 & VLAN 20 - 172.16.1.0/24, i wanted VLAN 10 subnet users to route through 172.16.2.254 (firwall-A IP) & VLAN 20 subnet users to route through 172.16.2.253 (firewall-B IP) to access internet. The firewall subnet is 172.16.2.0/24.Any help would be appreciated.

[Antonio Knox · Accepted solution]

Since I don't know if you're running any routing protocol, your config would look like this:

!----Define interesting traffic

ip access-list extended interestingvlan10

10 deny 172.16.0.0 0.0.0.255 172.16.1.0 0.0.0.255

20 permit ip 172.16.0.0 0.0.0.255 any

ip access-list extended interestingvlan20

10 deny 172.16.1.0 0.0.0.255 172.16.0.0 0.0.0.255

20 permit ip 172.16.1.0 0.0.0.255 any

!---Create route map for next hop definition

route-map Redirect1020 permit 10

match ip address interestingvlan10

set ip next-hop 172.16.2.254

route-map Redirect1020 permit 20

match ip address interestingvlan20

set ip next-hop 172.16.2.253

!----apply to interfaces

int vlan10

ip policy route-map Redirect1020

int vlan20

ip policy route-map Redirect1020

Rate if helpful.

[Anand Narayana]

Thanks for the configuration. I shall let you know the result tomorrow when i test that in my lab. 2 Quick question in addition to that.

1. I believe there should not be default route command, am i right?
2. If i add a static route to a different gateway which is not part of the 2 firewalls i mentioned, will that route be common for 2 different subnet & will that be able to route the traffic accordingly?

[Antonio Knox]

The static (default) route will not take precedence as long as the 'next-hop' addresses of the route-map are reachable.  Should 172.16.2.254 become unreachable, then all vlan 10 traffic will route through the next hop address of your static route.  The same applies for vlan 20 should 172.16.2.253 go down.  Does this answer your question?

[Anand Narayana]

'next hop' will route to 0.0.0.0 / 0.0.0.0 network. My question is if i have a static route added like 'ip route 192.168.0.0 255.255.255.0 172.16.2.250', will this work?

172.16.2.252 & 172.16.2.252 will route all the packets to the internet based on the VLAN 10 & 20 as per your configuration, where as 172.16.2.250 a VPN box which i will use to create tunnels. I agree that unless 172.16.2.253 or 172.16.2.253 become un-recheable, it would not look any gateway, but what if i add a specific network to reach different gateway even though 172.16.2.52 & 172.16.2.253 is reachable?

[Antonio Knox]

This would definitely work, but to ensure that it does you will need to exclude the 192.168.0.0/24 network from the interestingvlan10 and interestingvlan20 ACLs so that traffic destined for the 192.168.0.0/24 network are excluded from policy routing.  Add the following:

ip access-list extended interestingvlan10

5 deny 172.16.0.0 0.0.0.255 192.168.0.0 0.0.0.255

ip access-list extended interestingvlan20

5 deny 172.16.1.0 0.0.0.255 192.168.0.0 0.0.0.255

exit

ip route 192.168.0.0 255.255.255.0 172.16.2.250

be certain to use an entry number below 20 for each ACL 'deny' entry so that they do not fall behind the permit ACL entries.

Rate if helpful.

[Anand Narayana]

Hi Anoni,

  Everything seems to be working in the lab as per your configuration. will be testing the actual configuration LIVE by this week end. Will rate the post upon my sucessful implementation :-). Haven't tried the static route to specific network, which i would let you by next week ;-)

[Antonio Knox]

Did you have any luck with the configuration in production?

[dhristov]

I would like to add a note to the ACL used for PBR. On 3000 platforms the ACL used for PBR should contain only permit Entries. Please consider to change the ACL with permit entries only to avoid high CPU. Route-Map with deny statement will be rejected.

"For PBR, route-map statements marked as deny are not supported."

"Do not match ACLs with deny ACEs. Packets that match a deny ACE are sent to the CPU, which could cause high CPU utilization."

Reference:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_58_se/configuration/guide/swiprout.html

-Dimitar

[Antonio Knox]

Duly noted.  I actually didn't know that about the 3000s.  Good info to have in case I run into one of those.

[Anand Narayana]

Like Dimitar mentioned, "Do not match ACLs with deny ACEs. Packets that match a deny ACE are sent to the CPU, which could cause high CPU utilization". But in my setup how to access the other VLAN's when PBR is enabled? Because if don't specify DENY statement, while i try to access a workstation from VLAN 10 to VLAN 20, it doesn't access since it takes a default path towards the policy route-map statement & hits internet. Below is my config. Any suggestion is most welcome as i am slightly seeing CPU utilization when DENY statement is used

ip routing

interface vlan 10

ip address 172.16.0.254 255.255.255.0

ip policy route-map SERVER

interface vlan 20

ip address 172.16.3.254 255.255.255.0

ip policy route-map WORKSTATION

route-map SERVER permit 10
match ip address SERVER
set ip next-hop 172.16.254.2

route-map WORKSTATION permit 10
match ip address SERVER
set ip next-hop 172.16.254.2

ip access-list extended SERVER
deny   ip 172.16.0.0 0.0.0.255 172.16.3.0 0.0.0.255
permit ip 172.16.0.0 0.0.0.255 any

ip access-list extended WORKSTATION
deny   ip 172.16.3.0 0.0.0.255 172.16.0.0 0.0.0.255
permit ip 172.16.3.0 0.0.0.255 any

CORE-SWITCH#sh sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  3K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    11K
    number of directly-connected IPv4 hosts:        3K
    number of indirect IPv4 routes:                 8K
  number of IPv4 policy based routing aces:         0.5K
  number of IPv4/MAC qos aces:                      0.5K
  number of IPv4/MAC security aces:                 1K