cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4824
Views
125
Helpful
38
Replies

PBR

salemmahara
Level 3
Level 3

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

38 Replies 38

Hello

Is this a typo - why are you PBR to a next-hop that the rib already have a route for ?

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
set ip default next-hop 192.165.0.

 

The only way the traffic from vlan 4 should be PBR'd in this case is if the destinations you are trying to reach are not in the rib, then traffic will be policy routed.

Can you set a debug on a pbr and see what results you get, I envisage the policy will be rejected and normal route forwarding take place

debug condition interface vlan 4
debug ip policy


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Given the partial config that was posted traffic from hosts in vlan 4 attempting to access connected subnets or networks advertised from the peer switch should not be policy routed. I agree that running debug for PBR is a good next step. 

 

If the behavior is that this traffic is being policy routed then we can consider these as possible causes:

- something in the config that we have not seen is impacting this traffic. (the least likely of the possible causes but this should be evaluated)

- perhaps the code running on this switch does not really support the set ip default next-hop and using the command produces unexpected results.

- perhaps it is a bug in the code

If you are able to open a case with Cisco TAC this would be the best way to address the second and third potential causes of the behavior.

HTH

Rick

The only way the traffic from vlan 4 should be PBR'd in this case is if the destinations you are trying to reach are not in the rib, then traffic will be policy routed.

Can you set a debug on a pbr and see what results you get, I envisage the policy will be rejected and normal route forwarding take place

This is what I've been trying to say. Traffic from VLAN4 members must be routed to destinations which there is route to them in rib. We are adding this PBR for this VLAN to redirect its users' traffic to internet to another Internet gateway which is not connected to this MLS(So, all internet traffic from VLANs on MLS1 will be routed through MLS1' gateway, but VLAN4 will use MLS2' internet gateway). <- This has a technical and design reason.

 

However, without Deny statements, internal networks(Those with a route in rib) are not reachable for VLAN4 members

Hello
"We are adding this PBR for this VLAN to redirect its users' traffic to internet to another Internet gateway which is not connected to this MLS"

In above scenario I would say you should use an recursive next hop in conjunction with the set ip default-next-hop, so PBR would use the rib first for the recursive lookup and is that isn’t available failover to the static default route however having the set ip default-next hop also would override the static rib default.

Anyway can you post the output of the debug please?
Curious have you tried using the PBR WITHOUT any acl appended to the route-map?


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

The original poster has been pretty clear about what they are attempting to accomplish. @paul driver and I have been pretty clear that PBR with set ip default next-hop should work. The original poster has been clear that it is not working. So there is some problem here. debug output would seem to be the logical next step in investigating the issue. Paul's suggestion about doing the PBR route map with no match statement is an interesting approach and I would be interested in knowing the results of trying it.

HTH

Rick

dear @Richard Burts and @paul driver ,

Thanks for keeping the topic up. 

I'll try to run a debug on the MLS and send the result here.

But, is it possible for one of you to check this problem through a remote connection(Anydesk)? Unfortunately it is not possible to send the whole configuration here ( I am sure you understand the reason )

It would be nice if we could see debug output. I am not sure about using any desk. I can understand issues about posting configuration in a public forum like this. There is a private messaging option in the community. Would that be permissible. 

HTH

Rick

......

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swuncli.html#wpxref73623

 

There are many found but unsupported command in 3500, one of them is PBR default, please see doc. 
if this is the solution just mention that.

Review Cisco Networking for a $25 gift card