Chainring Circus

This lab is very similar to the NBAR Fun posting a few weeks back.

Here is a copy of all of the configuration files, both initial and completed.

The server at 192.168.34.234 is running a webserver, tftp server, sshd, telnetd and iperf on port 9100 to emulate an HPJD printer.

The path for most packets will be R4 Fa0/0 -> R1 Fa0/0 -> R1 S0/0 -> R2 S0/0 -> R2 S2/1 -> R3 S2/1 -> 192.168.34.234. It will be done with both the traffic generator and from the command line on the routers.

Below is a graphic for the lab, click here for a better image.

To prepare for this lab only turn on one 800K link between R1 and R2, the serial link between R2 and R3 and the ethernet link for 192.168.34.3 on R3.

On R1:
• Add tcp port 9100 as a custom protocol called jetdirect in NBAR. One of my routers had it, the other did not.
• On the interface going to R2, S0/0, classify the traffic using NBAR.
• Make a class-map named cmap-jetdirect for printing traffic using the custom protocol.
• Make a policy-map named limit-jetdirect and apply it to S0/0 on R1 that includes the class-map from above.

On R2:
• Add tcp port 9100 as a custom protocol in NBAR if needed.
• Make a class-map named cmap-jetdirect using the custom protocol.
• Make a class-map named cmap-http for HTTP traffic with a regular expression matching the word msi.
• Make a policy-map named limit-drop and apply it to S0/0 on R1 that includes the class-maps from above and limits printing to 40Kbps.

Notes:
• Make sure to run sh queue before and after the configuration on the routers.
• You may or may not have the jetdirect service/protocol defined in NBAR.
• Make sure to run sh ip nbar protocol-discovery after applying the routing policy.

R1 starting configuration:

R2 starting configuration:

R3 starting configuration:

Last night I started working through the meat of the ONT lab work book and once again I am disappointed with a CCNP lab workbook. At this point my expectations should be sufficiently lowered that the workbooks should meet them, however, it seems I keep reaching new lows. Who knows, I guess a $50 lab book is just not enough money to expect quality labs. As a result I’m going to post the labs I have decided to write for myself. I posted my BSCI labs over at CLN but this time I’m going to post them on this blog. Hopefully this will help someone else, even though there is so little time left to take this test.

Let me explain the design of my topology. If you have the CCNP ONT Lab Portfolio then you will recognize most of this topology. I have added more choke points and changed the IP addressing scheme because it makes more sense to me.

R4 is the traffic generator and sends traffic to R1 over ethernet. This allows the largest pipe of traffic to be the generated traffic and means the first choke points are the serial interfaces out of R1. I will most often use the 800Kpbs lines to R2 because that provides me with a second choke point on R2, coming from the 800Kbps serial lines to 128Kbps serial lines. That gives me more chances to play with different queuing techniques and classification structures.

Here are the diagrams of what I am using for the lab.

The ethernet wiring diagram, click here for a better view.

Below is the serial wiring diagram, you can click here for a better view.

The server at 192.168.34.234 is running a webserver, tftp server, sshd, telnetd and iperf on port 9100 to emulate an HPJD printer.

The path for most queries will be R4->R1->R2->R3->192.168.34.234. It will be done with both the traffic generator and from the command line on the routers.

Lab 1 — NBAR
Lab 2 — FIFO and WFQ on serial links
Lab 3 — Priority Queuing
Lab 4 — Round Robin
Lab 5 — Weighted Fair Queuing (WFQ)
LAB 6 — Class-Based Weighted Fair Queuing (CBWFQ)
Lab 7 — Low-Latency Queuing (LLQ)

The difference between classification and marking is action. Classification tools categorize packets while marking changes packet headers. These tools lay the foundation upon which the rest of QoS is built.

Classification — Perform classification closest to the source as possible is the most efficient use of network resources.

Marking — Marking is performed after classification, how it is marked depends upon the layer.

Layer 2 Marking:

• CoS — Used on ISL or 802.1Q header
• EXP — MPLS header
• DE — Frame relay header
• CLP — ATM cell header

