When I first encountered PBR, I understood it mainly as source-based routing as opposed to the usual destination-based routing. The usual forwarding process on routers conceptually does a look-up in the routing table for the destination address in the packet and uses the next-hop information it gets from the routing table to pass the packet onwards towards its destination. The routing table itself is primed by information exchanged by routing protocols or via static routes. (In fact, it is useful to think of even static routes and connected routes themselves as special cases of routing protocols.)
However with PBR, this process is changed because the source address of the packet can affect the handling of the packet. In effect, with the usual packet forwarding scheme all variables other than the destination address of the packet are dont-cares while with PBR those other variables stop being dont-cares. So for instance, PBR would allow a router to forward all packets with the destination address D to be forwarded via interface serial0 except when those packets were some specific source address S in which case the packets would be forwarded to interface serial1. Thus, the forwarding process becomes sensitive to the source address.
Actually, thinking of PBR as mainly source-based or source-sensitive routing is limiting because using PBR one could also make it sensitive to a number of other variables like the length of the packet, any layer4 information in the packet, whether the packet is of a particular protocol type etc. The way these variables are selected and caused to affect the forwarding process is done via route maps.
In some recent reading I realized that there was another way to look at PBR. As with all things, multiple ways of looking at something results in a better understanding of the concept at hand. The other way to look at PBR is to think of it as a powerful static route -- static routes on steroids. Just as static routes define how packets destined prefixes will be handled, PBR specified how packets that match certain criteria will be handled. It is just that the criteria include destination addresses as with static routes but also include much more. Also, just as a static route by virtue of its low administrative distance will override any routes that may be learnt for the same prefix via some routing protocol, PBR specified policies will override what the routing table lookup might have specified for that destination prefix. This way of looking at PBR allows one to understand PBR as a generalization of the idea of static routes.
The generalized nature of PBR causes some representational difficulties w.r.t displaying the semantics of PBR configuration. The effect of a static route is clearly discernible just by looking at the routing table via the "show ip route" command. However, it is not possible to see the effect of PBR simply by looking at the routing table. The very general nature of PBR causes it to be a bit difficult to capture the effect of the PBR configuration on a running system simply by some output from a show command. To see how the PBR configuration would affect the traffic flow, one needs to mentally parse the configured route maps and see which interfaces the policy routing is applied to and then think of the effect on the traffic flow depending on variables like source and destination addresses, source and destination ports, packet lengeth etc in the packet stream. The fact that the multi-variate nature of what PBR deals with makes it hard to display the effect of PBR via show command output is akin to the difficulty of representing and visualizing n-dimensional space for values of n greater than 3.
However with PBR, this process is changed because the source address of the packet can affect the handling of the packet. In effect, with the usual packet forwarding scheme all variables other than the destination address of the packet are dont-cares while with PBR those other variables stop being dont-cares. So for instance, PBR would allow a router to forward all packets with the destination address D to be forwarded via interface serial0 except when those packets were some specific source address S in which case the packets would be forwarded to interface serial1. Thus, the forwarding process becomes sensitive to the source address.
Actually, thinking of PBR as mainly source-based or source-sensitive routing is limiting because using PBR one could also make it sensitive to a number of other variables like the length of the packet, any layer4 information in the packet, whether the packet is of a particular protocol type etc. The way these variables are selected and caused to affect the forwarding process is done via route maps.
In some recent reading I realized that there was another way to look at PBR. As with all things, multiple ways of looking at something results in a better understanding of the concept at hand. The other way to look at PBR is to think of it as a powerful static route -- static routes on steroids. Just as static routes define how packets destined prefixes will be handled, PBR specified how packets that match certain criteria will be handled. It is just that the criteria include destination addresses as with static routes but also include much more. Also, just as a static route by virtue of its low administrative distance will override any routes that may be learnt for the same prefix via some routing protocol, PBR specified policies will override what the routing table lookup might have specified for that destination prefix. This way of looking at PBR allows one to understand PBR as a generalization of the idea of static routes.
The generalized nature of PBR causes some representational difficulties w.r.t displaying the semantics of PBR configuration. The effect of a static route is clearly discernible just by looking at the routing table via the "show ip route" command. However, it is not possible to see the effect of PBR simply by looking at the routing table. The very general nature of PBR causes it to be a bit difficult to capture the effect of the PBR configuration on a running system simply by some output from a show command. To see how the PBR configuration would affect the traffic flow, one needs to mentally parse the configured route maps and see which interfaces the policy routing is applied to and then think of the effect on the traffic flow depending on variables like source and destination addresses, source and destination ports, packet lengeth etc in the packet stream. The fact that the multi-variate nature of what PBR deals with makes it hard to display the effect of PBR via show command output is akin to the difficulty of representing and visualizing n-dimensional space for values of n greater than 3.
