Nexus 9k Policy based routing

[balaji.bandi]

I have not tested myself,  how about deny rest of the traffic and allow only IP address you like to do PBR ?

check below example : (just trying to help you- may this not you looking ?)

https://www.letsconfig.com/how-to-configure-pbr-in-cisco-nexus-switches/

[Georg Pauwen]

Hello,

the default route is *via 172.16.1.69, Vlan60, but are there are any more specific routes in the routing table ? Where is the other traffic from Vlan162 supposed to go to ?

Post the output of:

show ip route

[clive.hodgetts]

a

[Georg Pauwen]

Hello,

post the full running config of your Nexus, as well as the output of

'show ip route'

The PBR config looks by the book. so there probably is something else missing...

[clive.hodgetts]

a

[Richard Burts · Accepted solution]

First let us clarify the differences in the first 2 commands:

set {ip | ipv6} next-hop address1 [address2...] [load-share]

This command acts on any IP packet that is a match for the acl used in the match statement (or acts on all traffic if there is not a match command) and forwards the packet to the next hop address(es) specified.

set {ip | ipv6} default next-hop address1 [address2...] [load-share]

This command acts on any IP packet that is a match for the acl used in the match statement (or acts on all traffic if there is not a match command) and which packet would have been forwarded using the default route.

The significant difference is that the second command acts only on traffic which would use the default route. If a packet does match the acl but there is a route in the routing table for the destination then normal routing is used and not PBR.

The third command is a variation of the first command which would be used in situations where the router was using vrf to separate traffic.

If set ip default is not supported on this platform then I would suggest that what you need to do is to modify the acl used for PBR. The early lines in the revised acl would deny any traffic from that source to destinations that are local. Then you would have the line that does permit the source to any destination.

[clive.hodgetts]

Thanks Rick, this is as I thought, but it seems very messy to have to list non contiguous networks, especially when there are so many of them. Luckily this work is related to a migration so is only temporary. I have logged a TAC case with Cisco to try to understand why this platform of Nexus doesn't support the

default next-hop

option whereby it seems most others do!

Thanks, again and I will mark your answer as correct.

[Richard Burts]

First let us acknowledge that getting full feature parity as Cisco introduces new platforms (like the 9K) is a challenge. As they write the code for the new platform do they wait to support a feature until they have all aspects of that feature or do they go ahead and support a feature (like PBR) when they have the most important aspects and try to get other aspects in later releases. Clearly Cisco said partial PBR is good enough. If you have opened a case with TAC about PBR support that certainly gives Cisco feedback that set ip default is part of the feature that they should work on.

Then let me suggest that it may not be as messy as you think. Assuming that the networks for which you want normal routing to work are in the Private address space you may be able to accomplish what you want with 3 additional statements in your acl: deny if the destination network/subnet is in 10.0.0.0, deny if the destination network/subnet is in  appropriate parts of 172.16.0.0, deny if the destination network/subnet is in 192.168.0.0,

[clive.hodgetts]

Hi Rick,

We have amended the ACL's to cover the private address space but we have quite a number of services which do not fall under the private space which still need to take the routes in the routing table. These have been added to the ACL too. We did hit one issue with this and that is that 'deny' is not supported on ACL's being used by PBR. To accomplish what we needed to do, we created an ACL with permit statements for the private addresses and the destination subnets not covered by those statements. This ACL formed the first match in our route-map but we left the 'set' option blank so those would follow the local routing table. We then created an ACL with the single rule permit any and that formed the second match in our route-map with the set next-hop address configured. All has been implemented and tested successfully. As mentioned, it is only a temporary solution to cover the migration of services from one DC to another. 

Thanks for your input and hopefully we will see the full feature set of PBR contained in new versions of 9k code.

[Richard Burts · Accepted solution]

Thanks for the update. Glad that you have it working. I am surprised about the restriction of not allowing deny in an acl for PBR. But if it is not allowed then your solution is certainly appropriate.

Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.