Layer 3 Marking:

• IP Precedence — RFC 791, first 3 bits of the ToS byte.
• DSCP IP Header — RFC 2474 and 2475, first 6 bits of the ToS byte.

Layer 2 Class of Service (CoS):

Ethernet frame 802.1Q/P uses the 3 bits from the PRI field, which make up 8 possible values.

Frame relay uses the discard eligible (DE) bit to tell a router whether the frame can be dropped, 1 == discard eligible, 0 == should not be dropped.

ATM cells has the cell loss priority field, 1 == discard eligible, 0 == should not be discarded.

Layer 2 1/2:
MPLS packets have the EXP field within the MPLS header which is compatible with the 3 bit PRI/CoS field of the 802.1Q header. The CoS field can be copied into the MPLS EXP field or, a service provider can designate their own EXP value, leaving the customer’s intact in the IP header field.

Layer 3:
RFC 791 called the 3 most significant bits of the ToS byte the IP Precedence bits. It was the predecessor to Differentiated Services Code Point (DSCP) which uses 6 bits of the ToS byte to classify traffic, the remaining two bits of DSCP are for Explicit Congestion Notification (ECN).

DSCP is backward compatible with IP Precedence, however, it has more options for classification.

Because DiffServ does not signal along the path like IntServ, each hop has it’s own behavior based upon the DSCP which are called Per-Hop Behaviors (PHB).

DSCP defines four PHBs:

• Class selector PHB — The 3 least significant DSCP bits set to 000, provides backward compatibility with ToS based IP Precedence.
• Default PHB — The 3 most significant bits set to 000, this is best effort or when a packet has not been marked.
• Assure Forwarding (AF) PHB — Defines four queues with reserved bandwidth for each queue. When congestion occurs for a queue packets are dropped to avoid tail drop based on their drop precedence. Lower AF drop precedence provides better QoS within each AF class.

  	Low Drop Probability Within Class	Medium Drop Probability within Class	High Drop Probability within Class
  	Name/Decimal/Binary	Name/Decimal/Binary	Name/Decimal/Binary
  Class 1	AF11 / 10 / 001010	AF12 / 12 / 001100	AF13 / 14 / 001110
  Class 2	AF21 / 18 / 010010	AF22 / 20 / 010100	AF23 / 22 / 010110
  Class 3	AF31 / 26 / 011010	AF32 / 28 / 011100	AF33 / 30 / 011110
  Class 4	AF41 / 34 / 100010	AF42 / 36 / 100100	AF43 / 38 / 100110

• Expedited Forwarding (EF) PHB — Provides low delay service to packets with the DSCP field set to 101110 or a decimal value of 46.

QoS Service Class

1. Identify network traffic and its requirements.
2. Divide traffic into classes.
3. Define QoS policies for each class

Cisco recommended mappings between CoS, DSCP IP precedence markings:

Trust Boundaries — The trust boundary is the perimeter where you classify data and do not reclassify QoS markings after that point. The trust boundary should be as close to the source as possible taking into account the ability of the device.

Network Based Application Recognition (NBAR):
NBAR has some built in traffic recognition and can expand the number of packets it recognizes by using Packet Description Language Models (PDLMs) published by Cisco.
Can be used for:

• Protocol discovery — Used to learn and report on the types of traffic passing through an interface. NBAR uses subport classification, it looks into the payload of the packet and classifies based on content.
• Traffic classification — NBAR can use deep packet inspection to classify traffic based on URL, MIME type or hostname.
• Traffic statistics collection — NBAR reports traffic statistics by protocol as shown below:
  circus-rtr#sh ip nbar protocol-discovery
  
   GigabitEthernet0/1/0
                              Input                    Output                  
                              -----                    ------                  
     Protocol                 Packet Count             Packet Count            
                              Byte Count               Byte Count              
                              5min Bit Rate (bps)      5min Bit Rate (bps)    
                              5min Max Bit Rate (bps)  5min Max Bit Rate (bps)
     ------------------------ ------------------------ ------------------------------
     secure-http              45804031                 51160464                
                              14439692115              45672201126            
                              2000                     1000                    
                              5249000                  2207000                
     http                     426396714                578778999              
                              54201282821              812650380836            
                              2000                     372000                  
                              4309000                  3087000                
     ftp                      689880                   771488                  
                              467904677                812190544              
                              0                        0                      
                              802000                   1798000                
     ssh                      71666                    95757                  
                              11923882                 103359890              
                              0                        0

