O'Reilly Network    
 Published on O'Reilly Network (http://www.oreillynet.com/)
 See this if you're having trouble printing code examples


O'Reilly Book Excerpts: Cisco Cookbook

Cooking with Cisco, Part 1

Related Reading

Cisco Cookbook
By Kevin Dooley, Ian J. Brown

by Kevin Dooley

Author's note: Cisco includes many subtle but useful features in its IOS that you can use to improve your network's efficiency and reliability. This recipe from Cisco Cookbook shows how to use a feature called "Frame-Relay Traffic Shaping" to ensure that the router doesn't overrun the capacity of the individual PVCs in a Frame Relay WAN. This is different from the more common Generic Traffic Shaping, which controls the packet rate for the entire interface. The recipe also shows how to use adaptive Frame-Relay Traffic Shaping, allowing the router to adjust how fast it sends packets to avoid intermittent network congestion problems.

Recipe 11.11: Using Frame-Relay Traffic Shaping

Problem

You want to separately control the amount of traffic sent along each of the PVCs in a Frame Relay network.

Solution

This first example shows how to configure Frame Relay traffic shaping using point-to-point frame relay subinterfaces:

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface HSSI0/0
Router(config-if)#encapsulation frame-relay
Router(config-if)#exit
Router(config)#interface HSSI0/0.1 point-to-point
Router(config-subif)#traffic-shape rate 150000
Router(config-subif)#frame-relay interface-dlci 31
Router(config-subif)#end
Router#

Most Frame Relay carrier networks are sufficiently overprovisioned, meaning that you can actually use much more capacity than your contractual Committed Information Rate (CIR). So you might want to apply traffic shaping only when you encounter Frame Relay congestion problems, and then only to reduce the data rate until the congestion goes away:

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface HSSI0/0
Router(config-if)#encapsulation frame-relay
Router(config-if)#exit
Router(config)#interface HSSI0/0.1 point-to-point
Router(config-subif)#traffic-shape adaptive 10000
Router(config-subif)#frame-relay interface-dlci 31
Router(config-subif)#end
Router#

Discussion

These examples are different from the one that we showed in Recipe 11.10. In this recipe we don't want to control the entire aggregate traffic flow, and we don't care about the traffic based on application. Here we want to ensure that every Frame Relay PVC using this interface is shaped separately so that they don't overrun the amount of bandwidth purchased from the WAN carrier. If you have 20 PVCs on an interface, it is fine to send the maximum per-PVC bandwidth to all of them simultaneously, but you will suffer from terrible performance problems if you try to send all of that bandwidth through a single PVC.

Usually you will purchase a particular amount of Frame Relay bandwidth, or CIR, from the WAN carrier for each PVC. So the first example shows how you can force the router to only send 150Kbps through the PVC with DLCI 31. It is important to remember that you can have different CIR values for different PVCs. You may need to have a different Frame Relay traffic shaping rate on every PVC.

The second example assumes that a lot of the time there will be very little congestion in the carrier's network, so you should be able to safely use some of the excess capacity. The Frame Relay protocol includes the ability to tell devices when there is congestion in the network. There are two types of congestion notifications, which are just noted as flags in the header portion of regular user frames. If a router receives a frame with the Forward Explicit Congestion Notification (FECN) flag set, it knows that the frame encountered congestion on its way from the remote device to the router. If the router receives a frame with the Backward Explicit Congestion Notification (BECN) flag set, a frame encountered congestion on its way from this router to the remote device. Please refer to Chapter 10 of Cisco Cookbook for a more detailed discussion of these Frame Relay protocol features.

The traffic-shape adaptive command tells the router that when it sees frames with a BECN flag, it should reduce the sending rate on this PVC. By default, this command will back off the sending rate all the way to zero. So, in the example, we have specified a minimum rate of 10,000bps, which would correspond to the CIR for this PVC:

Router(config-subif)#traffic-shape adaptive 10000

