Policy-Based Routing (PBR)
Policy-Based routing gives network administrators very granular control over their networks. Administrators can control how the traffic flows by source and/or destination, protocol, size of the packet, or even time of day. PBR harness the power of access lists and route maps. PBR is a list of criteria that changes how the packet is routed if it matches the criteria before it is routed by the routing table.
At the point that a Cisco Certificate Candidate is exploring Policy-Based Routing, they have already encountered many different types of routing protocols. If asked to categorize routing protocols, the differences between RIP and OSPF can easily be differentiated by describing distance vector and link state protocols. But they are both dynamic protocols. Policy-Based Routing is a “routing protocol” just as much as static routes are a routing protocol.
A route map is a logic structure that allows very granular control of the flow of traffic. It uses
match statements to define a condition, and
set statements to modify the traffic if the condition is met. These
match statements can be defined using an access list (standard or extended) using the
match ip address <ACL Name/Number>.
If traffic “matches” the access lists, it continues to the
set statements. The
set statements change how the traffic is routed. It is the action preformed if the traffic matches the initial statement.
Our task is to write a network policy that only allows HTTP traffic to route to the HTTP-Responder and HTTPS traffic to go to the HTTPS-Responder. Although both HTTP and HTTPS will be enabled on both routers, only its respective traffic should be routed to it.
- Basic configuration including IP addresses.
- Configure HTTP and HTTPS responders with HTTP servers with secure server and authentication enabled.
- Create access lists for HTTP and HTTPS routes.
- Create a Route-Map to route HTTP and HTTPS traffic using the previously created ACLs.
- Apply the route maps to the interface.
- Verify the configurations.
Configure HTTP and HTTPS Responders
The configuration for both routers are the same except for a null route to prevent re-routing filtered traffic.
The following commands creates a user
admin, enables the HTTP and HTTPS services, and uses local authentication to login to the service (previously created user
admin can login to the server).
username admin privilege 15 secret cisco ip http server ip http secure-server ip http authentication local
The configurations that differ between the two responders is the null route. This route is a fix for the issue outlined in the problems section. It prevents filtered traffic from being re-routed to the other router.
ip route 10.2.2.2 255.255.255.255 null0
ip route 10.1.1.2 255.255.255.255 null0
HTTP and HTTPS Access Lists
These two access lists will
permit all HTTP or HTTPS traffic respectively. Anything permitted by the access lists with fulfill the
match condition in the route-maps.
ip access-list extended HTTP_Route permit tcp any any eq 80 ip access-list extended HTTPS_Route permit tcp any any eq 443
Web_Policy Route Map
The route map will include two sequences for HTTP and HTTPS traffic. One sequence will
match against the HTTP route, and another will
match against the HTTPS route. It will then forward the matching traffic out the correct interface towards the HTTP or HTTPS Responder respectively.
route-map Web_Policy 10 match ip address HTTP_Route set ip next-hop 10.1.1.2 set interface serial 0/0/0 route-map Web_Policy 20 match ip address HTTPS_Route set ip next-hop 10.2.2.2 set interface serial 0/0/1
Apply the Web_Policy to a Interface
We want the traffic to be filtered at the interface closest to the client. In this case, that’s the
FastEthernet0/0 interface. This will only filter traffic on that interface, no other interfaces will be affected.
interface FastEthernet0/0 ip policy route-map Web_Policy
Core#show access-lists HTTP_Route Extended IP access list HTTP_Route 10 permit tcp any any eq www Core#show access-lists HTTPS_Route Extended IP access list HTTPS_Route 10 permit tcp any any eq 443
Core#show route-map Web_Policy route-map Web_Policy, permit, sequence 10 Match clauses: ip address (access-lists): HTTP_Route Set clauses: ip next-hop 10.1.1.2 interface Serial0/0/0 Policy routing matches: 0 packets, 0 bytes route-map Web_Policy, permit, sequence 20 Match clauses: ip address (access-lists): HTTPS_Route Set clauses: ip next-hop 10.2.2.2 interface Serial0/0/1 Policy routing matches: 0 packets, 0 bytes
Core#show ip policy Interface Route map Fa0/0 Web_Policy
Notice traffic is being forwarded to both servers as expected, and traffic that doesn’t match is forwarded as normal.
Core#debug ip policy Policy routing debugging is on IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.1.2, len 52, FIB policy match IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.1.2, len 52, PBR Counted IP: s=192.168.1.2 (FastEthernet0/0), d=10.1.1.2, g=10.1.1.2, len 52, FIB policy routed IP: s=192.168.1.2 (FastEthernet0/0), d=10.2.2.2, len 47, FIB policy match IP: s=192.168.1.2 (FastEthernet0/0), d=10.2.2.2, len 47, PBR Counted IP: s=192.168.1.2 (FastEthernet0/0), d=10.2.2.2, g=10.2.2.2, len 47, FIB policy routed IP: s=192.168.1.2 (FastEthernet0/0), d=192.168.1.255, len 78, policy rejected -- normal forwarding
Click to expand
As mentioned above, route maps can be applied globally or per interface. In this lab, we only applied it on the Fast Ethernet 0/0 interface. This meant HTTP/HTTPS filtering was only occurring on that interface – not on the serial interfaces. This caused HTTPS traffic destined for the HTTP-Responder to get correctly filtered to the HTTP-Responder router, but because its a router, it routed the HTTPS traffic back to the HTTPS-Responder. There are a few ways to resolve this issue.
- Explicitly deny mismatching traffic (HTTP to the HTTPS-Responder and vis versa).
- Apply filters the the Serial interface
- Block traffic between the HTTP-Responder and HTTPS-Responder
This lab used the third option. This is not an optimal option because it blocks all traffic between these two routers. Depending on the application, the best solution would be to modify the Route Map to block mismatching traffic from exiting the Core router.
Policy-based routing gives Network Administrators full control of how traffic is routed in their networks. Although PBR can be used as a way to proxy out different types of traffic, it has many more powerful features that warrant exploration. Future labs might use PBRs to route traffic based on traffic properties and manipulating fields within the packet.