I have been trying to get PBR to work on a 4500x running entservices for the last few days in my lab before deploying into production. However, I am having problems getting PBR to work on the SVIs; local PBR is working as desired on the core. I did however get PBR to function properly on a 3750x running ipservcies. Below is the general setup:
I just noticed the subnet on the firewall for V405 and V405 on the core are marked as different subnets. I verified this in the config and both are /29. I just mismarked the diagram. (9-19-2018)
Vlan 400: MGT Plane for all switches
Vlan 405: L3 Interconnect between core and firewall
Vlan 150: User subnet 10.10.150.0 /24
Vlan 160: User subnet 10.10.160.0 /24
Desired traffic flow:
All traffic coming from any user IP address directed to a switch IP on vlan 400 needs to go through the firewall first. In addition, all traffic originated on vlan 400 such as syslog, ping and ntp need to go through the firewall; this part functions properly as the local PBR route-map on the core directs traffic from the core's vlan 400 to the firewall. Additionally the access layer switches direct their traffic to their default gateway of 192.168.30.1 (Firewall sub-interface).
Here is the PBR configuration that worked as intended on a 3750x but not a 4500x:
-----------------------------------------------
access-list 130 permit ip any 192.168.30.0 0.0.0.255
access-list 135 permit ip 192.168.30.0 0.0.0.255 any
route-map pcnm permit 300
match ip address 130
set ip next-hop 192.168.35.1
exit
route-map local permit 300
match ip address 135
set ip next-hop 192.168.30.1
exit
interface vlan 150
ip policy route-map pcnm
exit
interface vlan 160
ip policy route-map pcnm
exit
ip local policy route-map local
-----------------------------------------------
When issuing a show route-map I see matches on both policies. To help troubleshoot I issued a 'debug ip policy' on the core and received the following results:
Test1:
Ping from PBR-Core to PC#1: Traffic is routed through the firewall as expected
*Aug 30 15:52:41.361 MST: IP: s=192.168.30.2 (local), d=10.10.150.5, len 100, policy match route map local, item 300, permit
*Aug 30 15:52:41.361 MST: IP: s=192.168.30.2 (local), d=10.10.150.5 (Vlan400), len 100, policy routed local to Vlan400 192.168.30.1
*Aug 30 15:52:41.364 MST: IP: s=192.168.30.2 (local), d=10.10.150.5, len 100, policy match route map local, item 300, permit
Test2:
Ping from PC#1 to PBR-Core: Traffic is routed laterally and does not go through firewall; however PBR-Core sends ICMP reply back through firewall which is expected. What is not seen is a policy match for PC#1 (10.10.150.5) to PBR-Core (192.168.30.2). This traffic is defined in access list 130 but for some reason the inbound traffic on interface 150 does not check against the route-map.
*Aug 30 15:55:23.659 MST: IP: s=192.168.30.2 (local), d=10.10.150.5, len 60, policy match route map local, item 300, permit
*Aug 30 15:55:23.659 MST: IP: s=192.168.30.2 (local), d=10.10.150.5 (Vlan400), len 60, policy routed local to Vlan400 192.168.30.1
Test3:
Ping from PC#1 to Switch#1: No log appears on the PBR-Core showing inbound traffic against the route-map. However, the traffic is observed on the firewall and traffic to and from Switch#1 to PC#1 behave as desired.
What am I missing? My money is on one simple command that's needed on the 4500x. Thanks in advance.
Here is a screen capture of a ping test from PC#1 to Switch #1 and Switch #2 according to the firewall logs (Image 1). As you can see the source information and destinations are in the correct order along with the application. There was no output from the Core when I used the 'debug ip policy' command.
(Image 1)
Next is a ping test from PC#1 to the Core switch (Image 2 & 3). With this test I got hits on the Core using the 'debug ip policy' but only for the return traffic from the Core to PC#1. Notice the firewall log source and destination zones are backwards along with the incorrect application. To me shows that the ping from PC#1 to the core is going laterally rather than going through the firewall as desired.
(Image 2)
(Image 3)