In general, this adaptive traffic shaping method is preferred over the static method, because it will give you significantly better network performance when the carrier's network is not congested. However, it is important to remember that the precise implementation of FECN and BECN markings is up to the carrier. Some carriers disable these features altogether, while others use them inconsistently. Since most customers ignore these markings, there is often very little reason to ensure that they are accurate.

You should check with your network vendor before implementing adaptive Frame Relay traffic shaping. We also recommend monitoring your FECN and BECN statistics for a reasonable period of time before implementing them, to verify that they are reliable.

See Also

Chapter 10 and Recipe 11.10; Recipe 11.12 from Chapter 11.

Author's note: You can use the logging feature with Cisco Access Lists to keep track of how often certain types of packets pass through your network. This is often a good way to detect patterns of abuse or attempts to violate network security. The only problem is that the sheer volume of log messages generated this way can make analysis very difficult. This recipe provides a script to scan and analyze the log files automatically for you.

Recipe 19.10: Analyzing ACL Log Entries

Problem

You want to analyze the log entries created by logging ACLs.

Solution

The Perl script in Example 19-1 parses a router syslog file and builds a detailed report of packets that were denied by logging ACLs. By default, the script will parse every ACL log message that it finds in the syslog file on a server. You can also look for messages associated with a particular ACL by specifying the ACL number or name as a command-line argument.

Example 19-1. logscan.pl

#!/usr/local/bin/perl
#
#       logscan.pl -- a script to extract ACL logs from a syslog file. 
#
# Set behaviour
$log="/var/log/cisco.log";
$ntop=10;
#
chomp ($acl=$ARGV[0]);
if ($acl =  = "") { $acl=".*"};
   
