12-13-2013 08:14 PM - edited 03-07-2019 05:04 PM
I'm attempting to use PBR on a 3560 switch. Everything seems to be working OK but we have some periodic CPU interupt spikes that are effecting performance.
I have three vlans
vlan 1 - 172.19.142.0/24
vlan 2 - 172.20.142.0/24
vlan 3 - 173.23.142.0/24
route-map PBR permit 10
match ip address 140
set ip next-hop 192.168.250.2
I'm trying to policy route all www and ssl traffic
ip access-list 140 permit tcp any any eq www
ip access-list 140 permit tcp any any eq 443
However I have two problems
1)I have internal web services, so I need www traffic from 172.23.142.0/24 ro route to 172.19.142.0/24 and this policy sends all www traffic out next hop of 192.168.250.2
2)When I add to acl 140
ip access-list 140 deny tcp 172.23.142.0 0.0.0.255 172.19.142.0 0.0.0.255 www
The policy works as expected but CPU starts to spike.
If I try to use 'set ip default next-hop XXXX' or change to 'route-map PBR deny 10' (for internal routed) the ip policy route-map pbr statement disappears from the vlan interface and cannot be re-added. No errors are displayed, it's just like the command is ignored.
I've looked at:
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a00807213f5.shtml#pbr
Specifically
•Do not match ACLs that permit packets destined for a local address
•Do not match ACLs with deny ACEs
I'm looking for a way to impliment PBR for selective traffic (www and 443), but keep the internal routing intact using the same protocols (www and 443).
Any suggestions would be appreciated.
Thanks,
Tom
12-14-2013 12:20 AM
If you write your ACLs and route-maps going from most specific to least specific you should be fine. So try something like this:
conf t
ip access-list extended WWW-142
permit tcp 172.23.142.0 0.0.0.255 172.19.142.0 0.0.0.255 eq 222
ip access-list extended WWW-SSL
permit tcp any any eq www
permit tcp any any eq 443
route-map PBR permit 10
match ip address WWW-142
set interface vlan 1
route-map PBR permit 20
match ip address WWW-SSL
set ip next-hop 192.168.250.2
Does the 3560 support setting the interface? You could give that a try.
Daniel Dib
CCIE #37149
12-14-2013 12:40 AM
Daniel,
route-map PBR permit 10
match ip address WWW-142
set interface vlan 1
how about leaving out the set statement entirely? If I remember correctly, the normal routing table will be used then but I'm not quite sure.
Regards
Rolf
[EDIT]:
Seems like my brain works even on a saturday morning ;-)
https://supportforums.cisco.com/message/4056398
So this should work as required:
ip access-list extended WWW-142
permit tcp 172.23.142.0 0.0.0.255 172.19.142.0 0.0.0.255 eq www
!
ip access-list extended WWW-SSL
permit tcp any any eq www
permit tcp any any eq 443
!
route-map PBR permit 10
description Internal Web-Servers => RIB
match ip address WWW-142
! no set needed
route-map PBR permit 20
description External WWW/SSL => PBR
match ip address WWW-SSL
set ip next-hop 192.168.250.2
12-14-2013 03:17 AM
One more note:
- Do not match ACLs that permit packets destined for a local address. PBR forwards these packets, which can cause ping or Telnet failure or route protocol flapping.
I think "local address" here means control-plane traffic destined to a SVI. Shouldn't be an issue here as we don't change the next-hop for such packets.
12-14-2013 05:06 AM
Nice one Rolf!
So that definitely seems like the best option when you want to have a broad ACL but still do some forwarding according to RIB.
Daniel Dib
CCIE #37149
12-14-2013 07:43 PM
Thank you all for your for your suggestions.
But unfortunately it looks like a locally connected subnet cannot be listing in an ACL:
My interupts jump to 4% with only one connection from 172.19.142.124 to 172.23.142.11
Rolf, I think the "local address" is a locally connected subnet, but thanks.
CPU utilization for five seconds: 10%/4%; one minute: 9%; five minutes: 9%
Then it jumps to 6% for a file transfer:
CPU utilization for five seconds: 13%/6%; one minute: 10%; five minutes: 9%
using:
route-map PBR permit 10
match ip address 198
!
route-map PBR permit 20
match ip address 199
set ip next-hop 192.168.250.2
ACL 198 matches the directly connected subnets.
permit ip 172.23.142.0 0.0.0.255 172.19.142.0 0.0.0.255 (1016 matches)
ACL 199
is everything above.
It was in the high 20% range yesterday and TAC believes that is what the issue is.
I did run thru a TAC ticket with the routing team last night and they had this same solution, but the issue remained.
They say it's the interupts: CPU utilization for five seconds: 10%/4%; that are causing the performance issue. Turns it into a software switch??
They did not have any other solutions or recommendations to try.
I was setting this up as a temporary solution while we changed our internet facing device (2811 router to a Fortinet device), and was thinking of leaving it as a failover/DR solution in case something happened with the Fortinet. But it looks like this may not work.
I really appreciate the suggestions and am hopful there may be another suggestion here.
Thanks again for everyone's time.
12-16-2013 08:32 AM
I'm not entirely sure this will work but it is worth a try. if you can't use local subnets then you need to specify all possible internet addresses. The acl below uses wildcard masks to specify every possible internet address. Due to the way wildcard masks work all traffic between 172.16.x.x and 172.31.x subnets do not match the acl. if you wanted to be more specific to your subnets you could be but it would make the acl considerably longer. But as this whole range is private addressing it doesn't really matter or shouldn't.
Also to keep the acl short it does allow traffic to the other private address ranges ie. 10.x.x.x and 192.168.x.x but then so did your original acl. So you only need one permit statement in your route map with sets the next hop to 192.168.250.2.
I have assumed that you do not have any http/https traffic between internal subnets that you actually want to policy route. If you do this acl would not match and therefore they would be routed using the normal routing table.
permit tcp any 0.0.0.0 127.255.255.255 eq www - covers all class A networks
permit tcp any 0.0.0.0 127.255.255.255 eq ssl
permit tcp any 128.0.0.0 31.255.255.255 eq www - 128.0.0.0 -> 159.255.255.255
permit tcp any 128.0.0.0 31.255.255.255 eq ssl
permit tcp any 160.0.0.0 7.255.255.255 eq www - 160.0.0.0 -> 167.255.255.255
permit tcp any 160.0.0.0 7.255.255.255 eq ssl
permit tcp any 168.0.0.0 3.255.255.255 eq www - 168.0.0.0 -> 171.255.255.255
permit tcp any 168.0.0.0 3.255.255.255 eq ssl
permit tcp any 172.0.0.0 0.15.255.255 eq www - 172.0.0.0 -> 172.15.255.255
permit tcp any 172.0.0.0 0.15.255.255 eq ssl
permit tcp any 172.32.0.0 0.31.255.255 eq www - 172.32.0.0 -> 172.63.255.255
permit tcp any 172.32.0.0 0.31.255.255 eq ssl
permit tcp any 172.64.0.0 0.63.255.255 eq www - 172.64.0.0 -> 172.127.255.255
permit tcp any 172.64.0.0 0.63.255.255 eq ssl
permit tcp any 172.128.0.0 0.127.255.255 eq www - 172.128.0.0 172.255.255.255
permit tcp any 172.128.0.0 0.127.255.255 eq ssl
permit tcp any 173.0.0.0 0.255.255.255 eq www - 173.0.0.0 -> 173.255.255.255
permit tcp any 173.0.0.0 0.255.255.255 eq ssl
permit tcp any 174.0.0.0 1.255.255.255 eq www - 174.0.0.0 -> 175.255.255.255
permit tcp any 174.0.0.0 1.255.255.255 eq ssl
permit tcp any 176.0.0.0 15.255.255.255 eq www - 176.0.0.0 -> 191.255.255.255
permit tcp any 176.0.0.0 15.255.255.255 eq ssl
permit tcp any 192.0.0.0 31.255.255.255 eq www - 192.0.0.0 -> 223.255.255.255
permit tcp any 192.0.0.0 31.255.255.255 eq ssl
Like i say no guarantees and i have no idea of what this will do to the switch in terms of CPU etc. but probably worth a try.
Jon
12-16-2013 12:14 PM
Thank you all for your suggestions. I had to abandon this path as it was causing too much of a performance issue.
It we just had one subnet, I believe everything would have been fine, but whe we tried to route across subnets the CPU would spike and we would experience extremely high latency and voice calls were getting dropped.
Appenty this is a limitation of the 3560 and 3750 switches and intra-vlan routing.
Thanks again for your time and input, I appreciate it.
Tom
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide