aces to prevent interaction between the two networks. This design is an excellent example of politics and money trumping best-practice engineering. Still, our job was not to judge, but rather to make the network function the way the client wanted it to function. To further complicate the issue, each company insisted that its employees should only use the frame-relay link that that company had purchased. The problem with this mandate was that each company's branch employees used servers at both com- panies' headquarters. In other words, if a Company 1 user at Branch #9 needed to use a server at Company 2's headquarters, that user was not allowed to use the link that connected Branch #9 to Company 2. Instead, he was to use the link provided by Company 1, SO that Company 1 could route (and attempt to secure) the request across the DS3 link between the two companies' headquarters. This needed to be done across more than 300 branches, all of which were configured the same way. We were not allowed to add hardware. Here is the routing table from the Branch-9 router: Branch-9# sho ip route [ - text removed - ] 172.16.0.0/24 is subnetted, 2 subnets 172.16.201.0 is directly connected, Serial0/0.209 172.16.101.0 is directly connected, Serial0/0.109 10.0.0.0/24 is subnetted, 4 subnets 10.109.0.0 is directly connected, FastEtherneto/0 10.101.0.0 [90/2172416] via 172.16.101.1, 00:16:02, Serial0/0.109 10.201.0.0 [90/2172416] via 172.16.201.1, 00:16:06, Serial0/0.209 10.209.0.0 is directly connected, FastEthernet1/0 As you can see, the routing protocol (EIGRP, in this case) is doing what it is designed to do. The network 10.101.0.0/24 is available through the shortest path-the direct link on S0/0.109 The 10.201.0.0/24 network is similarly available through the short- est path, which is found on SO/0.209. The problem is that routing is based on destination addresses. When a user on either of the locally connected Ethernet networks wants to get to either of the companies' HQ networks, the router doesn't care where the packets orig