NBAR Limitations:

• Cannot function on Fast Etherchannel logical interface.
• Can only handle 24 concurrent URLs, hosts or MIME types.
• Only analyzes the first 400 bytes of a packet.
• Only supports CEF.

Commands to implement NBAR:

If you read my SLA Labbing post ealier you know that we were having trouble graphing Cisco SLA output in MRTG. The problem was the the MIB was not returning information that made graphable sense to MRTG. Which is when I got involved to write a script that would help us out.

This is how you would download snmp data from your router:

And to make it more MRTG friendly:

Regardless, I abandoned this when our graphs were not that helpful and moved on to another format. This script and resulting graph show the ping and http download speed to the web server in question. I realize there is a considerable amount of application latency built in, and the graphs also confirm this. Remember, Cisco sla takes great pains to eliminate the upper layer latency.

You can download this script in .tar or .pl. I have removed the perldoc formatting from the script below so that it renders properly.

This is the resulting output from the script and MRTG configuration.

Over the last few days here at the Circus we have been playing around with trying to test our service level agreements (SLA). It came about because one of our off-campus sites was having connectivity issues and were extremely vocal in their complaints, squeaky wheel and all that.

The problem is that a vendor was blaming their poor performance on the site connectivity. Of course we set up nagios to poll every minute but that wasn’t good enough. We needed to be able to graph response time. Eventually I wrote a perl script to feed data to MRTG but before we did that we played around with IOS rtr and ip sla commands.

I was working on something else when my counterpart began playing with ip sla and rtr, so I decided to lab it even though it is not on the ONT exam.

A short note about IP SLA and responders. Depending upon version number and platform you are able to do different operations. It is interesting that Cisco SLA monitoring is very careful regarding time stamps. This is so that you can truly get line speed as opposed to application or processing delays. From the Cisco documentation, IP SLA test packets use time stamping to minimize the processing delays. When the IP SLA responder is enabled, it allows the target device to take time stamps when the packet arrives on the interface at interrupt level and again just as it is leaving, eliminating the processing time. This time stamping is made with a granularity of sub-milliseconds.

Below is an image of the lab setup I am using. Once again it is the general cabling diagram from the ONT Lab book because I am not changing the wiring until I have to.

Goals for the lab:

• Have R1 download the index page from the web server 192.168.24.234 and report it’s statistics for a 24 hour period under the tag HTTP.234.
• Have R1 report the SLA for tcpConnect for a one hour period to R2.

How I did the lab:

The server at 192.168.24.234 is running a web server and we want to have the IOS HTTP SLA measure performance. Let’s test downloading a file from the server:

Now let’s see what operations sla supports on our router.

You might as well configure snmp on the router, I used the ubiquitous public community string, I would recommend changing that:

Now to configure a test of the sla in the lab:

Notice that when we scheduled it we are only going to run it for a day, 86,400 seconds with a start-time of now. If you wanted to run this test indefinitely you would configure life forever.

Now to show what is going on:

I also wanted to test the IP SLA tcpConnect SLA configuration. Here is the command to set up R2 as the responder:

And the commands to enable it on R1 as the source of the tcpConnect:

And to confirm that is working on R1:

Now to confirm that is working on R2:

You can find the SNMP Object Navigator here where you can look up Cisco MIBs.

This is how you would download snmp data from your router:

And to make it more MRTG friendly:

I used the IP SLA documentation to help me configure SLA, it is also the source of the quote above.

Command Line:
Not even the Cisco QoS Exam Certification guide covers the old command line configuration.

