|
|
You can make changes to some of the default settings for the more common protocols. These settings determine what value initially appears for the protocol when defining a new network service; it can later be changed within existing network services or during the creation of new network services without affecting the default settings shown in the protocol's properties in the Protocol Definitions branch.
The Protocol Definitions branch is divided into three sub-branches: the Application Layer branch, the Transport Layer branch, and the Network Layer branch. You can find all supported application-layer protocols under the Application Layer branch, all supported transport-layer protocols under the Transport Layer branch, and all supported network-layer protocols under the Network Layer branch. The subtopic below discusses these layers in more detail:
Some protocols have default settings that you can modify either at the protocol definition level or at the network service level. Specifying a setting at the protocol definition level simply sets the default value that will appear when that protocol is used to define a new network service. It will have no effect on existing services or policies. Specifying a setting at the network service level, however, will change the setting for all policies or network service bundles that reference that service.
For example, if you change the Type session setting in the ICMP protocol panel (in the Protocol Definitions branch) to Echo Request, each new network service that you create afterward using the ICMP protocol will have an initial, default Type of Echo Request.
That setting can be changed, however, within the network service being defined without affecting the default setting in the protocol definition. For example, if you have changed the default Type session setting for the ICMP protocol to Echo Request in the Protocol Definitions branch, but decide that, for the particular service being created, the Type needs to be set to Echo Reply, you can adjust that session setting from within the Network Service Installation Wizard. The change only affects that particular network service you are creating.
In the same way, you can change the settings for a protocol in existing network services, without affecting the default value in the protocol definition, by changing the setting within the network service property panels. The changes made within the network service's property panels will not affect the default settings for the protocol, but will affect any security policies that reference that service.
The supported network protocols are grouped in the Protocol Definitions branch according to the layers at which they are located in the OSI Reference Model for data communications protocols. According to this model, protocols that enable application programs with which the user interacts exist at the application layer (like FTP and Telnet), protocols that provide end-to-end data delivery services exist at the transport layer (like TCP and UDP), and protocols that separate the upper-layer protocols from the physical network exist at the network layer (like IP). Therefore, Cisco Secure Policy Manager reflects this same structure in the Protocol Definitions branch.
You cannot reference protocol definitions directly within your security policy abstracts, although you can create custom network services based on the protocols. When you create a network service (with the Network Service Installation Wizard), you must specify the protocols that are engaged in the assembly and transfer of each packet of that network service, one protocol for each layer of the OSI Reference Model. For example, if you want to create a network service for FTP traffic, you can select that protocol (the FTP protocol definition) for the application layer, but you must also select a transport-layer protocol and a network-layer protocol to handle each packet of that network service at those levels. On the other hand, if you want to create a network service for ICMP traffic, the highest-level protocol that you need to define is for the transport layer (ICMP), followed by a protocol for the network layer, because ICMP does not need to function at the application layer.
![]() |
Note Although Policy Enforcement Points use instance settings defined for the network service, such as the implicitly or explicitly defined TCP or UDP port number for a particular network service, they cannot enforce session-based settings, such as the Idle Timeout value. Two exceptions exist to this session-based setting rule (the Policy Enforcement Point will interpret these settings correctly): ICMP: Type and Code settings RPC: Program Number setting With regard to timeout settings, the Policy Enforcement Points implement timeout values as global timeouts that are enforced across all sessions of a specific type. To specify these global timeout settings, see the Settings 1 panel on each Policy Enforcement Point node in the Network Topology tree for which you want to enforce such settings. |
To change a default protocol setting, perform the following task:
Step 2 Click the protocol icon in the Navigator pane.
Result: The panel for the protocol appears in the View pane.

![]() |
Tips If the panel for the protocol does not appear in the View pane, right-click the protocol icon in the Navigator pane and click Properties on the shortcut menu. |
Step 3 To change a setting, double-click the existing value in any box and then type the new value or, if a list of values is provided, select the value from the list of values.
Result: The new value is applied to the protocol definition.
Step 4 To accept any changes that you make and close the panel, click OK.
Result: The protocol property panel closes.
Step 5 To save any changes that you have made, click Save on the File menu.
Result: If you accepted the changes, all subsequent network services that you create referencing this protocol will show the values you entered as the default values (but, you can make changes to the settings within the network service without affecting the default setting you specified). Pre-existing network services, though, will remain unaffected.
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Thu May 25 13:22:51 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.