ce. The problem was that I had to go to the CIO and report that my assumed cost savings were impossible and that we now needed routers. CIOs love to be told that the networking team needs more money. Once we had the right equipment, we still had another issue that we hadn't thought about, and it was, once again, a speed discrepancy problem. Providers often provide an Ethernet handoff by putting a device on your premises that has OC3 (in this case) on one side and Gigabit Ethernet on the other. The issue is that you'll be sending packets to this device at one billion bits per second, while the OC3 can only send them at 155 million bits per second. As with the Frame Relay scenario outlined in the Chapter 31, the OC3 interface will only queue SO many packets before it drops them, and with an oversubscription rate of 10:1.5, it will probably drop a lot of packets. The solution was to traffic-shape the data coming out of the Gigabit Ethernet link on our side, thus slowing down the relevant data stream SO the OC3 could receive (and then send) it. The first step is to create a policy map. This is a very simple policy map, since there are no other CoS or QoS statements involved. There are a lot of options and a lot of ways to make a mess of this, but all we really need to do is tell the interface that we're going to shape average with the desired rate, applied to the default class: policy-map Provider-Outbound description [ -- [ For 150M Ethernet Handoff ]--] class class-default shape average 150000000 If you want to add other CoS commands, you must place them after the shape aver age command. If you place them before, the CoS will be applied before traffic shaping occurs, and you'll end up dropping your prioritized packets when the 155 Mbps buffer gets overrun with 1 Gbps packets. Luckily, policy maps can cascade, SO we can apply them beneath the class-default class. I actually did something similar in Chapter 30 when I applied QoS to a subinterface: policy-map Provider-Outbound description [ [ For 150M Ethernet Handoff