open(LOG , "<$log") or die;
while (<LOG>) {
 if (/IPACCESSLOGP: list $acl denied ([tcpud]+) ([0-9.]+)\(([0-9]+)\) ->
  ([0-9.]+)\(([0-9]+\), ([0-9]+) /) {
   $x=$6;
   $srca{$2}+=$x;
   $foo=sprintf("%16s  -> %16s  %3s port %-6s",$2,$4,$1,$5);
   $moo=sprintf("%3s port %-6s",$1,$5);
   $quad{$foo}+=$x;
   $port{$moo}+=$x;
 }
}
$n=0;
printf ("Connection Summary:\n");
foreach $i (sort { $quad{$b} <=> $quad{$a} } keys %quad) {
   if ($n++ >= $ntop) { last };
   printf ("%6s:%s\n", $quad{$i},$i);
}
$n=0;
printf ("\nDestination Port Summary:\n");
foreach $i ( sort { $port{$b} <=> $port{$a} } keys %port) {
   if ($n++ >= $ntop) { last };
   printf ("%6s: %s\n", $port{$i},$i);
}
$n=0;
printf ("\nSource Address Summary:\n");
foreach $i ( sort { $srca{$b} <=> $srca{$a} } keys %srca) {
   if ($n++ >= $ntop) { last };
   printf ("%6s: %s\n", $srca{$i},$i);
}

Note that we have had to split the line that begins "if (/IPACCESSLOGP: list" across two lines so that it will fit on the page. If you decide to use this script, please type this as a single line.

Discussion

It's a good idea configure your access lists so that they log all of the packets that they deny. This is particularly true for security-related ACLs. You can then use these log messages for security or audit purposes. Unfortunately, this level of logging can create a large number of messages, which makes analysis difficult. This Perl script automates the most difficult part of this analysis by parsing a large file of ACL log messages and building a report that can help to identify potential problems.

The report produced by the script has three sections that summarize connections, destination ports, and source IP addresses. The connection report displays the top 10 most common connection denied attempts including the source address, destination source, and destination port number. The destination port summary displays the top 10 most frequently denied destination ports. Finally, the source address summary displays the 10 hosts whose connection attempts were most frequently denied. In each case, the script looks at both TCP and UDP ports.

The following is a sample report:

Freebsd%./logscan.pl
Connection Summary:
   195:      172.25.1.1  ->     172.20.100.1  tcp port 23    
    13:      172.25.1.1  ->     172.20.100.1  tcp port 22    
     8:      172.20.1.2  ->       172.25.1.3  udp port 53    
     6:      172.20.1.2  ->       172.25.1.1  udp port 123   
     6:      172.25.1.1  ->         10.2.2.2  tcp port 23    
     4:      172.20.1.2  ->       172.25.1.1  udp port 162   
     4:      172.25.1.1  ->     172.20.100.1  tcp port 21    
     4:      172.20.1.2  ->       172.25.1.1  udp port 53    
     3:      172.25.1.1  ->     172.20.100.1  tcp port 80    
     2:      172.20.1.2  ->       172.25.1.3  udp port 123   
   
Destination Port Summary:
   206: tcp port 23    
    14: tcp port 22    
    12: udp port 53    
     8: udp port 123   
     4: tcp port 80    
     4: udp port 162   
     4: tcp port 21    
     2: tcp port 443   
     1: tcp port 6000  
     1: tcp port 79    
   
Source Address Summary:
   222: 172.25.1.1
    24: 172.20.1.2
     3: 172.25.1.6
     1: 192.168.4.217
     1: 172.25.1.9
     1: 10.2.3.134
     1: 172.25.1.4
     1: 172.22.1.9
     1: 10.23.55.121
     1: 172.25.1.3
Freebsd%

This report can help identify troubling behavior that warrants further investigation. For instance, address 172.25.1.1 has attempted to telnet to 172.20.100.1 195 times. This may not have been evident by scanning the log file by hand.

The script can also build a report based on the messages received from a particular ACL number or name:

Freebsd%./logscan.pl 122
Connection Summary:
     2:      172.25.1.6  ->         10.2.2.2  tcp port 443   
     1:   192.168.4.217  ->         10.2.2.2  tcp port 23    
     1:      172.22.1.9  ->         10.2.2.2  tcp port 6000  
     1:      10.2.3.134  ->         10.2.2.2  tcp port 23    
     1:      172.25.1.9  ->         10.2.2.2  tcp port 23    
     1:    10.23.55.121  ->         10.2.2.2  tcp port 79    
     1:      172.25.1.1  ->         10.2.2.2  tcp port 22    
     1:      172.25.1.6  ->         10.2.2.2  tcp port 23    
   
Destination Port Summary:
     4: tcp port 23    
     2: tcp port 443   
     1: tcp port 22    
     1: tcp port 6000  
     1: tcp port 79    
   
Source Address Summary:
     3: 172.25.1.6
     1: 10.2.3.134
     1: 172.22.1.9
     1: 192.168.4.217
     1: 172.25.1.1
     1: 172.25.1.9
     1: 10.23.55.121
Freebsd%

Before you can use this script you must modify the variable $log. This variable must contain the full directory and filename of the syslog file that you wish to scan. The script is then ready to launch. The only other variable you may want to modify is the $ntop variable. This variable defines how long each section of the report will be. By default, the script is set to display the top 10 matches in each category. However, you can set this number to any number you prefer. Note also that, as in the previous example, if there are fewer than $ntop matches in any category, the script will show only the matches that it actually finds.

For more information on logging and remote logging to a syslog server, please see Chapter 18 of Cisco Cookbook.

See Also

Chapter 19's Recipe 19.8; Recipe 19.9; Chapter 18

Editor's note: Check back to this space next Tuesday for recipes on a little-known IOS feature called IP Multicast Helper, and on a simple way to ensure that the routers never send unimportant messages.

Kevin Dooley is an independent networking consultant who has been designing and implementing networks for more than ten years.


Return to the O'Reilly Network.

Copyright © 2009 O'Reilly Media, Inc.