ies, SO these don't need a lot of bandwidth. 64 Kbps should be more than enough, and we can allocate this amount without impacting other protocols: Telnet/SSH-64 Kbps HTTP to and from 10.10.100.100 is a critical app on our network, SO we'll give it a siz- able chunk of bandwidth. Let's say during our discovery process http traffic hovered at around 300 Kbps. We'll plan for growth, and allocate 384 Kbps: HTTP to/from 10.10.100.100-384 Kbps Email is prioritized only to appease the executives, SO we'll allocate it a small amount of bandwidth. 128 Kbps should give it enough bandwidth to function while still leaving plenty for other applications: Email (SMTP, POP, IMAP, Exchange)-128 Kbps The default queue will be allocated the remaining amount of bandwidth after the other queues are considered. Assuming a T1 at 1544 Kbps, and the queues we've decided upon, we get the following results: 1544 - (148 + 30 + 64 + 384 + 128) = 754 Kbps. So, the final element will be: Everything else (default-best effort)-remainder (754k) Chapter 30: Designing a QoS Scheme Our final list looks thus like this: Voice RTP-priority queue-148 Kbps Voice control-30 Kbps Telnet/SSH-64 Kbps HTTP to/from 10.10.100.100-384 Kbps Email (SMTP, POP, IMAP, Exchange)-128 Kbps Everything else (default-best effort)-remainder (754 Kbps) Configuring the Routers We've done all of our discovery and planning. Now, it's time to get to the meat of the exercise: configuring the routers. For this implementation, we're going to config- ure QoS on the edge routers that connect the T1 to the individual buildings. We will do marking, classification, and policing on the same device, but remember that these steps can be separated onto discrete devices as needed. VoIP phones will usually mark their packets, SO we'll assume that they're doing SO on our network. To configure LLQ, we need to configure three things: class maps, policy maps, and service policies. Class Maps We need to identify what packets should be marked. To do this, we will create class maps, which will matc