Modular QoS Command Line (MQC):
This tool separates classification of the traffic from the policy of the per hop behavior (PHB) on the router. The same policy can be applied to many interfaces on the same router.

There are three major commands in MQC, using the commands from NBAR Fun as examples.

• class-map
  Defines matching parameters to separate classes into a number of named service classes. An example is:
  class-map match-any http-citrix
  match protocol http url “*citrix*”
• policy-map
  This step defines PHB behaviors and links those behaviors to traffic classes. A policy-map is named an can associate 256 traffic classes, which are each defined by a class-map.
  An example is:
  policy-map mark-inbound-http-citrix
  class http-citrix
  set ip dscp 1
• service-policy
  This is the application of classification and policy on an interface. It is applied to traffic that is either inbound or outbound. An example of this command:
  interface FastEthernet0/0
  ip address 192.168.14.1 255.255.255.0
  duplex auto
  speed auto
  service-policy input mark-inbound-http-citrix

On order to display and verify QoS classes and policies on a router use these commands:
show class-map
show policy-map
show policy-map interface int

AutoQos:
The key benefit of AutoQoS is that administrators who do not understand QoS can use AutoQoS to implement features consistently and accurately across the entire network if you consistently use AutoQoS across the enterprise.

The commands to implement AutoQos are:
auto qos voip — The first generation of AutoQoS
auto discovery qos — Must have CEF and NBAR turned on, the router analyzes traffic.
auto qos — The router builds class maps and then creates and applies a policy map on the interface automagically.

Security Device Manager (SDM) QoS Wizard:
is a web based client to interact with your router. The SDM predefines three traffic classes real-time, business-critical and best-effort. SDM allows you to easily implement QoS, monitor QoS and troubleshoot QoS.

Do the SDM lab in the lab workbook. I spent more time installing Windows on a server and getting SDM to run in my browser than the lab took, but there is no sense in me trying to explain the SDM. It’s a GUI tool and if you are like me and used to working with the CLI then it’s no big loss if you don’t use it.

Type of Service (ToS)

The first stab at QoS was RFC 791, published September 1981, which defined the ToS byte. Inside the ToS byte the first three bits were defined as IP precedence. The greater the IP precedence the more important the traffic, the higher the probability of timely forwarding.

This table is reproduced based on one from the QoS Exam Certification Guide and shows the IP precedence bits of the ToS field.

For the sake of completeness I made this table from data in RFC 791 showing all of the bits on the ToS field.

DSCP

The introduction of RFC 2474 states that differentiated services are intended to provide a framework and building blocks to enable deployment of scalable service discrimination in the Internet. Marking is performed by traffic conditioners or DS boundary routers. The DiffServ code point or DSCP redefines the ToS byte in the IP header. DSCP redefined the ToS byte to include the first 6 bits with RFC 2474 designating the last two bits as unused. RFC 3168 specified the last two bits of the DSCP field would be used for explicit congestion notification (ECN) bits. The DSCP describes per hop behavior to be used in that autonomous system.

PHB

From the CCNP ONT Certification Guide, PHB is formally defined as an externally observable forwarding behavior of a network on a group of IP packets that have the same DSCP Value. First traffic is classified as close to the source as possible, then marking is performed. If marking is done in our autonomous sytem (AS) it is trusted and the markings can be used in subsequent nodes.

There are four per hop behaviors:

1. Best Effort (BE)
   Provides no QoS marking or treatment, the default, DSCP value of 000000.
2. Expedited Forwarding (EF)
   From RFC 2598, the EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to-point connection or a “virtual leased line”. This service has also been described as premium service.
   
   A priority queue must be used to minimize the time EF packets spend waiting in the queue. It should also be policed so as to not exceed a configured rate. The DSCP field is set to 101110, a decimal value of 46.
