Reset Search
 

 

Article

Why does applying a policy route-map on a VRF interface fail?

« Go Back

Information

 
TitleWhy does applying a policy route-map on a VRF interface fail?
Question
The router does not allow applying a route-map to an interface if it is a part of a non-default VRF.

Here is a sample configuration and an attempt to apply a route-map to VE 150, which is configured under VRF Test.


access-list 70 sequence 10 permit 192.168.0.0/16
!
route-map PVLAN permit 10
match ip address 70
set ip next-hop 192.168.1.101
!
vlan 550 name PVLAN
tagged e 3/3
router-interface ve 150
!
interface ve 150
ip vrf forwarding VRF_Test
ip address 192.168.1.1/24
ip vrrp-extended vrid 150
backup priority 110
ip-address 192.168.1.3
advertise backup
activate
!
SSH@MLX_02(config-vif-150)# ip policy route-map PVLAN

Error: PBR policy is not supported on VRF interfaces
Environment
Answer
Currently the software supports Policy Based Routing only on the interfaces under the default routing instance (Default VRF). It cannot be applied on a VRF interface - it will display the following error:

Error: PBR policy is not supported on VRF interfaces

Other PBR considerations:

1. PBR can be defined and applied either Globally or per interface. If Global and interface PBR both are applied, then interface takes precedence over a global PBR policy.
2. You cannot apply PBR on a port if that port already has inbound ACLs, inbound ACL-based rate limiting, or TOS-based QoS.
3. PBR Route-map cannot be applied on the VPLS, VLL or VLL-Local endpoints.
4. PBR policies are not supported on the Layer-3 VPNs.
5. The number of route maps that you can define is limited by the system memory.

When a route map is used in a PBR policy, the PBR policy uses up to 200 instances of a Layer 3 route map, up to 5 ACLs in a matching policy of each route map instance.
The following two conditions can cause more than 200 Layer 3 route-map instances to be used.
  1. If one or more of first 200 instances have deny clause.
  2. If the access-list used in the first 200 instances is not configured.
    • ACLs with the log option configured should not be used for PBR purposes.
    • PBRignoresimplicitdenyipanyanyACLentries,toensurethatforroutemapsthat use multiple ACLs, the traffic is compared to all the ACLs. However, if an explicit deny ip any any is configured, traffic matching this clause will be routed normallyusing Layer 3 paths and will not be compared to any ACL clauses that follow this clause.
    • PBR always selects the first next hop from the next hop list that is up. If a PBR policy's next hop goes down, the policy uses another next hop if available. If no next hops are available, the device routes the traffic in the normal way.
    • Any changes to route maps or ACL definitions will be effective immediately for the interfaces where the PBR route map is applied. There is no need to rebind. However, rebinding is required if a change is made to an IPv6 ACL.
    • If a PBR policy is applied globally, inbound ACLs, inbound ACL-based rate-limiting or TOS-based QoS cannot be applied to any port on the device.
    • If an IPv4 option packet matches a deny ACL filter with the option keyword, the packet will be forwarded based on Layer-3 destination. If the ignore-options command is configured on the incoming physical port, the packet will be forwarded based on its Layer-3 destination in hardware, otherwise the packet will be sent to the CPU for software forwarding.
    • If an IPv4 option packet matches a permit ACL filter with the option keyword, it is hardware-forwarded based on its PBR next-hop (if available). If no PBR next-hop is available, the packet is either software or hardware-forwarded (depending on whether ignore-options is configured), based on an IP forwarding decision.
    • Policy Based Routing (PBR) currently does not support the IPv4 and IPv6 features for changing the MTU.
    • Where the next hop is a GRE tunnel:
      • Packets that are larger than the tunnels MTU are subject to IP fragmentation and PBR processing of the fragmented packets.
      • For route changes of the tunnel destination, the appropriate information is automatically propagated to the PBR feature. Depending on the configuration of the route map, a route change can change the active next hop of the PBR if it leads to the active next hop going down which triggers a new next hop selection process.
    • PBR route-map cannot be applied on VPLS, VLL, or VLL-Local endpoints and vice-versa.
    • PBR policies are not supported on Layer-3 VPNs.
    • In a PBR route-map definition, if even one route-map instance contains a "set next-hop-flood-vlan" statement, all instances of that route-map will apply to both routed and switched traffic.
    • Flooding traffic to a POS interface is not allowed. It can only be flooded to Ethernet ports on the VLAN, including the default VLAN.
    • When an incoming port is POS then the SA of the outgoing flooded packets will be 0.
    • IPv6 PBR to flood VLAN is not supported for switched traffic for the Brocade NetIron CES Series and Brocade NetIron CER Series.
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255