Below lists other general usages of PBR:
Source-based transit provider selection – Organizations can use PBR to route traffic originating from different sets of users through different Internet connections.
Quality of Service (QoS) – Organizations can provide QoS upon differentiated traffic by setting Type of Service (ToS) or IP Precedence values in the IP packet header on edge routers and use queuing mechanisms to prioritize traffic in the network core or backbone.
Cost savings. Organizations can temporary direct the bulk traffic associated with specific application to use a higher-bandwidth, high-cost link for a short period of time and resume basic connectivity over a lower-bandwidth, low-cost link for interactive traffic.
Load sharing. Organizations can distribute traffic among multiple paths based on the characteristics of the applications in addition to the dynamic load-sharing capabilities offered by destination-based routing that the Cisco IOS software has always supported.
PBRs are applied upon incoming packets. Enabling PBR causes the router to evaluate all packets arriving on the interface configured with a route map for that purpose. Packets are being processed by the data plane and forwarded to the appropriate next-hop based on the criteria defined in the route map; and therefore override the normal packet forwarding of the router.
Most Cisco routers today use Cisco Express Forwarding (CEF) by default, which causes them to match the destination address of IP packets with the CEF table instead of the IP routing table. Cisco IOS derives the CEF table from the information in the IP routing table, with much faster entry lookup as compared with using the IP routing table.
Implementing PBR is basically configures a route map and applies the route map to an interface. The PBR route map statements can be configured with permit or deny actions.
If the action of the statement is permit, a packet that meets the match criteria is being policy routed according to the set actions.
If the action of the statement is deny, a packet that meets the match criteria is not being policy routed and is forwarded through the normal destination-based routing.
If a packet is not matched by any route map statement, it is not dropped implicit deny statement; it is being forwarded through the normal destination-based routing.
If do not want to revert to the normal destination-based routing but instead want to drop all packets that are not being matched by any criteria, configure the set interface Null0 action as the last entry of the route map.
If a packet meets the match criteria of a permit statement with no set action, it is being forwarded through the normal destination-based routing.
Policy routing does not change the destination of the traffic; it affects only the next hop to which traffic is directed prior to arrive upon the final destination.
Below lists the match commands that matter when using route maps for PBR:
| match ip address {[acl-num | acl-name] | prefix-list {ip-prefix-name}} | Matches incoming packets that matched by the access list or prefix list. If multiple access lists or prefix lists are specified, matching any one will result in a match and being policy routed. Standard IP ACLs are used to specify match criteria based on source address; while extended IP ACLs are used to specify match criteria based on source and destination addresses, protocol types, applications, ToS, and IP Precedence. |
| match length {min max} | Specifies match criteria based on the packet length between the min and max values (inclusive) in bytes. The min and max values are from 0 to 2147483647 (inclusive). Time-sensitive interactive traffic often uses small packets. They can be directly to another link to prevent the terminal sessions from starving the bandwidth resources with bulky traffic that uses large packets (file transfers). |
One or more of the following set actions can be specified within a single match statement to perform customized packet forwarding requirement when the match statement is satisfied. A router evaluates the following set actions applicable for PBR in the order they are presented. As soon as a destination next-hop address or interface has been chosen, other set actions that changing the destination next-hop address or interface are ignored.
One or more of the following set actions can be specified within a single match statement to perform customized packet forwarding requirement when the match statement is satisfied. A router evaluates the following set actions applicable for PBR in the order they are presented. As soon as a destination next-hop address or interface has been chosen, other set actions that changing the destination next-hop address or interface are ignored.
| set ip next-hop {ip-addr} [… ip-addr] | Specifies a list of IP addresses of the adjacent next-hop routers to which the packets should be forwarded. It must be the IP address of an adjacent router. When multiple IP addresses are specified, the first IP address associated with an active interface is used; the other IP addresses are tried in turn. [1] |
| set interface {intf-type intf-num} [… intf-type intf-num] | Specifies a list of interfaces through which the packets can be routed. When multiple interfaces are specified, the first active interface is used to forward the packets; the other interfaces are tried in turn. [1] |
| set ip default next-hop {ip-addr} [… ip-addr] | Same logic as the set ip next-hop action; however, policy routing is applied only after attempted to route the packet using the normal destination-based routing. |
| set default interface {intf-type intf-num} [… intf-type intf-num] | Same logic as the set interface action; however, policy routing is applied only after attempted to route the packet using the normal destination-based routing. |
The default keyword significantly impacts the operation of PBR. Without this keyword configured, Cisco IOS applies PBR before trying to use the normal destination-based routing; with this keyword configured, Cisco IOS applies PBR logic only after trying to use the normal destination-based routing and no explicit route for the destination existing in the routing table. A default route is not considered as an explicit route for an unknown destination address.
Without the default keyword – Try PBR first; but if the PBR route fails, route as usual.
With the default keyword – Try to route as usual while ignoring any default route; if normal routing fails, use PBR.
The set interface action has no effect and is ignored if the packet is destined to a broadcast or an unknown address. This is because there is no explicit route for the destination address of the packet exists in the routing table.
PBR also provides a mechanism to mark packets using the following commands:
| set ip tos [number | name] | Sets the 8-bit IP ToS field in the IP packet header. |
| set ip precedence [number | name] | Sets the IP Precedence bits in the IP packet header. |
In the 8-bit IP ToS field, the 5 least-significant bits are used for setting the Class of Service (CoS); while the 3 most-significant bits are used for setting the IP Precedence – 8 possible values (0 – 7). IP Precedence is often being used when implementing QoS services, eg: Weighted Fair Queuing (WFQ) and Weighted Random Early Detection (WRED).
Below lists the numbers and names defined for the corresponding ToS and IP Precedence values:
Title:
| 0 | normal | Sets the normal ToS. |
| 1 | min-monetary-cost | Sets the min-monetary-cost ToS. |
| 2 | max-reliability | Sets the max reliable ToS. |
| 4 | max-throughput | Sets the max throughput ToS. |
| 8 | min-delay | Sets the min delay ToS. |
| 0 | routine | Sets the routine precedence. |
| 1 | priority | Sets the priority precedence. |
| 2 | immediate | Sets the immediate precedence. |
| 3 | flash | Sets the Flash precedence. |
| 4 | flash-override | Sets the Flash override precedence. |
| 5 | critical | Sets the critical precedence. |
| 6 | internet | Sets the internetwork control precedence. |
| 7 | network | Sets the network control precedence. |
The ip policy route-map {map-tag} interface subcommand specifies a route map to use for policy routing on an interface. Policy-based routing is configured on the receiving interface, not on the outgoing interface from which the packets are sent.
Occasionally it may be necessary to use PBR to process packets originated by the router itself. However, such packets are not being processed and policy routed by the ip policy route-map interface subcommand, as the packets originated by the router itself do not actually enter the router through any interface. The ip local policy route-map {map-tag} global configuration command enables local policy routing to process locally originated packets using the PBR. The IP SLA section later shows an example use of this command. IP SLA causes a router to generate packets, applying PBR to such packets influence the forwarding paths of these packets.
Network Setup for Policy-Based Routing
The sample network above demonstrates the PBR configuration for the following requirements:
EIGRP is running on RT1 and RT2. Therefore the primary path between 192.168.0.0/16 and 172.16.1.0/24 is via 11.11.11.0/30.
Packets sent between 192.168.2.0/24 and 172.16.1.0/24 are routed via 22.22.22.0/30.
Packets smaller than or equal to 100 bytes are routed via 22.22.22.0/30.
Other packets are routed normally via the primary path.
Note that small ping packets sent between PC1, PC2, and RT1 are actually being policy routed! Besides that, there is a chance that the EIGRP Hello packets between 11.11.11.1 and 11.11.11.2 are also being policy routed, which will cause the flapping of EIGRP neighborship between RT1 E0/1 and RT2 E0/1. This symptom was seen on Cisco IOS Release 12.4(T) used for the IP SLA network setup later but was not seen on Cisco IOS Release 12.3 used for the network setup above. The configuration above will be enhanced to eliminate the mentioned problems.
Below shows that PC1 sends 5 ping packets that are being policy routed via 22.22.22.0/30:
PC1#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/78/88 ms PC1# ---------------------------------------------------------------------- RT1#clear route-map counters RM-PBR RT1# RT1#debug ip policy Policy routing debugging is on RT1# 00:12:36: IP: s=192.168.1.2 (Ethernet0/0), d=172.16.1.1, len 100, FIB policy match 00:12:36: IP: s=192.168.1.2 (Ethernet0/0), d=172.16.1.1, g=22.22.22.2, len 100, FIB policy routed --- output omitted --- RT1# RT1#sh route-map route-map RM-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 101 Set clauses: ip next-hop 22.22.22.2 Policy routing matches: 0 packets, 0 bytes route-map RM-PBR, permit, sequence 20 Match clauses: length 1 100 Set clauses: ip next-hop 22.22.22.2 Policy routing matches: 5 packets, 570 bytes RT1#The show route-map {map-name} EXEC command displays configured static and dynamic route maps along with their match, set, and continue clauses.
Below shows that PC1 sends 5 ping packets that are not being policy routed via 22.22.22.0/30:
PC1#ping 172.16.1.1 size 101 Type escape sequence to abort. Sending 5, 101-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/56/92 ms PC1# ---------------------------------------------------------------------- RT1# 00:13:42: IP: s=192.168.1.2 (Ethernet0/0), d=172.16.1.1, len 101, FIB policy rejected(no match) - normal forwarding --- output omitted ---
Below shows that all packets from PC2 are being policy routed via 22.22.22.0/30:
PC2#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/61/80 ms PC2# ---------------------------------------------------------------------- RT1# 00:14:18: IP: s=192.168.2.2 (Ethernet0/0), d=172.16.1.1, len 100, FIB policy match 00:14:18: IP: s=192.168.2.2 (Ethernet0/0), d=172.16.1.1, g=22.22.22.2, len 100, FIB policy routed --- output omitted --- ====================================================================== PC2#ping 172.16.1.1 size 101 Type escape sequence to abort. Sending 5, 101-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 44/79/100 ms PC2# ---------------------------------------------------------------------- RT1# 00:14:50: IP: s=192.168.2.2 (Ethernet0/0), d=172.16.1.1, len 101, FIB policy match 00:14:50: IP: s=192.168.2.2 (Ethernet0/0), d=172.16.1.1, g=22.22.22.2, len 101, FIB policy routed --- output omitted --- RT1# RT1#sh route-map route-map RM-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 101 Set clauses: ip next-hop 22.22.22.2 Policy routing matches: 10 packets, 1145 bytes route-map RM-PBR, permit, sequence 20 Match clauses: length 1 100 Set clauses: ip next-hop 22.22.22.2 Policy routing matches: 5 packets, 570 bytes RT1#
The show ip policy EXEC command displays the route maps used for policy routing:
RT1#sh ip policy Interface Route map Ethernet0/0 RM-PBR RT1# ====================================================================== RT2#sh ip policy Interface Route map local RM-PBR Ethernet0/0 RM-PBR RT2#
No comments:
Post a Comment