3. Class Selector (CS)
   DiffServ calls DSCP values used for backword compatibility with ToS-based IP precedence class selectors (CS). The least significant bits are set to 0, so it only uses 8 DSCPs. More important traffic is classified with a higher value as in the ToS table above. From the QoS Exam Certification Guide, it is important to distinguish between what the values of the precedence and DSCP fields can mean and what the should mean when following sound QoS design practices. IP precedence with value 0 should imply the lowest QoS service possible, with 7 implying the best.

   DSCP Class Selector, IOS Values	Binary Values of DSCP	Precedence Value (Decimal)
   Default	000000	0
   CS1	001000	1
   CS2	010000	2
   CS3	011000	3
   CS4	100000	4
   CS5	101000	5
   CS6	110000	6
   CS7	111000	7

4. Assured Forwarding(AF)
   A company intranet often includes geographically distributed offices that have limited bandwidth connecting them. The company will have to specify which packets take precedence by classifying and marking packet forwarding assurance as well as drop precedence for its service provider.
   
   RFC 2597 defines AF as four independently forwarded classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence which correlate to different discard rates during congestion. A higher decimal number represented by the bits in AF does not represent a better service level as it does in ToS and CS.
   
   From RFC 2597, in a DS node, the level of forwarding assurance of an IP packet depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet.
   
   The following table is reproduced from the QOS Exam Configuration Guide and shows the four AF classes as well as the probability of being dropped:

A list of the RFCs pertinent to this discussion:
791 ToS
2474 Details of the DSCP field in the IP header
2475 Core concepts of DiffServ
2597 Assured Forwarding PHB
2598 Expedited Forwarding
3260 Diffserv Clarification

This all began when I got a call from our Electronic Medical Record (EMR) vendor about “slowness” in the network. Of course they were sure it was something on our end, meaning our fault, despite the fact that we, the networkers here at the Circus, do not have access to the routers and firewalls that connect our organizations. You can see where this is headed.

So we begin by hooking up a sniffer to our last hop and running a ping to their Citrix farm. When the ping slowed, we hunted through the output on the sniffer to decipher what was wrong.

Eventually it came down to a shared problem. Our Citrix client is purposely run at one of the later versions that they support and is installed through an .msi, while on the farm web page is a newer version that can be installed even if you do not have administrative rights. So users were having difficulty and clicking on the client to reinstall, which was just exacerbating the problem. Normally that does not work, but this morning with the new package it did. Almost. Because these users were downloading ~15MB file over our scrawny link and flooding the circuit. Which just made more users complain that the “system” was slow and start clicking around like their cohorts.

To make matters worse our vendor refused to remove the link to the package that we do not want installed. That was when I thought about NBAR and decided to lab this up.

Here is the diagram:

Here is a link to the configuration files and packet captures and a listing of the files included in the .tar file is below:
$ tar -tf nbar-fun.tar
NBAR-Fun/
NBAR-Fun/r1-citrix.cfg — The configuration for R1.
NBAR-Fun/r2-citrix.cfg — The configuration for R2.
NBAR-Fun/r4-citrix-ios.cfg — The configuration for R4.
NBAR-Fun/r4-citrix-tgn.cfg — The traffic generator configuration for R4.
NBAR-Fun/switch-fa-01 — Packet capture to make sure generator worked.
NBAR-Fun/switch-fa-02-before — Packet capture before NBAR applied.
NBAR-Fun/switch-fa-02-after — Packet capture after NBAR applied.

Let me explain what I did. This lab is based off of the lab wiring for the CCNP ONT Lab manual. R4 is the traffic generator, it sends traffic to R1 that is then destined for R2 and eventually back in another interface on R4. When it gets to R1 it is processed through NBAR and packets requesting citrix.msi are dropped.

Here are really the only interesting commands needed:

So let’s break down the commands and explain what each does.

The first thing we do is define a traffic class called http-citrix:

A better name would have been block-citrix-msi in case we also needed a class called improve-citrix-prfrmnc.

In the class-map command I used match-any, but I could have used match-all because I am only looking for the word citrix. If on the other hand I wanted to do something like:

Then I would have to use match-any. Otherwise the chances would be slim that I would get a packet asking for citrix.msi and java.msi at the same time and in this case I would want to stop some java.msi as well as citrix.msi.

The second thing you do is define the traffic matching criteria:

