Policy Based routing on Nexus 5000

[Vag]

I am trying to apply a route-map on a Nexus 5000 in order to change the default gateway for a specific VLAN.

Normally I would go with using a route map like:

!

route-map CHANGE_GW permit 10

 match ip address MY_VLANS

 set  ip default next-hop 192.168.x.x

!

And while it is possible to write such a route-map on a Nexus, if you try to apply it on a SVI it gives an error message.

So my question is, how can I change the default gateway for that specific VLAN?

NX version 7.1

[Richard Burts]

You have not provided much detail for us to work with. But based on what you have told us so far there are several things that might cause the symptoms that you describe. If it does not turn out to be one of these things then you need to provide additional information.

- Policy Based Routing on N5K requires the Enterprise Services license. Do you have that license on this switch?

- Before you configure PBR you must enable the feature (feature pbr). Have you enabled this on the switch?

You can use this link to find additional details

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/unicast/6_x/cisco_n5500_layer3_ucast_cfg_rel_6x/l3_pbr.html

HTH

Rick

[Vag]

Hi Richard,

The Nexus does have an enterprise license and has the pbr feature enabled. Simple route-maps work, such as:

match ip address ACCESS_LIST

set ip next-hop 192.168.x.x

I have read the doc in the link that you provided above, however as can be seen, it only supports the set next-hop. 

The weird thing is that commands such as set ip default next-hop and match ip route-source do exist and can be used in writing a route-map, but when you try to apply a route-map that has any of those statements to an interface, you get an error message similar to:

% PBR route-map match criteria RPM_MATCH_IP_NHOP_PFL unsupported

Moreover, the ACLs can't have deny statements such as

deny ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.255.255

permit ip any any

so that I could exclude the private IP ranges, permit all other and use the next-hop, because you get a similar error message when you try to apply that route-map.

In short, the support of PBR seems quite limited in the Nexus world, so my question is how can I achieve the same result, which is to change the default gateway for specific VLANs

[Jon Marshall · Accepted solution]

Try using multiple permit statements. So your first permit statement matches all the private IP ranges you do not want to do PBR for but you don't have a set clause. Then your second permit statement catches the traffic you do want to do PBR for.

Note I haven't used PBR this way for a while and have never tried it on a Nexus so not sure whether without a set clause in the first statement it will simply move on to the second statement. I don't think it does but if it does then you would need a set clause in the first statement which matches your default route next hop.

Jon

[Vag]

Thanks Jon,

I was actually thinking something similar. I will use a DENY statement for the RFC1918 destinations, which will result in ignoring those subnets and route by Destination Based Routing (Normal) and then use a PERMIT statement with a match ip any any and set next-hop.

[Richard Burts]

It does appear that PBR on Nexus is a bit more restricted that it is on IOS devices. The strategy of an instance specifying deny and with ACL matching RFC 1918 addresses followed by another instance specifying permit and matching all traffic with a set statement should accomplish what you describe.

HTH

Rick

[Vag]

So the solution is:

ip access-list PBR_DENY
statistics per-entry
10 permit ip any 192.168.0.0/16
20 permit ip any 10.0.0.0/8
30 permit ip any 172.16.0.0/12

ip access-list PBR_PERMIT
 statistics per-entry
 10 permit ip any any

and

route-map PBR_RULE pbr-statistics
route-map PBR_RULE deny 10
 match ip address PBR_DENY
route-map PBR_RULE permit 20
 match ip address PBR_PERMIT
 set ip next-hop 192.168.X.X

The first statement could also be permit (route-map PBR_RULE permit 10). 

Both of them work, the difference is that in the deny case there's no further processing happening and the packets are routed as usual, while in the permit case packets are still being processed.

Note that the counters both on the ACLs and on the route-map do not increase, which makes troubleshooting harder, despite the fact that the options pbr-statistics and statistics per-entry  are in place.

[Richard Burts]

Thanks for the update and confirming that this solution does work. This will be helpful to other readers in the forum.

I am a little confused about your statement about difference between route-map PBR_RULE deny 10 and route-map PBR_RULE permit 10  One statement says that both of them work but then there is a statement that says that with permit that packets are still processed. Can you clarify this?

HTH

Rick

[Vag]

The difference is in resource utilization.

Deny excludes the traffic from being processed by the route-map so it follows the usual route, while in permit case the traffic "gets processed but no action is taken", as there is no set

[keith_gajeski]

Thank you so much! Works perfectly!

[andre]

Solution with 2 match do not work on Nexus 3000. Error:

% PBR route-map cannot have more than one sequence in it.