I think what Op is saying "cannot have a route-map and a ACL co-existing on the same Interface in the ICX world."
This is not exactly true, but there are constraints pertaining to direction etc... on both the ICX platform and Cisco, too.
Please correct me if I am wrong reading any of this because I am making a lot of assumptions trying to read-between-the lines for what most of it does and what the it is intended to do. This is most likely not an actual working configuration snippet from a Cisco switch in that I do not think it does what the Op intends it to do...
Where a normal static-route is GET TO: Network/Mask via Next-Hop (taking no consideration where the traffic is sourced from), generally route-maps are extended ACLs; since they are often used to match the source... making them more useful than simple static routing tables for certain complicated tasks.
This is referred to as Policy-Based-Routing (PBR).Looking at this:http://docs.ruckuswireless.com/fastiron/08.0.90/fastiron-08090-securityguide/GUID-8D819DAB-C84F-4339...
- PBR is not supported together with ingress ACLs on the same port.
This is indicating you cannot have an access-group ### in and an
ip policy route-map on the same port.
This does not mean you cannot achieve your Goals on the ICX7750 though!
If I look at OPs VLAN 1 it is an SVI with assigned IP 10.10.1.1/24 serving as the default-gateway of that VLAN. This makes a directly-connected route for 10.10.1.0/24 in the default routing table (since no ip VRF details are available).
Then the OP is doing an ip next-hop (not an ip default net-hop), so op is preempting the routing table for what otherwise would be a directly connected route for 10.10.1.0/24
Specifically, OPs route-map is overriding the routing table for everything with the permit ip any any statement... except that which is denied first not being processed by the route-map...Looking at the ACL for OPs route-map:
access-list 151 deny ip 10.10.1.0 0.0.0.255 10.10.0.0 0.0.255.255
access-list 151 permit ip any anyOP Probably Intends:
deny subnet 10.10.1.0/24 to 10.10.0.0/16 (anything internal)
permit anything else (i.e. let it get to the Internet)Intended Outcome: For devices that attempt to communicate internally with inter-VLAN routing send the next-hop to some other device (that probably does not exist being each IP is different (10.10.1.254, 10.10.2.254, etc.) Op is setting the next-hop)
. Do not interfere otherwise (i.e. traffic to Internet)
If this was the intent, I probably would have written it more as:
access-list 151 deny ip any 10.10.0.0 0.0.255.255
access-list 151 permit ip any any
This is because any traffic going out from VLAN 1 will be sourced from 10.10.1.x. If someone sets the IP wrong the default-gateway won't be on its same subnet, so it won't be found, and even if it was, the traffic wouldn't come back. Hence I changed 10.10.1.0 0.0.0.255 to any above.****However, I suspect the route-map ACLs have the permits and denies backwards
on the Cisco side, too if my understanding of what the OP is trying to do is allow Internet Traffic but no local traffic.
Simply put for something to be routed via PBR using a route-map it must be Permitted in. That is denying does not drop the traffic like it would if applied as an access-group but rather denied entries are not policy routed. It is best to think of ACLs as being processed top to bottom, and once a match is hit the list stops processing. If it matches a Permit, it returns a True (Boolean) and if it matches a Deny it returns False (Boolean). This is much more important a concept when dealing with QoS an Class-Maps which have Boolean operators such as AND or OR can be used to have multiple criteria to allow something into a Class.
There is also an implicit deny if no matches are made the processing terminates returning FALSE, so there is really no need to end with something like deny ip any any.,For a simple route-map that overrides the default routing table for anything internally but does not impact anything else like traffic to the Internet the statement would be succinctly written something more like:
access-list 151 permit ip any 10.10.0.0 0.0.255.255
route-map Internet-Vlan1 permit 10
match ip address 151
set ip next-hop 10.10.1.254
ip address 10.10.1.1 255.255.255.0
ip policy route-map Internet-Vlan1
************************This does not seem right on the Cisco side either:
ip access-group 101 in
ip address 10.10.1.1 255.255.255.0
access-list 101 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255
access-list 101 deny ip any any
Reasoning, this is a Layer-3 SVI (Interface). How could something externally be coming into the Interface sourced from the Inside?
Devices within VLAN 1 will presumably already be addressed 10.10.1.x/24 and external devices would be sourced from different subnets. Internal devices will not hit the SVI for internal communications; since, they are on the same Layer-2, so this does not provide any internal controls if that is what you are attempting.
To get the SVI involved, something must come from VLAN 1 sourced from 10.10.1.x/24 and destined to some other subnet. Then the device will actually forward to its default gateway 10.10.1.1 at which point, ACLs and route-maps can be applied.
If you are trying to impose internal controls, please check out PVLANS:
I am not even certain Policy-Based-Routing is appropriate for this use case in that they are generally not used to break routing tables to stop traffic.
Access lists should most likely be extended ACLs controlling outbound traffic anyway... In which case if you do need to combine them with route-maps on the ICX they should work.
If you are trying to accomplish a specific use case, please let us know, and I am sure someone can hammer out a snippit of the ICX configuration for you.