Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!

Policy-Based Routing and SVI forwarding - Ingress/Egress

Hello Cisco enthusiasts, I have been a long time lurker on this page, having solved many issues with the help and documentation of others. 
I currently have an issue that I am trying to wrap my head around, and I am quite perplexed. I am trying to understand in great detail the way traffic is passed across SVIs in the data plane and how that affects ACL matching, in regards to PBR. 

Specifically, I am in my GNS3 lab, trying to test a solution as close to Production as I can. This product we would like to implement essentially acts as a middle-man for RDP traffic. The design from the company is to use Policy-Based routing to redirect all RDP Traffic (port 3389 TCP/UDP) to this box. This pilot program we are running will just involve: 
1.) One Admin VLAN, SVI of This is the SOURCE VLAN. 
2.) One generic server VLAN,, SVI of This is DESTINATION VLAN. 
3.) One Application, the RDP Proxy(IP, in VLAN, SVI of This is our PBR NEXT HOP. 


The overarching issue here is scaling this to an enterprise density. In order to PBR ALL RDP traffic, we would need to ensure we are matching all RDP requests in the environment from ANY VLAN, destined to our SERVER VLANs. Consequently, we would have to match ALL TCP Replies to high-numbered ports from the RDP Proxy. 
TL:DR - We would have to add hundreds of ACL entries to ensure ALL RDP traffic is PBRd to our Proxy. Our goal is to put a truncated ACL in our PBR Match statement on the DESTINATION VLAN SVI. 


Extended IP access list 100
10 permit tcp eq 3389
20 permit udp eq 3389
Extended IP access list 101
10 permit tcp eq 3389
20 permit udp eq 3389

route-map INIT_RM permit 10
match ip address 100
set ip next-hop


route-map REPLY_RM permit 10
match ip address 101
set ip next-hop


------- So how can we consolidate and make this roll out manageable???


My team thought of consolidated all the PBR matching onto the DESTINATION SVI, as such: 
Extended IP access list 2001
10 permit tcp any eq 3389
20 permit tcp eq 3389 any


Theoretically, this would catch any traffic INGRESS to the Destination SVI and also the REPLY traffic back to the host. This format of ACL would cut our management overhead in half, in regards to building and modifying ACLs across our global network. 

However, I cannot get the ACL to match the INGRESS traffic. No matter how I write it. I even tried an ANY eq 3389 ANY eq 3389 (while running debug ip policy). I only see the REPLY traffic being counted to the PBR rule. 


Can anyone explain to me in very good detail, why this behavior is occurring? I have some ideas. It is possible that since the traffic has already been routed from the host SVI to the server SVI, it passes the "phase" of PBR/ACL matching, as it already has been forwarded/dispatched. I also found some notes regarding ingress/egress in regards to PBR on SVI. 


Any ideas, tech notes or explanations would be very helpful. I could not find solid documentation on the exact science how SVI routing/forwarding is treated, in reference to PBR. 

Many thanks! 



paul driver
VIP Mentor


It look like the problem is the setup, You are asking the router for it to reach its specified destination in the ACL go via an PBR alternate path (which is fine) However when it reaches that path you want it then redirected again to the destination subnet which would be fine if the destination L3 subnet resided off the PBR subnet but it doesnt its on the same L3 switch as the Source/PBR subnets

kind regards

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

Yes this is correct. I realized that the REPLY traffic from the RDP Proxy would be hit by the PBR match statement as well, essentially creating a loop there. I need to find a way to exempt the traffic.