Third, create a traffic policy, this is really for traffic class aggregation, however, in this scenario we only have one traffic class.

Fourth, mark the class of traffic class for later use. Remember this is DiffServ so we use DSCP to mark the traffic:

Then we need to assign that policy to an interface:

Now the traffic is marked coming into Fa0/0, but we need to do something with the marking to block traffic. So we make an ACL and assign it to an interface:

As you can see from the traffic capture switch-fa-02-after the traffic containing citrix.msi was dropped.

This lab is based on CCNP ONT Lab 4.1 and Cisco Document ID 27842.
This site was helpful as well:

http://www.opalsoft.net/qos/CDS-21.htm

There are three QoS Models:

1. Best-Effort
2. Integrated Services Model
3. Differentiated Services Model

Best-Effort Delivery/FIFO:
Switches and routers work to deliver packets as quickly as possible with no regard for the type of traffic or need for priority. There is no QoS policy applied to traffic.

If we use the firetruck example as in one of the books, sorry I can’t remember which one, firetrucks headed to a fire must stay within the normal flow of traffic. At an intersection it must wait in line like all other vehicles and gets no special treatment.

Benefits:

• Scalable
• Easy

Drawbacks:

• No differentitation
• No guarantees

Integrated Services (IntServ):
InServe is also called HardQoS because it guarantees bandwidth, delay and packet loss. IntServ applies QoS on a per-flow basis and requires that each node establish guaranteed bandwidth before a single packet is sent.  If each node cannot guarantee bandwidth the application does not start.

IntServ model involves setting up an end-to-end connection across the network using an ip based signaling protocol called Resource Reservation Setup Protocol (RSVP, RFCs 2205 – 2215). RSVP is used by the host to request bandwidth and it is used by routers in the path to establish and maintain state of the flow (RFC 2205). While the flow is active, the routers maintain the bandwidth reserved for that application from source to destination. If the reservation is not successful from source to destination, the application can not start.

RFC 1633 InServ describes two components that are key building blocks:

• Resource Reservation
• Admission Control

Resource Reservation:
Bandwidth must be managed because it is an important and finite resource and guarantees can not be achieved without reservation. Routers reserve the queuing preferences for a flow based on an RSVP request. RSVP reserves the bandwidth when the flow starts and continues while the flow is still active. RSVP can also request delay, but guaranteeing delay is not easy.

Admission Control:
Admission control is the algorithm that decides whether a flow can begin. Remember a flow will not start unless the network has met the requested guarantees. This is not to be confused with policing or enforcement, only whether or not the request has been met.

The ONT book also specifies Policing, Queuing and Scheduling:
Policing:
Ensure that clients do not exceed resource reservation by measuring and monitoring.

Queuing:
Routers must be able hold packets while processing others.

Scheduling:
Scheduling works in conjunction with queuing, the amount of data dequeued and sent is based on queuing mechanisms.

Using the firetruck example, the firetruck would radio ahead to each intersection before it left the firehouse to make sure the light will be green when it gets there. If all the lights can not be green, then the firetruck would not leave. This does not scale well.

Benefits:

• Resource control
• Per request control
• Signaling of dynamic port numbers

Drawbacks:

• Signaling requires overhead
• Does not scale

Differentiated Services (DiffServ):
DiffServ is more commonly used than IntServ and is therefore covered in more depth within the ONT book and I presume on the test. Chapters 3, 4 and 5 all deal with DiffServ so this section will be short.

DiffServ is also called SoftQoS and is defined in RFC 2474 and 2475. There is no signaling by the client or router before sending data. Traffic is first classified and then marked. As marked traffic moves through the network it’s level of service depends upon it’s marking.

Marking is done in the headers of each packet. The fields in the packet headers used to classify traffic are defined in RFC 2474, the DS field in IPv4 and the Traffic Class octet in IPv6. The IPv4 DSCP superseded the ToS octet from RFC 791. Six bits of the DS field are used as a codepoint (DSCP) to select the Per Hop Behavior (PHB) a packet experiences at each node.

