03-11-2017 03:15 AM - edited 03-05-2019 08:10 AM
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
Solved! Go to Solution.
03-12-2017 07:59 AM
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
03-11-2017 08:09 AM
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
03-11-2017 03:01 PM
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
03-12-2017 07:59 AM
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
03-12-2017 05:58 PM
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.
03-13-2017 12:54 PM
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
03-22-2017 04:22 PM
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.
03-23-2017 06:11 AM
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
03-24-2017 04:31 AM
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
06-17-2019 01:12 PM
07-30-2019 01:44 PM
Solution with 2 match do not work on Nexus 3000. Error:
% PBR route-map cannot have more than one sequence in it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide