link: route-map Company-1 permit 10 match ip address 101 set interface Serial0/0.109 The second forced traffic destined for Company 2's HQ network over Company 2's link: route-map Company-2 permit 10 match ip address 102 set interface Serial0/0.209 Policy-Routing Example With the route maps created, we needed to apply them to the interfaces. This was done with the ip policy interface command. Some fall-through logic was used here. We knew that Company 1's users' packets headed to Company 1's headquarters would route properly without alteration, as would Company 2's users' packets headed to Company 2's headquarters. The only time we needed to interfere was when either company's users accessed a server at the other company's headquarters-then, and only then, we needed to force the packets to take the other link. To accomplish this, we applied the Company-2 route map to the Company 1 Ethernet interface, and vice versa. This was done on the Branch-9 router: interface FastEtherneto/o description <[ Company-1 Users ]> ip address 10.109.0.1 255.255.255.0 ip policy route-map Company-2 half-duplex interface FastEtherneto/1 description <[ Company-2 Users ]> ip address 10.209.0.1 255.255.255.0 ip policy route-map Company-1 half-duplex Policy routing takes place when a packet is received on an interface. For this reason, the policy must be placed on the Ethernet interfaces. Monitoring Policy Routing Once policy routing is configured, how do you know it's working? In the preceding source-routing example, we altered the way that packets routed, but the IP routing table didn't change. Normally, we would look at the routing table to determine where a router is sending packets, but with policy routing in place, the routing table is no longer the most reliable source of information. Policy routing overrides the routing table, which can be confusing when troubleshooting routing problems. If your packets are not rout- ing the way you expect them to, check for policy routing on your interfaces. To see what policies are applied to wha