PBR

[salemmahara]

Hello guys,

Here we have a small scenario you might be interested to participate in:

Imagine we have 2 MLS with a number of SVI on each.

SW1:

       SVI:

             VLAN 100: 100.100.100.1/24

             VLAN 110: 110.110.110.1/24

             VLAN 50  : 50.50.50.1/252

       Routing Table:

             S   0.0.0.0   0.0.0.0    via Site1-Edge-Router

             D  200.200.200.0/24 via VLAN 50

             D  220.220.220.0/24 via VLAN 50

             C 100.100.100.0

              C 110.110.110.0

        ACL:

             ip access-list 100 permit 100.100.100.0 0.0.0.255 any  (internet)

        PBR:

             route-map test permit 10

             match ip address 100

             set ip default next-hop 50.50.50.2

SW2:

       SVI:

             VLAN 200: 200.200.200.1/24

             VLAN 220: 220.220.220.1/24

             VLAN 50  : 50.50.50.2/252

       Routing Table:

             S   0.0.0.0   0.0.0.0    via EdgeRouter

             D  100.100.100.0/24 via VLAN 50

             D  110.110.110.0/24 via VLAN 50

             C 200.200.200.0

             C 220.220.220.0

        ACL:

             ip access-list 100 permit 100.100.100.0 0.0.0.255 any  (internet)

        PBR:

             route-map test permit 10

             match ip address 100

             set ip default next-hop Site2-Edge-Router

  In this scenario, SW1 is supposed to pass traffic from 100.100.100.0/24 to any destination ( Except existed ones in routing table) to SW2 for using the internet. So, packets to exist destinations in routing table must be routed based on this table and if the destination is not exist, they must be policed. But after applying the route-map to the SVI vlan 100, traffics to internal networks will be timed out( Clients even can not ping the gateway (SVI100); however Traceroute is complated successfully! For solving this problem, I have to deny internal network in IP access-list ; however, SET IP DEFAULT NEXT-HOP is supposed to use Routing Table and then policy the traffic if it could not find a route in the table.

For clarification:

It is supposed to not policy traffic to destinations within routing tables. But it seems to policy all packets. 

I mean, it is working like SET IP NEXT-HOP

[salemmahara]

Hello Georg,

I'm really happy to have you here.

This is actually a Pseudo code. Consider the route there. 

Could you please check my last reply to MHM?

[MHM Cisco World]

MLS1-VLAN50-MLS2
without PBR 
we will config two static route 
ip route 0.0.0.0 0.0.0.0 toward MLS2 router edge
ip route 0.0.0.0 0.0.0.0 toward MLS1 SVI VLAN 50

so this way if the the default route is disappear then the traffic will go to MLS1 SVI VLAN 50.
check this solution.

[paul driver]

Hello
@MHM Cisco World  your solution doesn't involve PBR whatsoever so not so sure now where this discussion is going as It seems it has change from the the OP, My understanding was it related about the concept of PBR and the set ip default/interface command, now it seems to have moved slightly so to resolve an existing network issue?

[MHM Cisco World]

Yes I know we talk about the PBR but i write my view to solve this issue.
PBR with many deny and permit is hard work.
so from what I understand he want redundancy if the edge router MLS2 is down then the traffic pass to edge router MLS1. 

Thanks for your point

[Richard Burts]

Here is how the original poster describes the situation "Both MLS1,2 has their own Edge router and a default route to it. MLS1 sends internet traffic to Edge1 and MLS2 sends internet traffic to Edge2. But, we have a specific VLAN connected to MLS1 which is supposed to use the ISP connected to Edge2." Clearly this is not describing failover or redundancy but is describing an exception to normal routing (as provided by PBR).

[MHM Cisco World]

Thanks for reply 

"we have a specific VLAN connected to MLS1 which is supposed to use the ISP connected to Edge2"

You are right but he want to config ip default next-hop, this "default" keyword meaning that if the route is not appear in RIB then it will use the next-hop set in PBR.

so instead of all these complex can we use VLAN 50 which is transit VLAN to forward traffic if the default is missing in RIB.

[paul driver]

Hello
My understanding also was this post was related to PBR and the concept of it surrounding as to why the set ip default next-hop xx didn’t work as expected for the OP and how he could accomplish policy based routing without using deny aces in any route-map ACL .

As for the reason why, policy-based routing wasn’t working in this instance pointed towards to the pbr rtrs rib being populated not only with a default static route but also with it receiving specific eigrp prefixes that was taking precedence over that specific PBR command.

@MHM Cisco World  - The none PBR solution you proposed based on this topology could have a very good chance of not working, We don’t know if the rtr ports are directly connected to the switch or not so the switch can see the rtrs interfaces going down for the primary default route to be removed from the rib, However most sites usually implement wan handoff switches between their wan rtrs and core lans, and if this is the case here then the core switchports wouldn’t go down as such the primary default static won’t be removed and traffic would then be blackholed, Unless that is some condition to the static routing you proposed is incorporated, Such as ip sla tracking appended to the primary default route and a high admin distance appended to the secondary route.

[salemmahara]

Although I can understand your justification, let me not accepting that. There is a default route with MLS1's rib. We have also a series of routes learnt from MLS2(EIGRP neighbor) which are summarized. So, we still have route for LAN subnets. In this scenario, We want to ask the MLS to : Redirect traffic from VLAN X to internet (ANY destination) to a next-hop rather default next-hop . Why the PBR logic still force us to make an exception for LAN traffic? It is destroying the logic of the command.

To make this topic more challenging (A good source for others), let's get deep in Cisco's reasons in this case. Why the switch is concerning the existence of default route? Why the switch doesn't look its rib to find routes to LAN segments?

[paul driver]

Hello

Redirect traffic from VLAN X to internet (ANY destination) to a next-hop rather default next-hop . Why the PBR logic still force us to make an exception for LAN traffic? It is destroying the logic of the command.
Unless you dont want all traffic originating from the PBR interface to be policy routed then you don't have to use any deny ace entry in the acl in fact you don't even require an acl 

With reference to the ip default next hop xx command --
Why the switch is concerning the existence of default route?
Because you have specified the ip default next hop xx command and that's what the command is suppose to do.

Why the switch doesn't look its rib to find routes to LAN segment
It does and if it finds a more specific route (including summarised) than the default to the destination then normal routing is performed and not PBR.

[Richard Burts]

Paul makes an interesting point that an acl is not needed to achieve the desired result. Since PBR is to be applied to all traffic originating from this vlan there is not a real requirement for a match clause but only requires a set clause. 

Paul’s description of how PBR works is exactly what my experience has been in using set ip default next-hop. But the original poster is very clear that it is not working that way for him. So why is it not working?  Perhaps if we could see the config we might find some issue. Perhaps if we knew whether this is an emulator or real hardware it might make a difference. Perhaps knowing the model of switch and version of code might shed some light. Perhaps the output of debug for PBR might give us an answer. 

[salemmahara]

Thank you Richard,

This is not a lab. It is a real scenario and MLS switches are catalyst 3850 with ios 3.x.x and ip services license

[Richard Burts]

Thank you for telling us that this is real hardware (3850 switches). That does eliminate one of the possible explanations for the behavior you describe. I continue to wonder about the possibility that there is something in the config that we do not know about and which is impacting the actions of PBR. But perhaps the best thing we might do in investigating this issue would be to run debug for PBR, make some effort to access an internal resource, and post any output from debug.

Also I continue to wonder about this statement " they are not able to access and ping internal networks incluing their defaul-gateway!(normal routing); however Tracert completes successfully!" Perhaps you can post output from a device attempting to access something in the internal network and then doing tracert. 

[salemmahara]

According to your answer to Q3, why the switch apply policy to traffic going to its local SVIs and networks learnt from neighbors? Because we've configured Default route with 0 metric. Right? What if we change the metric to a higher number(even greater than eigrp)

[paul driver]

Hello

Because we've configured Default route with 0 metric. Right? What if we change the metric to a higher number(even greater than eigrp)

It wont make no difference, By default routing path is determined by longer prefix match ( not just PBR but in any scenario), So only if there are multiple prefixes found to have the same length THEN admin distance is taken into account even if you give the default static a admin distance of 254 for when you have longer more specific prefixes matching on the destination in the rib forwarding will take that path.

[salemmahara]

Finally I decided to bring a piece of code here :

Gateway of last resort is 192.164.0.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.164.0.2
D     192.167.0.0/16 [90/15360] via 192.165.0.1, 00:00:07, Vlan200
      192.166.0.0/16 [90/15360] via 192.165.0.1, 00:00:07, Vlan200
D        192.168.0.0/16 is a summary, 7w0d, Null0
C        192.168.1.0/26 is directly connected, Vlan2
C        192.168.1.64/26 is directly connected, Vlan3
C        192.168.1.128/26 is directly connected, Vlan4
.
.
.


interface Vlan4
 ip address 192.168.1.129 255.255.255.192
 ip policy route-map TEST

route-map TEST permit 10
 match ip address TEST
 set ip default next-hop 192.165.0.1

ip access-list extended TEST
 permit ip 192.168.1.128 0.0.0.63 any

Now, PC1 with IP address of 192.168.1.132 is going to access 192.167.1.1 . We have a route to 192.167.0.0/24  so in spite of having a PBR on SVI VLAN 4, it is supposed to be routed. But this is policied and no one of devices in 192.167 , 192.166 and even 192.168(connected subnets to MLS) is reachable.

to solve this problem, we have to add below code in firs line of ACL:

 deny   ip 192.168.1.128 0.0.0.63 192.168.0.0 0.0.255.255
 deny   ip 192.168.1.128 0.0.0.63 192.167.0.0 0.0.255.255
 deny   ip 192.168.1.128 0.0.0.63 192.166.0.0 0.0.255.255

Why MLS is applying the Policy in spite of routes in rib?