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

[MHM Cisco World]

R-MLS1-MLS2
you want internal VLAN to route in each MLS and if other then use edge router?

use one vlan 
vlan connect R1-MLS1 -access or trunk -MLS2

config default toward next hop R

this way if traffic is route internal it ok if not then the packet will forward to R.

please try this design and send me result.

[salemmahara]

Thanks for replying,
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. So, for making an exception in routing we used an ACL to distinguish the traffic (Permit ip VLAN X to ANY) and also a PBR to set the next hop which is MLS2( Set ip DEFAUL next-hop MLS2). This command is designed to: first, check the Routing table and if there was a route to the destination(Internal networks) not policy that. Then, applys the policy if couldn't find a route in table.

After applying the policy to SVI, clients are able to access the internet through Edge2( this part of scenario is working fine). But, they are not able to access and ping internal networks incluing their defaul-gateway!(normal routing); however Tracert completes successfully! (How does it happen? they are not able to ping the gateway but have internet access!!!). After removing the policy from the interface, clients are able to access internal netwoks but the internet traffic is routed through Edge1 (Different than what we need)

[MHM Cisco World]

route-map test deny 10

match ip address 110

Route-map test permit 20

Match ip address 100

set ip default next-hop Site2-Edge-Router

For acl 110 make it match subnet to other subnet internal

Try this way and send me result later 

[salemmahara]

Dear MHM,

I know it and I've already configured Deny statements to address the issue. The problem is with the concept. 

set ip default next-hop is supposed to firstly check the routing table and do the normal routing (So there shouldn't be any need to deny statement for internal routes because it has a higher priority). If we need to Deny internal traffic with ACL, why we have to use DEFAULT keyword in the set command? we can use set ip next-hop .

Cisco says set ip default next-hop  check routing table first, then goes for PBR.

[paul driver]

Hello

"set ip default next-hop is supposed to firstly check the routing table and do the normal routing"

This is correct however it would depend on the topology which at present you are not being clear on, Please post a topology of this network so we can better understand it.

[salemmahara]

Hi Paul,

Great to have you here,

Well, it is not possible to copy the configuration here for some reasons. But I can say:

1. All VLANs are shown in MLS1 routing table as Connected 

2. Connected networks to MLS2 are propagated using EIGRP, So MLS1 has a summarized route to MLS2 .

Same situation for MLS2.

You can ignore MLS2 from the scenario. Why PBR is applying even on traffic to directly connected destinations :

MLS1:

int vlan 100
ip add 100.100.100.1 255.255.255.0

int vlan 110
ip add 110.110.110.1 255.255.255.0

int vlan 120
ip add 120.120.120.1 255.255.255.0
ip policy route-map test

ip access-list 100 permit ip 120.120.120.0 0.0.0.255 any

route-map test permit 10
match ip add 100
set ip default next-hop MLS2_IP

router eigrp 1
network 100.100.100.1
network 110.110.110.1
network 120.120.120.1

ip route 0.0.0.0 0.0.0.0 Edge1_IP

In this scenario, traffic from 120.120.120.0/24 to any destination (Except those existing ones in routing table) are supposed to be normally routed. But after applying policy to vlan interface, clients can't ping any internal address; however they can access internet through MLS2.

[paul driver]

Hello

I can see you have a default route set, and when you have a default route in the rib and you apply set ip default next-hop it will be policy routed with the ip default next-hop as its overriding the current default route. 

[salemmahara]

Of curse it is. As I said, traffic from clients in VLAN 120 is passing through MLS2 to internet successfully. The problem is with  traffic to internal networks(which are directly connected to MLS1 or learnt from other neighbors)

* Everything would be great by Denying internal traffic in first sequences of ACL. But I am looking for a logical answer to justify DEFAULT keyword 

[paul driver]

Hello
You are at present telling the router to policy route all traffic from vlan 200 towards the set ip default next-hop ip address, now if you want to negate certain traffic to be policy routed say between vlan 200 and vlan 100-110 then you will need a deny ace statement before the permit ace statement in your acl 

no ip access-list 100 permit ip 120.120.120.0 0.0.0.255 any
ip access-list 100 deny ip any 100.100.100.0 0.0.255
ip access-list 100 deny ip any 110.110.110.0 0.0.255
ip access-list 100 permit ip any any

And the logical answer is set ip default next hop when used inconjunction with a default route existing in the rtrs rib table is that the traffic in the Policy statement will be policy routed

[salemmahara]

Thanks a million for the time you're spending on this topic.

So, I am wrong about definition of set ip default next-hop. Because I thought it doesn't matter weather we have or have not default route and it only check RIB for normal routing and then goes for PBR. But as you said, when we have a default route, this command means overriding the default route (Just it). Something like a separate default route for specific traffic.

So, there is no difference between set ip next-hop and set ip default next-hop in my scenario. Right?

I was looking for a way to do the job without denying other traffic. What about the scenario without default route? That wouldn't need Deny lines. Right?

[paul driver]

Hello
In your scenario it looks like you have a default route and are also receiving eigrp routes, so if you specify the set ip default nexthop/interface at this point no policy routing will occur on the pbr rtr as there would be more specific routes to the destination via eigrp  ( rib check – just as you stated), However if the PBR rtr wasn’t receiving any specific routes but was receiving or had only default routes then your PBR statement with set ip default next hop/interface will work.

Lastly if you add a recursive statement which also will check the rib first for forwarding to the specified recursive ip however this time irrelevant even if you had default routes or specific routes policy routing via the rib will occur as the recursive will take precedence over set ip default next-hop/interface,

[Richard Burts]

So far we do not know much about the switches being used. And that might be significant. I know that on some switches (and perhaps some versions of code) that set ip default next-hop does not work - or does not work correctly. What can you tell us about these switches? What model of switch? What version of code? Are these real switches or is this in some emulator?

I am also concerned about the statement that hosts in the subnet being policy routed can not ping their gateway but that tracert does work. 

As I understand the discussion I believe that conceptually you are correct. With the access list that you are using every packet from a host in vlan 100 should be evaluated for PBR. When using set ip default next-hop they should use normal routing for other connected networks and for networks learned via EIGRP and only traffic to destination using the default route should be changed. That fact that this appears to be not working makes me wonder if something in the actual configuration is different from what we expect or that these particular switches have an issue with this feature. Perhaps output from debug for PBR might provide some insight?

[salemmahara]

Hello Rechard,

Thanks for joining us.

Maybe it is a bug and maybe is not!(Check Paul's last reply about the existence of default roue in our scenario). Although I am a bit angry with Cisco and its logic behind this justification and I am not hundred percent satisfied. Because I think the instruction behind the code should be kept the same(Whether we have default route and learnt route from neighbors or not)

[Georg Pauwen]

Hello,

something doesn't look right in your routing tables: if you have an SVI for Vlan 50 on both switches, there should be a 'C' (connected) entry for that Vlan in your routing tables ?

Post a schematic drawing of your topology showing how everything is connected.