DiffServ applies QoS on a per-hop basis to a group of similar flows. Each device handles packets on an individual basis, which is called Per Hop Behavior. Packets should be classified as close to the source as possible. Each router or switch can be configured with QoS policies to follow and decisions are made accordingly. While providing flexibility, you have to configure each router, regardless, it scales more readily because you have less overhead from no use of RSVP. DiffServ requires no advance reservations, QoS is handled in a distributed fashion.

Continuing with the traffic example, police are stationed at every intersection, however, none of them knows a firetruck is coming until they hear the siren. At each intersection the decision on how to handle the fire truck is made based on the rules of that intersection.

DiffServ Benefits:

• Scalability
• Many service levels

DiffServ Drawbacks:

• No service guarantee
• Configuration throughout the network

Sources:

http://rfc.sunsite.dk/rfc/rfc1633.html

http://rfc.sunsite.dk/rfc/rfc2205.html

http://rfc.sunsite.dk/rfc/rfc2210.html

http://rfc.sunsite.dk/rfc/rfc2474.html

http://rfc.sunsite.dk/rfc/rfc2475.html

Cisco QoS Exam Certification Guide
CCNP ONT
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T

Once again this post will be pretty mundane to the typical enterprise Linux admin. I continue to post these projects because it highlights what can be done with free software, plus I have worked out some kinks that others may run into.

If you couple parts of this post with how to join Ubuntu to an AD domain you have a simple scalable PDF printer for every user in the enterprise. We even discussed doing this at the Circus.

The last couple of days have been fun. I found out the Circus has been spending $25K per year on paper and toner, not to mention the two FTEs, to print medical records out of our Electronic Medical Records (EMR). Then we paid two ladies to scan that paper file back into a .pdf.

The worst part of this whole set up was that this department had first been told that printing to .pdf was just not possible. Then they were told that if we installed a new print system from our EMR, that would cost us $100K, we would be able to print to .pdf. I was appalled.

So I set up a cups-pdf printer and shared out the output directory through samba, asked for it to be set up like any other printer from the EMR and ta-da, .pdf medical records. The director and manger of medical records offered to buy me dinner and my CIO offered lunch. Not a bad couple of days of work. Not to mention the savings to the hospital, I’m guessing a ball park of $40K annually.

So here is how I did it. I forgot to mention that once they saw the first one, the decided they wanted two and then two months later a third. That added a little wrinkle but I’ll show you how I dealt with it.

I am using RHEL 5.3 but any CentOS will do, it’s even easier to setup on Ubuntu. That’s where I did my proof of concept, but all of the extra stuff I only did on Red Hat.

First add the users, these will be used to direct the pdf output to the correct directory. Also make sure to add these users to the lp group in /etc/group.

Now make the ip addresses. I have to make three IP addresses to be able to print to three pdf printers because they will be used for different purposes and I don’t want the end users getting lost.
eth1 == 192.168.1.10
eth1:1 == 192.168.1.11
eth1:2 == 192.168.1.12

Next install the cups-pdf rpm, I used cups-pdf-2.4.6-1.el5.i386.rpm.
Edit the /etc/cups/cupsd.conf file to allow printing from your network.
Here is mine:

Edit the cups-pdf configuration file, /etc/cups/cups-pdf.conf. The keys here are the UserUmask and the Out directory. The out directory ties into the user specified in the jetdirect configuration for xinetd. We print to the user that corresponds to the directory of the correct share from Samba. Reread that last paragraph because it is the crux of this set up.

Those who work with printing quite a bit will know that HP network printing uses port 9100. Let’s verify so that we can make xinetd answer for that port:

Now set up xinetd to answer on each IP address above for a different printer and user that correlates to the directory where the output is supposed to end up.

To set up the printer, just set it up like any other HP jetdirect printer. I
use the “HP Color LaserJet PS” printer in Windows.

To share out the output directory first add whatever user to samba:
smbpasswd -a username

Or check out how to add a Linux box to your Windows domain.

The interesting sections of my /etc/samba/smb.conf file: