Nokia IPSO 4.0 Reference Manual

Nokia Network V oyager for IPSO 4.0 Reference Guide Part No. N451818001 Rev A Published October 2005
2 Nokia Network Voyager for IPSO 4.0 Referenc e Guide COPYRIGHT ©2005 Nokia. All rights reserved. Rights reserved under the copyright laws of the United S tates. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the United S tat es Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the R ights in T echnical Data and Computer Software clause at DF ARS 252.227-7013. Notwithstanding any other license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the United S tates Government regarding its use, reproduction, and disclosure are a s set forth in the Commercial Computer So ftware- Restricted Rights clause at F AR 52.227-19. IMPORT ANT NOTE TO USERS This software and hardware is provided b y No kia Inc. as is and any express or implied warranties, including, but not limited to, impli ed warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shal l Nokia, or its affiliates, subsidiaries or suppliers be liable for any direct, ind irect, in cidental, special, exemplary , or conseque ntial damages (including, but not limited to, procurement of substitute goods or service s; loss of use, data, or profits; or business interruption) however caused and on any theory of liability , whether in contract, strict liability , or tort (including negligence or otherwise ) arising in any way out of the use of this software, even if advised of the possibility of such damage. Nokia reserves the right to make changes wit hout further no tice to any products herein. TRADEMARKS Nokia is a registered trademark of Nokia Corporat ion. Other products mentioned in this document are trademarks or registered tra demar ks of their respective holders. 0501 10 Nokia Contact Information Corporate Headquarters Web S it e http://www .nokia.com T elepho ne 1-888-477-4566 or 1-650-625-2000
Nokia N etwork Voyager fo r IPSO 4.0 Refe rence Guide 3 Regional Contact Information Nokia Customer Sup port Fax 1-650-691-2170 Mail Address Nokia Inc. 313 Fairchild Drive Mountain View , California 94043-2215 USA Americas Nokia Inc. 313 Fairchild Drive Mountain Vi ew , CA 94043-2215 USA T el: 1-877-997-9199 Outside USA and Canada: 1 512-437-7089 email: info.ipnetworking_americas@nokia.com Europ e, Middle East, and Africa Nokia House, Summit Avenue Southwood, Farnborough Hampshire GU14 ONG UK T el: UK: 44 161 601 890 8 T el: France: 33 170 708 166 email: info.ipnetworking_emea@nokia.com Asia-Pacific 438B Alexandra Road #07-00 Alexandra T echno park Singapore 1 19968 T el: 65 6588 3364 email: info.ipnetworking_apac@nokia.com Web S it e: https://support.nokia.com/ Email: tac.support@nokia.com Americas Europe Vo i c e : 1-888-361-5030 or 1-613-271-6721 Vo i c e : 44 (0) 125-286-8900 Fax: 1-613-271-8782 Fax: 44 (0) 125-286-5666 Asia-Pacific Vo i c e : 65-67232999 Fax: 65-67232897 050602
4 Nokia Network Voyager for IPSO 4.0 Referenc e Guide
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 5 Content s About the Nokia Network Voyager Re ference Guide . . . . . . . . . 19 Conventions This Guide Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1 About Network Voyager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Software Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Logging In to Network Voyager . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Logging Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Obtaining a Configuration Lock . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Navigating in Network Voyager . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Reloading Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Accessing Documentation and Help . . . . . . . . . . . . . . . . . . . . . . 26 Viewing Hardware and Software Information for You r System . . . 28 2 Configuring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 IP2250 Management Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Configuring Network Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Configuring IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Interface Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 Nokia Network Voyager IPSO 4.0 Reference Guide Configuring Tunnel Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Configuring Ethernet Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . 34 Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Managing Link Aggregation Us ing SNMP . . . . . . . . . . . . . . . . . . 36 Configuring Switches for Link Aggregation . . . . . . . . . . . . . . . . . 36 Static Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Link Aggregation on the IP2250 . . . . . . . . . . . . . . . . . . . . . . . . . 37 Configuring Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Gigabit Ethernet Interface s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Point-to-Point Over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Configuring PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Configuring MSS Clamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Virtual LAN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 FDDI Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 ISDN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Configuring Calling Line-Identification Screening . . . . . . . . . . . . 56 Dial-on-Demand Routing (DDR) Lists . . . . . . . . . . . . . . . . . . . . . 58 ISDN Network Configuration Example . . . . . . . . . . . . . . . . . . . . 61 ISDN Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Token Ring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Token Ring Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Point-to-Point Link over ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 ATM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 IP over ATM (IPoA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 IPoA Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Serial (V.35 and X.21) Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Serial Interface Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 T1(with Built-In CSU/DSU) Interfaces . . . . . . . . . . . . . . . . . . . . . . 88 T1 Interface Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 E1 (with Built-In CSU/DSU) Interfaces . . . . . . . . . . . . . . . . . . . . . . 96 HSSI Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Unnumbered Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 7 Configuring Unnumbered Interfaces . . . . . . . . . . . . . . . . . . . . . 107 Configuring OSPF over Unnumbered Interface . . . . . . . . . . . . 110 OSPF over Unnumb ered Interfaces Using Virtual Links . . . . . . 110 Cisco HDLC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Frame Relay Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Loopback Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 GRE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Configuring GRE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 GRE Tunnel Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 High Availability GRE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 122 HA GRE Tunnel Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 DVMRP Tunnels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 DVMRP Tunnel Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 ARP Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Configuring ARP for ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . 130 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Transparent Mode Processing De tails . . . . . . . . . . . . . . . . . . . 133 Configuring Transparent Mode in VPN Environments . . . . . . . 134 Example of Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . 135 Configuring Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . 136 Monitoring Transparent Mode Groups . . . . . . . . . . . . . . . . . . . 139 Transparent Mode and Check Poin t NGX . . . . . . . . . . . . . . . . 139 Virtual Tunnel Interfaces (FWVPN) for Route-Based VPN . . . . . 140 Creating Virtual Tunnel Interfaces . . . . . . . . . . . . . . . . . . . . . . . 142 3 Configuring System Functions . . . . . . . . . . . . . . . . . . . . . . . . 145 Configuring DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Configuring DHCP Client Interfaces . . . . . . . . . . . . . . . . . . . . . 146 DHCP Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Configuring the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 147 DHCP Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8 Nokia Network Voyager IPSO 4.0 Reference Guide Changing DHCP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Adding DHCP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Enabling or Disabling DHCP Address Pools . . . . . . . . . . . . . . . 150 Assigning a Fixed-IP Address to a Client . . . . . . . . . . . . . . . . . 150 Creating DHCP Client Templates . . . . . . . . . . . . . . . . . . . . . . . 151 Configuring Dynamic Domain Name System Se rvice . . . . . . . . 153 Configuring the Domain Name Se rvice . . . . . . . . . . . . . . . . . . . . 154 Configuring Disk Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Using an Optional Disk (Flash-Based Systems Only) . . . . . . . . . 155 Mail Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 System Failure Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Configuring Mail Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Sending Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Setting the System Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Configuring Host Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Configuring System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Configuring Logging on Disk-Based Systems . . . . . . . . . . . . . . 160 Configuring Logging on Flas h-Based Systems . . . . . . . . . . . . . 161 Configuring Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Remote Core Dump Server on Flash-Based Systems . . . . . . . . . 165 Changing the Hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Managing Configuration Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Scheduling Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Backing Up and Restoring Files . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Creating Backup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Transferring Backup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Restoring Files from Locally Stored Backup F iles . . . . . . . . . . . 172 Managing Nokia IPSO Images . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Changing Current Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Deleting Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Installing New Image s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Testing a New Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Upgrading Nokia IPSO Images for a Cluster. . . . . . . . . . . . . . . 176
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 9 Downgrading Nokia IPSO Images . . . . . . . . . . . . . . . . . . . . . . . 176 Configuring Monitor Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Managing Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Installing and Enabling Packages . . . . . . . . . . . . . . . . . . . . . . . 178 Advanced System Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Tuning the TCP/IP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Router Alert IP Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 4 Virtual Router Redundancy Prot ocol (VRRP) . . . . . . . . . . . . . 183 VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 How VRRP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Understanding Monitored-Circuit VRRP. . . . . . . . . . . . . . . . . . . . 186 Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Selecting Configuration Parameters . . . . . . . . . . . . . . . . . . . . . 187 Before you Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Configuring Monitored-Circuit VRRP . . . . . . . . . . . . . . . . . . . . . 192 Configuring VRRPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Configuring Check Point NGX for VRRP . . . . . . . . . . . . . . . . . . . 197 Configuring VRRP Rules for Check Point NGX . . . . . . . . . . . . 199 Link Aggregation (IP2250 Systems Only) . . . . . . . . . . . . . . . . . 201 Monitoring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Monitoring the Firewall State . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Troubleshooting VRRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 General Configuration Consi derations . . . . . . . . . . . . . . . . . . . 203 Firewall Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Switched Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 5 Configuring Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 IP Clustering Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Using Flash-Based Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Example Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Cluster Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10 Nokia Network Voyager IPSO 4.0 Reference Gu ide Cluster Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Clustering Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Considerations for Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 214 If You Do Not Use a Dedicated Primary Cluster Protocol Networ k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Upgrading IPSO in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 For All Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Upgrading from IPSO 3.7 or Later. . . . . . . . . . . . . . . . . . . . . . . 218 Upgrading from IPSO 3.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Creating and Configuring a Cluster . . . . . . . . . . . . . . . . . . . . . . . 220 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Creating a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Selecting the Cluster Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Configuring the Work Assignment Method . . . . . . . . . . . . . . . . 221 Configuring an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Configuring Firewall Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 223 Supporting Non-Check Point Ga teways and Clients . . . . . . . . . 223 Configuring Join-Time Shared Features . . . . . . . . . . . . . . . . . . 226 Making the Cluster Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Adding a Node to a Cluste r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recommended Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Joining a System to a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Managing a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Using Cluster Voyager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Synchronizing the Time on Cluste r Nodes . . . . . . . . . . . . . . . . 239 Configuring NGX for Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Clustering Example (Three Nodes) . . . . . . . . . . . . . . . . . . . . . . . 243 Configuring the Cluster in Voyager . . . . . . . . . . . . . . . . . . . . . . 244 Configuring the Internal and External Route rs . . . . . . . . . . . . . 245 Clustering Example With Non-Check Point VPN . . . . . . . . . . . 246
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 11 6 Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 SNMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 SNMP Proxy Support for Check Point MIB . . . . . . . . . . . . . . . . . 252 Using the Check Point MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Using cpsnmp_start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Enabling SNMP and Selecting t he Version . . . . . . . . . . . . . . . . . 254 Configuring the System for SNMP . . . . . . . . . . . . . . . . . . . . . . . . 255 Setting an Agent Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Configuring Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Interpreting Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Configuring SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Request Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Managing SNMP Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 7 Configuring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 IPv6 and IPv4 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Configuring IPv6 in IPv4 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 270 Configuring IPv6 to IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Configuring IPv6 over IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Configuring IPv4 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 272 Configuring an IPv6 Default or Static Ro ute . . . . . . . . . . . . . . . 272 Routing Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Configuring OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Configuring RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Creating IPv6 Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . 273 Creating Redistributed Routes . . . . . . . . . . . . . . . . . . . . . . . . . 274 Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Configuring ICMPv6 Router Discovery . . . . . . . . . . . . . . . . . . . 275 VRRP for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Configuring VRRP for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Creating a Virtual Router for an IPv6 Interf ace
12 Nokia Network Voyager IPSO 4.0 Reference Gu ide Using VRRPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Creating a Virtual Router to Back Up Another VRRP Router Addresses Using VRRPv3 . . . . . . . . . . . . . . . . . . . . . 278 Monitoring the Firewall Sta te . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Setting a Virtual MAC Address for a Vi rtual Route r . . . . . . . . . . 280 Changing the IP Address List of a Virtual Router in VRRPv3 . . 281 Removing a Virtual Router in VRRPv3 . . . . . . . . . . . . . . . . . . . 281 Creating a Virtual Router in Monitore d Circuit Mode for IPv6 . . 282 Setting Interface Dependencies for a Monitored Circuit Virtual Router for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Changing the List of Addres ses in a Monitored Circuit Virtual Router for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Traffic Manageme nt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Security and Access Configuration . . . . . . . . . . . . . . . . . . . . . . . 285 8 Managing Security and Access . . . . . . . . . . . . . . . . . . . . . . . . 287 Managing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Managing User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Adding and Deleting Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Managing and Using S/Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Role-Based Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Managing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Assigning Roles and Access Mechanisms to Users . . . . . . . . . 295 Creating Cluster Administrator Users . . . . . . . . . . . . . . . . . . . . 296 Configuring Network Access and Services . . . . . . . . . . . . . . . . . 297 Configuring a Modem on COM2, COM3, or COM4. . . . . . . . . . 298 Configuring Nokia Network Voyager Access . . . . . . . . . . . . . . . . 300 Configuring Basic Nokia Network Voyager Options . . . . . . . . . 301 Generating and Installing SSL /TLS Certificates . . . . . . . . . . . . 302 Secure Shell (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Initial SSH Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Configuring Advanced Options for SSH . . . . . . . . . . . . . . . . . . 306
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 13 Configuring Secure Shell Authorized Keys . . . . . . . . . . . . . . . . 308 Changing Secure Shell Key Pairs . . . . . . . . . . . . . . . . . . . . . . . 309 Managing User RSA and DSA Identities . . . . . . . . . . . . . . . . . . 310 Tunneling HTTP Over SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Network Voyager Session Management . . . . . . . . . . . . . . . . . . . 311 Enabling Enabling or Disab ling Session Management . . . . . . . 312 Configuring Session Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 312 Authentication, Authorization, and Accounting (AAA) . . . . . . . . . 313 Creating an AAA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 313 Configuring RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Configuring TACACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Deleting an AAA Authentication Server Configurat ion . . . . . . . 322 Changing an AAA Configuration . . . . . . . . . . . . . . . . . . . . . . . . 323 Deleting an AAA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 327 Encryption Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Enabling Encryption Accelerator Cards. . . . . . . . . . . . . . . . . . . 328 Monitoring Cryptographic Acceleration . . . . . . . . . . . . . . . . . . . 328 IPSec Tunnels (IPSO Implementation) . . . . . . . . . . . . . . . . . . . . 328 Using PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 IPSec Implementation in IPSO . . . . . . . . . . . . . . . . . . . . . . . . . 332 IPSec Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Creating an IPSec Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Creating an IPSec Tunnel Rule . . . . . . . . . . . . . . . . . . . . . . . . . 341 Transport Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 IPSec Tunnel Rule Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 IPSec Transport Rule Example . . . . . . . . . . . . . . . . . . . . . . . . . 346 Changing the Local/Remote Address or Local/Remote Endpoint of an IPSec Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 348 Removing an IPSec Tunnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Miscellaneous Security Settings. . . . . . . . . . . . . . . . . . . . . . . . . . 349 9 Configuring Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Routing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
14 Nokia Network Voyager IPSO 4.0 Reference Gu ide Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Route Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Types of Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Area Border Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 High Availability Support for OSPF . . . . . . . . . . . . . . . . . . . . . . 355 Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 RIP 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 RIP 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Virtual IP Address Support for VRRP . . . . . . . . . . . . . . . . . . . . 366 Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Configuring RIP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Configuring Auto-Summarization . . . . . . . . . . . . . . . . . . . . . . . 369 RIP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Configuring Virtual IP Support for VRRP. . . . . . . . . . . . . . . . . . 371 PIM Support for IP Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Configuring Dense-Mode PIM . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Disabling PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Setting Advanced Options for Dense-Mode PIM (Optional) . . . 375 Configuring Sparse-Mode PIM . . . . . . . . . . . . . . . . . . . . . . . . . 376 Configuring High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . 377 Configuring this Router as a Candidate Bootstrap and Candidate Rendezvous Poin t . . . . . . . . . . . . . . . . . . . . . . . . . 379 Configuring a PIM-SM Static Rendezvous Point . . . . . . . . . . . . 380 Setting Advanced Options for Sparse-Mode PIM (Optional) . . . 381 Debugging PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 IGRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Generation of Exterior Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Aliased Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 IGRP Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 15 Configuring IGRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Configuring DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Configuring DVMRP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Configuring IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Adding and Managing Static Routes Exa mple . . . . . . . . . . . . . 397 Backup Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Route Aggregation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Route Rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Rank Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Routing Protocol Rank Example . . . . . . . . . . . . . . . . . . . . . . . . 402 BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Support for BGP-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 BGP Sessions (Internal an d External) . . . . . . . . . . . . . . . . . . . . 404 BGP Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 BGP Multi-Exit Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 BGP Interactions with IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Inbound BGP Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Redistributing Routes to BGP . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 EBGP Multihop Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Route Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 TCP MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 BGP Support for Virtual IP for VRRP . . . . . . . . . . . . . . . . . . . . 412 BGP Support for IP Clustering . . . . . . . . . . . . . . . . . . . . . . . . . 413 BGP Memory Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 BGP Neighbors Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Path Filtering Ba sed on Communities Example . . . . . . . . . . . . 418
16 Nokia Network Voyager IPSO 4.0 Reference Gu ide BGP Multi Exit Discriminator Example . . . . . . . . . . . . . . . . . . . 419 Changing the Local Pre ference Value Example . . . . . . . . . . . . 421 BGP Confederation Examp le . . . . . . . . . . . . . . . . . . . . . . . . . . 423 Route Reflector Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 BGP Community Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 EBGP Load Balancing Example: Scenario #1 . . . . . . . . . . . . . 430 EBGP Load Balancing Example: Scenario #2 . . . . . . . . . . . . . 432 Adjusting BGP Timers Example . . . . . . . . . . . . . . . . . . . . . . . . 433 TCP MD5 Authentication Example . . . . . . . . . . . . . . . . . . . . . . 434 BGP Route Dampening Example . . . . . . . . . . . . . . . . . . . . . . . 435 BGP Path Selectio n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 BGP-4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Route Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 Redistributing Routes to BGP . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Redistributing Routes to RIP and IGRP . . . . . . . . . . . . . . . . . . 440 Redistributing OSPF to BGP Example . . . . . . . . . . . . . . . . . . . 443 Redistributing Routes with OSPF . . . . . . . . . . . . . . . . . . . . . . . 444 Inbound Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 BGP Route Inbound Policy Exa mple. . . . . . . . . . . . . . . . . . . . . 446 BGP AS Path Filtering Example . . . . . . . . . . . . . . . . . . . . . . . . 448 10 Configuring Traffic Management . . . . . . . . . . . . . . . . . . . . . . . 449 Traffic Manageme nt Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Packet Filtering Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Traffic Shapin g Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Traffic Queuing Descriptio n . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 Configuring Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . 450 Configuring ACL Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 Modifying a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Configuring Aggregation Classes . . . . . . . . . . . . . . . . . . . . . . . . . 455 Configuring Queue Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 Configuring ATM QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Configuring Common Open Policy Server . . . . . . . . . . . . . . . . . . 461
Nokia Netw or k Voya g er IPSO 4.0 Reference Guid e 17 Configuring a COPS Client ID and Po licy Decision Point . . . . . 462 Configuring Security Parameters for a COPS Client ID . . . . . . 462 Assigning Roles to Specific Interfaces . . . . . . . . . . . . . . . . . . . 463 Activating and Deactivating the COPS Client . . . . . . . . . . . . . . 464 Changing the Client ID Associated with Specific Diffserv Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 Deleting a Client ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 Example: Rate Shaping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Example: Expedited Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 466 11 Configuring Router Services . . . . . . . . . . . . . . . . . . . . . . . . . . 469 BOOTP/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Configuring BOOTP/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . 470 IP Broadcast Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 Router Discovery Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Configuring Router Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Network Time Protocol (NTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 Configuring NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 12 Monitoring System Configuration and Hardware . . . . . . . . . . 479 Viewing System Utilization Statistics . . . . . . . . . . . . . . . . . . . . . . 479 CPU-Memory Live Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Disk and Swap Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 Monitoring Process Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 480 IPSO Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 Generating Monitor Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Monitoring System Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Monitoring System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Viewing Cluster Status and Member s . . . . . . . . . . . . . . . . . . . . . 485 Viewing Routing Protocol Information . . . . . . . . . . . . . . . . . . . . . 486 Displaying the Kernel Forwa rding Table . . . . . . . . . . . . . . . . . . 486 Displaying Route Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
18 Nokia Network Voyager IPSO 4.0 Reference Gu ide Displaying Interface Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Hardware Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Using the iclid Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 iclid Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 Preventing Full Log Buffers and Rela ted Console Messages . . . 494 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Nokia N etwork Voyager fo r IPSO 4.0 Refe rence Guide 19 About the Nokia Network V oyager Reference Guide This guide provides information about how to configure and monitor Nokia IPSO systems. This gu ide provides co nceptual information about system features and instructions on how to perform tasks using Nokia Netwo rk V oyager , the W eb-based interface for IP SO. All of the tasks that you perform with Network V oyager you can also pe rform with the comm and-line interface (CLI), allowing you to choose the inte rface you are most comfortable with. For information specific to the CL I, see the CLI Refer ence Guide for Nokia IPSO . This guide is intended for experienced network administrators who confi gure and manage Nokia IP security platform s . It assumes a working knowledge of networking and TCP/IP p r oto col prin cipals and some experien ce with UNIX-based systems. This guide is organized in to the following chapters:  Chapter 1, “About Network V oyager” describes the IPSO operating system, Nokia Netwo rk V oyage r , h ow to use Network V o yager , and how to access documentation and help pages.  Chapter 2, “Configu ring Interfaces” describes how to configure and monitor interfaces.  Chapter 3, “Configuring System Functions” describes how to configure basic system functions such as DH CP , DNS, disk mirroring, mail relay , system failure notification, system time , host entries, system logging, and
About the Nokia Network Voyager Reference Guide 20 Nokia Netwo rk Voyager for IPSO 4.0 Reference Guid e the hostname . It also describes how to save configuration sets, schedule jobs, backup and restore files, manage and upgrade system images, reboot the system, manage packages, and advanced system tuning.  Chapte r 4, “V irtual Router Redu ndancy Protocol (VRRP)” des cribes how to provides dynam ic failover of IP addresses using VRR P .  Chapte r 5, “Configuring Clustering” describes how to provide fault tolerance and dynamic load balancing usin g clustering.  Chapter 6, “Configuring SNMP” describes how to config ure Simple Network Management Protocol (SNMP), th e protocol used to exchange management information between ne tw ork devices.  Chapter 7, “Configuring IPv6” describes how to configure features that use the IPv6 protocol.  Chapter 8, “ Managing Security and Acces s” desribes how to manage passwords, user accounts and groups , assign privileges using role-based administration, and how to config ure network access, s ervices, and Network V oyager session ma nagement. It also describes how to configure AAA for a new service, encryption acceleration, and virtual tunne l interfaces (VTI), which suppor t Check Point route-based VPN..  Chapter 9, “Configuring Routing” describes the IPSO routing subsystem, how to configur e the v arious routing protocols th at are supported, route aggregation, and route redi stribution.  Chapter 10, “Configuring T raffic Management” describes traf fic management functionality , including a ccess control lists and aggregation classes.  Chapter 1 1, “Configuri ng Router Services” describes how to enable your system to forward broadcast traffic by enabling the IP Broadcast Helper , forward BOOTP/DHCP traffic by enab ling BOOTP relay , how to enable router discovery , and how to configure for Network T ime Protocol (NTP).  Chapter 12, “Monitoring System Configuration and Hardware” provides information on monitoring your system.
Conventions This Guide Uses Nokia N etwork Voyager fo r IPSO 4.0 Refe rence Guide 21 Conventions This Guide Uses The following sections describe the co nventions this guide uses, including notices, text conventions, and command-line conventions. Notices Caution Cautions indicate potential equipment da mage, equipment malfunction, loss of performance, loss of dat a, or interruption of service. Note Notes provide information of special inter est or recommendations. T ext Conventions Ta b l e 1 describes the text conventions this guide uses. T able 1 T ext Conventions Convention Description monospace font Indicates command syntax, or represent s computer or screen output, for examp le: Log error 12453 bold monospace font Indicates text you enter or type, for example: # configure nat Key names Keys that you press simultaneously are linked by a plus sign ( ): Press Ctrl Alt Del.
About the Nokia Network Voyager Reference Guide 22 Nokia Netwo rk Voyager for IPSO 4.0 Reference Guid e Menu Items Menu items in procedures are sepa rated by the greater than sign. For example, click Backup and Restore under Configuration > System Configuration indicates that you first cl ick Configurat ion to expand the menu if necessary , then click System Configuration, and finally click the Backup and Restore link. Related Document ation In addition to this guid e, do cumentation for this product includes the following:  CLI Refer ence Guide for Nokia IPSO , which is on the IPSO CD. This guide contains the commands that you can implement from the command-line interface (CLI) for IPSO.  Getting S tarted Guide and Release Notes for IPSO , which is included in the release pack. This docume nt contains a lis t of new features fo r the current IPSO release, installation instru ctions, and known limitations. Menu commands Menu commands are separated by a greater than sign (>): Choose File > Open. Italics • Emphasi zes a point or denotes new terms at the place where th ey are defined in the te xt. • In dicates an external book title reference. • In dicates a variab le in a command: delete interface if_name T able 1 T ext Conventions ( continue d ) Convention Description
Nokia Network Voyager for IPSO 4.0 Reference Guide 23 1 About Network V oyager This chapter provides an overview of Network V oyager , the W eb-based interface that you can use to manage Nokia IPSO systems. Nokia Network V oyage r is a W eb-base d interface that you can use to manage IPSO systems from any authorized location. Network V oyage r comes packa ged with the IPSO operating system software and is accessed from a client using a browser . Y ou can also use the command-line interface (CL I) to perform all of the tasks that you can perform when you use Network V oyager , which a llows you to choose the interface you are most comfortable with. For information about the CLI, see the CLI Reference Guide . Software Overview Nokia firewalls function with the help of several software components:  Operating System —Nokia IPSO is a UNIX-like operating system based on FreeBSD. IPSO is customized to support Nokia’ s en hanced routing capab ilities and Check Point’ s FireW all-1 firewall functionality , and to "har den" network security . Unnecessary features have been removed to mini mize the ne ed for UNIX system administration.  Ipsilon Routing Daemon (IPSRD) —IPSRD is Nokia’ s routing software. The routing policy implemented by IPSRD resides in a database. Network V oyager (see below) configures and maintains the ro uting software and database.  Check Point Fir eW all-1 —FireW all-1 consists of two ma jor components: (1) the Firewall module, which runs on the Nokia firewal l and implements the security policy , and (2) the Management module, whic h run s either on the Nokia firewall or on another wo rkstation. Use the Management Module to define and maintain the security policy .  Network V oyager —Network V oyager communicate s with the routing software to configure interfaces and ro uting protocols, to manage routing policy for the firewall, and to monitor network traffic and protocol performanc e. Network V oyager also provides online documentation. Network V oyager itself runs on a remote machine as a client application of the Nokia routing software and is HTML based.
1 24 Nokia Network Voyager for IPSO 4.0 Reference Guide Logging In to Network V oyager When you log in to Network V oyager, the navigation tree you see depend s on the role or roles assigned to you. If the roles assigned to your us er account do not includ e access to a feature, you will not see a link to the feature in the tree. If th ey have read-only access to a feature, you will see a link and be able to access the page, but all the controls will be disabled. For more information on role-ba sed administration, see “Role-Based Administration” on page 293. Note The system logs messages about both successfu l and unsuccessful attempt s by users to log in. These are stored in the /var/log/messages file. T o open Nokia Network V oyager 1. Open a W eb browser on a computer with network connectivity to the IPSO system. 2. In the Location or Address text box, ente r the IP address of the initial interface you configured for the appliance. Y ou are prompted to enter a username and passw ord. If this is the first login, enter the Admin username and the password you entered when you performed the initial configuration. Y ou can select to log in with or without an exclusive lock on conf iguration changes. For more information, see “Obtaining a Configuratio n Lock” on page 25. For information about initia l configuration, see the Getting S tarted Guide and Release Notes for IPSO . Note If the login screen does not appear , you might not have a physical network connection between the host and your appliance, or you mig ht have a network routing problem. Confirm the information you entered durin g the initial con figuration and check that all cables are firmly connected. Logging Off When you are finished with your Network V oyage r session, or if you need to log in to a new session, log out by clickin g Log Off at the to p of the Network V o yager window . Note The Log Of f link does not appear if you disable d session management. For information about session management, see “N etwork V oyager Session Management” on p age 31 1.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 25 Obt aining a Configuration Lock When you log in with exclusive confi guration lock, no other user will be able to change the system configuration. Only users with read/wr ite access privileges are allowed to log in with exclusive configuration lock. If you acquire a configuratio n lo ck and then close your brows er without logging out, the lock remains in ef fect until the session time-out elapses or someone ma nually overrides the lock. For instructions abou t how to override a configuration l ock, see “T o override a configuration lock.” Users who have one or more read/write access pr ivileges (as defined by the administra tor under role-based administration) acquire conf iguration locks unless they uncheck the Acqui r e Exclusive Configuration Lock check box when they log in. However , their read/write access is limited to the features assigned by the administra tor even though the conf iguration lock is in effect for all features. T o log in with exclusive configuration lock 1. At the login, en ter your user name. 2. Enter your password. 3. Check the Acquire Exclusive Configuration Lock check box. This is the default. 4. Click Log In. Note Enabling the exclusive configur ation lock in Network V oyager prevent s you or other users from using the CLI to conf igure the system while your browser ses sion is active. T o log in without exclusive configuration lock 1. At the login, en ter your user name. 2. Enter your password. 3. Uncheck the Acquire Exclusiv e Configuration Lock check box. 4. Click Log In. T o override a configuration lock Note Only users with read/w rite access privil eges are allowed to override an exclusive configuration lock. 1. From the login page, click Log In with Advanced Options. 2. V erify that the Acquire Exclusive Configuratio n Lock check bo x is checked. This is the default choice. 3. Check the Override Locks Acquired by Other Users check box.
1 26 Nokia Network Voyager for IPSO 4.0 Reference Guide 4. Enter your user name and password. 5. Click Log In. Navigating in Network V oyager The following table explains the functions of th e buttons in Network V oyager . Other buttons are described in the inline help for each page. A void using your browser ’ s Back and Forward bu ttons while in Network V oyager . The browser caches the HTML page information; therefore, us ing Back and Forward may not dis play the latest configuration and diagno stic information as you move from pag e to page. Reloading Pages If the pages seem to have outdated information, you can u se the Reload button on the browser to update it. Y ou can also clear memory an d disk cache with the following procedure. T o clear the memory and disk cache 1. Select Network Preferences from the Options menu in Netscape. 2. Select Cache in the Preferences window . 3. Click the Clear Memory Cache Now button, then click OK. 4. Click Clear Disk Cache Now , then click OK. 5. Click OK or close the Preferences window . Accessing Document ation and Help Y ou can access the Nokia Network V oyager Re fer ence Guide for IPSO , the CLI Refer ence Guide , and Network V oyager online help from link s wi thin the Network V oyager interface. Button Description Apply Applies the settings on the current page (and any d eferred applies from other pages) to the current (running) configuration fi le in memory . Feedback T akes you to the documentation or T e ch nical Assistance Center (T AC) feedback page. Help Displays help for all elements of the page. Reset Routing Restart s the routing daemon. Save Saves the current (running) configuratio n fi le to disk.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 27 This guide, the Nokia Network V oyage r Re fer ence Guide for IPSO , is the comprehensive reference source for IPSO ad ministration and using the Netw ork V oyager interface. Y ou can access this guide a nd the CLI Refer ence Guide from the following locations:  Network V oyager interface—Click the Documentation link in the tree view .  Nokia support site ( https: //support.nokia.com ).  On the software CD that might have been de livered with your applia nce. If you have a CD, the documentation is located in the doc folder . Inline help supplies context sensi tive information for Network V oya ger . T o access inline help for a Network V oyager page, navigate to th at page an d cli ck Help. T ext-only definitions and related information on fields, b uttons, and sec tions appear in a separate window . Inline and online help use the following text conventions. Y ou can preserve the current page con tent in your browser and start another bro wser window to display the inline or online help te xt by using the following procedure . T o open a new window to view help 1. Right-click the Doc button. 2. Click Open Link in New Browser W indow . Displays the online help in a new window . 3. Right-click the Help On button. 4. Click Open Link in New Browser W indow . Displays the inline (text-only) help in a new window . T ype of T ext Description italic text Introduces a word or phrase, highlights an important term, phrase, or hyperte xt link, indicates a field name, system message, or document ti tl e. typewriter text Indicates a UNIX command, program, file na me , or path name. bold typewriter text Indicates text to be entered verbati m by you. Represents the name of a key on the ke yboard, of a button displayed on your screen, or of a button or switch on the hardware. For example , press the R ETURN key . <bracketed> Indicates an argument that you or the software replace s with an a ppropriate value . For example, the command rm <filenam e> indicates that you should type rm followed by the filename of the fil e to be removed. LinkT ext Indicates a hypertext link. - OR - Indicates an exclusive choice between two items.
1 28 Nokia Network Voyager for IPSO 4.0 Reference Guide V iewing Hardware and Software Information for Y our System The asset management summary pa ge provides a summary of all system resources, including hardware, software and the operating system . The hardware summary includes information about the CPU, Disks, BIOS, and motherboard, including the serial numb er , model number , and capacity , or date, as appropriat e. The summary also displays the amount of me mory on the appliance. The Check Point FireW all summary lists informatio n about the host and policy installed and the date on which the FireW all policy was installed. The summary al so describes w hich version of the FireW all is running and license information. The operating system summary lists which soft ware release and version of that release is running on the system. T o view the asset management summary 1. Click Asset Management under Configuration in the tree view . The asset management summary pa ge appears. 2. The page se parates information into three tables: Hardware, FireW all Package Information, and Operating System. 3. Click the Up button to return to the main configuration page.
Nokia Network Voyager for IPSO 4.0 Reference Guide 29 2 Configuring Interfaces This chapter describes configuring and monitoring the various types of interfaces supported by Nokia IP security platforms, aggregating Ethernet ports, conf iguring GRE and DVMRP tunnels, using transparent mode to allow your IP SO appliance to behave like a Layer 2 device, and o ther topics related to physical and logical interfaces. Interface Overview Nokia IPSO support the following interface types.  Ethernet/Fast Ethernet  Gigabit Ethernet  FDDI  A TM (RFC1483 PVCs only)  Serial (V .35 and X.21) running PPP , point-to-point Frame Relay , or Cisc o HDLC  T1/E1 running PP P , Frame Relay , or Cisco HDLC  HSSI running PPP , point-to-point Frame Relay , or Cisco HDLC  VPN T unneling  T oken Ring  Unnumbered Interface  ISDN Note For information on what types of interfaces your app liance model supports, see your hardware installation guide. Y ou can configure these interfaces with IP ad dresses. Y ou also can assign additional IP addresses to the loopback, FDDI , and Ethernet inte rface s. Al l interface types support IP multicast.
2 30 Nokia Network Voyager for IPSO 4.0 Reference Guide IP2250 Management Port s The Ethernet management ports on IP2 250 system s are de signed to be used for the following purposes:  Managing the appliance  Firewall synchronization traf fic  IP cluster protocol traf fic  Connection to a log server Caution The management p orts are not suit able for forwarding production data tr affic. Do not use them f or this purp ose. Configuring Network Devices Network V oyager displays network devices as ph ysi cal interfaces. A physical interface exis ts for each physical port on a network interface card (NIC) installed in the appliance. Physical interface names have the form: <type>-s<slot>p<port> where: <type> is a prefix indica ting the device type. <slot> is the number of th e slot the device occupies in the appliance. <port> is the port number of the NIC. The first port on a NIC is port one. For example, a two-port Ethernet NIC i n slot 2 is represented by two physical interfaces: eth-s2p1 and eth-s2p2 . The following table lists the inte rface-name prefixes for each type. Ty p e P r e f i x Ethernet eth FDDI fddi AT M atm Serial ser T1/E1 ser HSSI ser T oken Ring tok
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 31 The loopback interface also has a physical interfa ce name d loop0 . Use Network V oyager to set attributes of interfa ces. For example, line speed and duplex mode are attributes of an Ethernet physical inte rface. Each communications port has exactly one physical interface. Configuring IP Addresses Logical interfaces are created for a device's physic al interfa ce. Y ou assign an IP address to logical interfaces and then route to the IP a ddr ess. Ethernet, FDDI, and T oken Ring devices have one logical interface. For A TM devices, you cre ate a new logical interface each time you configure an RFC1483 PVC for the device. Serial, T1/E1, and HSSI devices have one logical interface when they are running PPP or Cisco HDLC. Serial, T1/E1, and HSSI dev ices running poin t-to-point Frame Relay have a logical interface for each PVC configured on the port. Y ou also have the option of configuring an unnumbered interface for point- to-point interfaces. T unnels, however , cannot be configured as unnumbered interfaces. Logical interfaces, by default, are named after th e physical interface for wh ich they are created. If you wish, you can override th is default name with a more descriptive or familiar name. Y ou can also associate a comment with the logical inte rface as a further way to define its relationship in the network. Default logical interface names have the form: <type>-s<slot>p<port>c<chan> where <type> , <slot> and <port> have the same values as the corresponding physical interface . <chan> is the channel number of the logical interface. For logical interfaces created automatically , th e channel number is always zero. For logical interfaces created manually , the cha nnel number is the identifi er of the virtual circuit (VC) for which the interface is created (for example, the A T M VCI or the Frame Relay DLCI). ISDN isdn Ty p e P r e f i x Physical Interface Logical Interface Default Cisco HDLC PPP Frame Relay Ethernet One ( c0 ) FDDI One ( c0 ) A TM One per VCI ( c# )
2 32 Nokia Network Voyager for IPSO 4.0 Reference Guide For example, the logical inte rface of a physical interface eth-s2p1 is called eth-s2p1c0 . The logical interfaces for PVCs 17 and 24 on an A TM NIC in slot 3 are c alled atm-s3p1c17 and atm-s3p1c24 respectively . Once a logical interface exists for a device , yo u can assign an IP address to it. For Ethernet, FDDI, and T oken Ring, you must sp ecify the interf ace's local IP address and the length (in bits) of the subnet mask for the subnet to which the device connects. If you are running multiple subnet s on the same physical network, you can configure additional addresses and subnet masks on the single logical in terface connected to that network. Y ou do not need to create additional logical interfaces to run multiple subnets on a single physical network. For point-to-point media, such as A TM, se ria l, or HSSI, you can either assign IP addresses or configure an unnumbered interface. When assi gning IP addresses you must specify the IP address of the local interface and the IP address of the remote system's point-to-point interface. Y ou can add only one local/destina tion IP address pair to a point- to-point logical interface. T o assign IP addresses to multiple VCs, you must create a logical inte rface for each VC. IP subnets are not supported on po int-to-point interfaces. Whenever an unnumbered interface generates a pa cket, it uses the address of the interface that the user has specified as the source address of the IP packet. Thus, for a route r to ha ve an unnumbered interface, it must have at leas t one IP address assigned to it. The Nokia implementation of unnumbered interfa ces does not support virtual links. Note If you make changes to IP addresses or delete inter faces, the firewall sometimes does not learn of the changes when you get the topology . If you get the topology and yo ur changes to interfaces are not shown, stop and rest art the firewall. Interface S t atus The configuration and status of removable-inte rface devices are displayed. Interfaces can be changed while they are offline. Ta b l e 2 describes the interface status indicators. Serial (X.21 or V .35) One ( c0 )O n e ( c0 ) One per DLCI ( c# ) T1/E1 One ( c0 )O n e ( c0 ) One per DLCI ( c# ) HSSI One ( c0 )O n e ( c0 ) One per DLCI ( c# ) T oken Ring One (c0) ISDN One ( c# ) Physical Interface Logical Interface Default Cisco HDLC PPP Frame Relay
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 33 Events that can affect the status of interfaces:  If you hot-insert a device (not power down the unit first), it appea rs in the lists of interfaces immediately (after a page refre sh) on the configuration pages.  If you hot-pull a device, and no configuration ex ists for it, it disappears from the lists of interfaces immediately .  If you hot-pull a device, and it had a configuratio n, its configuration de t ails continue to be displayed and can be changed even after a reboot.  Hotswapped interfaces that are fully seated in a router ’ s chassis are represented in the ifT able (MIB-II), ipsoCardT a ble (IP440-IP SO-System-MIB), and the hrNetworkT able (Host-Resources-MIB).  Unwanted configurations of absent devices can be delete d, which removes the physical an d logical interfaces from all interface lists. Configuring T unnel Interfaces T unnel interfaces are used to encapsulate protocols inside IP pa cke ts. Use tunneling to:  Send network protocols ov er IP networks that don’ t support them.  Encapsulate and encr yp t private data to send over a public IP ne twork. Create a tunnel logical interface by specifying an encapsulation type. Use Network V oyager to set the encapsulatio n type. Network V oyage r su pports two encapsulation types, DVMRP and GRE. The tunnel logical interface name has the form: tun0c<chan> where <chan> (channel number) is an instantiation identifier . T able 2 Interface S tatus Indicato rs Indicator Description None If no color indi cation is displayed , the physica l interface is disabled. T o en able the interface, click on the physical interface name to go to its configuration page. Blue The device corresponding to this physical in terface has bee n removed from the system, but its configuration remains. T o delete its configur ation, click on the physical interface name to go to its configuration page. Red The physical interface is enabled, but the device does not detect a conn ection to the network. Green The physical interface is ready for use. It is enab led and connected to the network.
2 34 Nokia Network Voyager for IPSO 4.0 Reference Guide Ethernet Interfaces Y ou can configure a number of parameters for ea ch Ethernet interface, including the following:  Enable (make active) or disable the interface.  Change the IP address for the interface.  Change the speed and duplex mode. Configuring Ethernet Interfaces Ta b l e 3 describes the configuration setti ngs for an Ethernet interface. T able 3 Physical Interface Conf iguration Parameters Parameter Description Active Select On to enabl e the interface, select Off to disable the interface. These selections appear on both the main Interface Config uration page and the pages for each individual interface. Link T rap Click On or Off to enable or disable the linkup/li nkdown traps for the i nterface. Default is On for all physical interfaces. Link Speed Select 100 Mbit/sec or 10 Mbit/sec. This setting must be the same for all hosts on the network to which the device connects. Duplex Mode Select Full or Half. This setting must be the same for all hosts on the network to which the device connects. Autoadvertise Click on or off to enable or disable autoadvertise. If turned on, the device adve rtises its configured speed and dup licity by using Ethernet negotiation. Link recognition delay Specify how many seconds a link must be st able before the interface is declared up. Default is 6; range is 1-255. Queue mode For more information, see “Configuring Queue Classes” on page 457. IP address & Mask length Y ou can add multiple IP addresses. Note Do not change the IP address you use in your browser to access Network V oyager . If you do, you can no lo ng e r access the IP security pl atform with your Network V oyager browser .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 35 T o configure an Ethernet interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the name of the physical interface you wa nt to configure. Example: eth-s2p1 3. Specify the configuration paramete rs for speed add duplex mode. 4. Click Apply . 5. Click the logical interface name in the Logical Interfaces table. The Logical Interface page is displayed. 6. Enter the IP address a nd mask length. 7. Click Apply . Each IP addresses and mask length that you add are added to the table when you click Apply . The entry fields return to blank to allow you to add more IP addresses. Use the delete check box to dele te IP addresses from the table. 8. (Optional) Change the interface l ogical name to a more meaningful name by typing the preferred name in the Logical na me text box. 9. Click Apply . 10. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 11 . Click Up to go to the In terface Configuration page. 12. Click On button that corresponds to the logical interface you configured. Click Apply . The Ethernet interface is now ava ilable for IP traf fic and routing. 13. T o make your change s pe rmanent, click Save. Link Aggregation Nokia IPSO appliances allow you to aggregate (c ombine) Ethernet ports so that they fu nction as one logical port. Y ou get the be nefits o f grea ter bandwidth per logica l interface and load Logical name Use this to enter a more meaningful name for the interface. Comments (Optional) This field is disp layed on th e main Interface Configura tion and the Logical Interface pages. Use it to add a description that you might find useful in identifyin g the logical in te rf ace . T able 3 Physical Interface Conf igu ration Parameters Parameter Description
2 36 Nokia Network Voyager for IPSO 4.0 Reference Guide balancing across the ports. For example, you can aggregate two 10/100 mbps ports so they function like a single port with a theoretical ba ndwidth of 200 mbps, and y ou can aggregate two Gigabit Ethernet ports so they function like a single port with a theoretical bandwidth of 2000 mbps. If you have only 10/100 interfaces and need a faster link but can’t or don’ t want to use Gigabit Ethernet, you can use lin k ag gregation to achieve faste r throu gh put with the interfaces you already h ave. Another benefit of link aggre gation is redundancy—if one of the physical links in an aggregation group fails, the traffic is redistributed to the remaining physical links and the aggregation group continues to function. IPSO distri butes the outbound IP traffic acro ss the physical link s using the source and destination IP addresses. It uses the source and destination MAC address es to distribute non-IP traffic. Y ou can aggregate as many as four ports in one aggregation grou p, and you can have as many as eight aggregation groups on one appliance. Y ou can hot swap NICs that have po rts participating in an aggrega tion group. If the group has ports on other NICs, the traf fic is distributed to those ports and the aggr egation group continues to function when you remove a NIC in this manner . If you reinsert the NIC, the appropriate ports rejoin the aggregation g roup and resu me forwarding traf fic automatically . Managing Link Aggregation Using SNMP Nokia IPSO systems use a proprietary SNMP MIB to manage link aggregation. T o incorporate link aggregation into you r SNMP-based management, perform the following tasks:  Copy the file NOKIA-IPSO-LINKAGGREGA TION - MIB.txt to your management system. This file is locate d at /etc/snmp/mibs/.  In Network V oyager o r the IPSO CLI, enable the following traps:  Enable lamemb erActive traps  Enable lamemberInactive traps Note IPSO does not use the standard IEEE80 23-LAG-MIB to support link aggregation. Configuring Switches for Link Aggregation Observe the following consideratio ns when you configure a switch to support link aggregation in combination with a Nokia appliance:  Y ou must configure the approp ri ate switch ports to use static link a ggregation. (On Cisco switches, this means you must enable EtherCha nnel.) That is, if you aggregate four ports into one group on your No kia appliance, the four switch ports tha t they connect to must static link aggregation.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 37  When you assign switch p orts to an EtherChannel group, set the chann el mode to on to force the ports to form a ch annel without using the Link Aggregation Control Protocol (LACP) or Port Aggregation Protocol (P AgP).  If your switch supports it, configure the aggr egated ports to distribute the traffic using source and destination IP addresses.  If your switch can only distribute traffic ba sed on source or destination MAC addresses, configure it to use the source MAC addresses. If it uses the destination MAC address to distribute the load, all the tr af fic flowing from the switch to the IPSO system over the aggregated link is sent to the primary port of the aggregation group.  Y ou must configure the switch port s to have the same physical characteristics (link speed, duplicity , autoadvertise/autone gotiation setting, and so on) as the c orresponding aggregated ports on the Nokia system.  On Cisco switches, trunking must be enabled if you create more than one tagged VLAN on an aggregated link. (Y ou can configure a s many as 1015 VLANs for an IPSO system.).  If you use IOS on a Cisco switch, tr unking is enabled automatically .  If you run CatOS on a Cisco switch, use the following command to configure VLAN trunking on the EtherChann el: set trunk ports nonegotiate dot1q vlans S t atic Link Aggregation The IPSO implementation of li nk aggregation complie s with the IEEE 802.3ad standard for static link aggregation. Nokia has also tested IPSO link aggregation with the following Cisco Catalyst switches:  6500 Series  3550 Series  2950 Series IPSO does not support LACP , which is used for dynamic link aggregation. Link Aggregation on the IP2250 This section describes aspects of link aggregatio n that are spec ific to the IP2250 appliance. Firewall Synchron ization T raffic If you configure two IP2250 ap pliances in a VRRP pair or IP Cluster and run NG X on them, Nokia recommends that you aggregate two of the built-in 10/ 100 Ethernet management ports to create a 200 Mbps logical link and config ure NGX to use this network for firewall synchronization traffic. If you use a single 100 Mbps connection for sync hronization, connection information might not be properly synchro nized when the appliance is handles a lar ge number of connections.
2 38 Nokia Network Voyager for IPSO 4.0 Reference Guide Note Use Ethernet crossover cables to con nect the manage ment port s tha t you aggr egate. Using a switch or a hub can result in incomple te synchronization. Because you should use crossove r cables for these connections, yo u should n ot co nfig ure more than two IP2250 appl iances in a VRRP group or IP cluster . If you use aggregated ports for fi rewall synchronization traffic a nd delete a port from the aggregation group but do no t delete the group itself, be sure to dele te the c orresponding port on the other IP2250 system. If you delete a port on on e system only and that port remains physically and logically enabled, the other system will continue to send tr affic to the deleted port. This traffic will not be received, and firewall sync hronization will therefore be incomplete. Caution Do not use ports on IP225 0 ADP I/O cards for firew all synchroniz ation traffic. Doing so can cause connections to be dropp ed in the event that there is a failover to a backup router . Configuring the Remaining Management Port s If you are using IP clustering, follow these guide lines when you configure the remaining built-in Ethernet managemen t po rts:  Use one of the management ports exclusivel y for the p rimary cluster protocol network.  Use a separate manage ment port for the following purposes, if necessary:  management connection  log server connection  secondary cluster protoc ol network  Use a switch or hub to conn ec t the se ports . Do not use crossover cables to connect any interfaces other than those us ed for firewall synchronization. Caution The management port s are not suita ble for forwarding production data traffic—do not use them f or this purp ose. Production T raffic (A DP I/O Port s Only) Y ou can aggregate the ports on ADP format IP22 50 I/O cards and use the aggregated links for traffic other than firewall sync hronizatio n. If you aggregate ports on IP2250 I/O cards, observe the following guidelines:  Y ou can connect the aggregated ports us ing a switch, hub, or crossover cab le.  Do not include ports on different I/O cards in the same aggregation group.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 39  Do not combine any o f the built-in 10/100 Ethernet management p orts with ports on an I/O card to form an aggregation grou p. Caution Do not use the management port s of an IP2250 for production traf fic, regardless of whether the por ts are a ggregated. Configuring Link Aggregation T o set up link aggregation in Network V oyager 1. Physically configure the interfaces. 2. Create the aggregati on group. 3. Logically configure the aggregatio n group. These steps are explained in the following sections. Physical Interface Configuration T o set up link agg regation in Network V oyager , yo u first config ure the ph ysical interfaces that you will aggreg at e. Note Make sure th at the phys ical configuratio ns (link speed, duplicity , aut oadvertise set ting, and so on) are identical for all the interfaces that will participate in a given group. These settings must match the settings for the switch port s that t he interfaces are connec ted to. When you aggregate an interface, any logical conf iguration information is deleted. Be careful not to aggregate the interface th at you use for your management connection because doing so breaks your HTTP connection to the appliance. Should this occur , you can restore HTTP connectivity by using one of the following ap proaches:  Connect to another configured po rt and use Network V oyager to reconfigure the management port.  Use the IPSO CLI over a co nsole connection to reconfigure the management port. Because the manage ment port is now part of an ag gregation group, Netw ork V oyager and the CLI identify it using the format ae xxx , in which xxx is the group ID. T o physically configure the interfaces you will aggregate 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click a link for one of the physic al interfaces that you will aggregate. Be careful not to select a port that you are using for a management connectio n. 3. Configure the physical config ura tion to the settings you want.
2 40 Nokia Network Voyager for IPSO 4.0 Reference Guide 4. Click Apply 5. Click Save to make the changes permane nt. 6. Perform step 2 through step 5 again to configure the other interfaces identically . Group Configuration Once the physical interfaces are configured, you need to create and configure link aggregation groups. On appliances other than the IP22 50, you can put ports on di ffer ent LAN interface cards in the same aggregation group. For example, you can includ e a port on a card in slot 1 and a port on a card in slot 2 in the same group. On the IP2250, do not include ports on dif ferent IO cards in the same aggregation group. If you use VRRP and VPN-1 NG with appliances other th an the IP2250, you can run firewall synchronization traffic over an aggregated link, regardless of which ports participate in the link. On the IP2250, do not run this traffic over an aggregated lin k tha t is made up of ports on an interface card. T o configure link aggregation groups 1. Click Link Aggregation under Configuration > Interface Configuration in the tree view . 2. In the New Group ID field, enter a numeric va lue that will identify the group of aggregrated interfaces. 3. Click Apply . An entry for the new group appears under Existing Link Aggregation Groups. 4. Use the Primary Port pull-down menu to select a port for the aggregation group. The menu shows the physical names of the interfaces that correspond to the available Ethernet ports. For ex ample, eth1 corresponds to the first built-in Ethernet port, and eth-s5p1 corresponds to port 1 on the NIC in slot 5. Be careful not to select a port that you are using for a management connection. 5. Click Apply . The entry for the aggregation group indicates that the MA C address for the interface you selected is used as the MAC address for all the interfaces in the group. 6. Add a port to the group by selecting a nother interface from the Add Port menu. Caution Do not include port s on different IP225 0 I/O cards in the same aggregation group. This configuration is not supported. 7. Click Apply . Note that Network V oyager ’ s display of the ag gregated bandwidth does not reflec t whether any of the ports are physically up or logically active.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 41 Logical Configuration When you have completed the aggregation group, you must configure it with an IP add ress and so on. Navigate to the Interfaces Configuration page and click the logical name of the group . Network V oyager shows the lo gical name in the format ae xxxc0 . For example, the logical name of a group with the ID 100 is ae100c0 . If you create a link aggregatio n grou p but do not ad d any interfaces to it, th e logical name of the group does not appear on the In terfaces Configuration page. Y ou ca nn ot configure an aggregation group with logical information un til you have added an in terface to the group. Deleting Aggregation Group s T o delete an aggregation grou p, you mu st first remove all the ports fro m the group. T o remove a port from an aggregation grou p, click Delete next to the appropriate port and click Apply . Click Save to make the change permanent. Y ou cannot remove the primar y port from an aggr egation group unless the other ports have be en removed, but you can remove all the ports simu ltaneously . Y ou can simultaneously remove all the ports and delete the group by clicking all the Delete checkbo xes and then clicking Apply . Click Save to make the change permanent. Gigabit Ethernet Interfaces Y ou can configure the parameters listed in Ta b l e 4 for each Gigabit Ethernet interface. For information on how to comple te the configuration of an Gi gabit Ethernet interface, see “T o configure an Ethernet interface” on pag e 35. T able 4 Gigabit Ethernet In terface Parameters Parameter Description Active Select On to enabl e the interface, select Off to disable the interface. These selections appear on both the main Interface Configuration page and the pages for each individual interface. Link T rap Click On or Off to enable or di sable the linkup/linkdown traps for the i nterface. Default is On fo r all physical interfac es. Flow Control Y o u can implement flow control to reduce receiving-buffer overflows, which can cause received packets to be dropped, and to allow local control of network congestion levels. With the flow contro l On , the Gigabit Ethernet card can send flow-control packets and respond to received packets. Default i s Off. Link Recogniti on Delay Specify how many seconds a link must be stable before the in terface is declared up. Default is 6; range is 1-255.
2 42 Nokia Network Voyager for IPSO 4.0 Reference Guide Note Link speed is fixed an d duple x mo d e is set to full at all times for Gigabit Ethernet interfaces. T o configure a Gigabit Ethernet interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure. Example : eth-s5p1 . 3. Set flow control to On. 4. Click Apply . 5. Click the name of the logical inte rface in the logical interfaces table. The Logical Interfa ce page is d isplayed. 6. (Optional) T o increase the maximum length of fra mes, in bytes, that can be transmitted over this device, enter a value for MTU. The default i s 1500. 7. Enter the IP address and subne t mask length fo r the device in the appropriate text fields. 8. Enter the IP address and mask length. Click Apply . MTU The maximum length of frames, in bytes, that can be transmitted over this device. This value limits the MTU of any network protocols that use this device. This option appears only for NICs that have the ca pability of tran smi tting jumbo frames. Default is 1500; range is 1500-16 ,000. Note On the IP2250, the range is 1500-96 00. IP Address & Mask Length Y ou can add multiple IP addresses. Note Do not change the IP address you use in your browser to access Network V oyager . If you do, you can no lo n ge r access the IP security platform with your Network browser . Logical Name Use this to enter a more meaningful name for the interface. Comments (Optional) This field is displayed on the main Interfa ce Configuration and the Logical Interface pages. Use it to a dd a description th at you might find useful in identifying the logical interface. T able 4 Gigabit Ethernet In terface Parameters Parameter Description
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 43 Each IP addresses and mask length that you add are added to the table when you click Apply . The entry fields return to blank to allow you to add more IP addresses. Use the delete check box to dele te IP addresses from the table. 9. (Optional) Change the interface l ogical name to a more meaningful name by typing the preferred name in the Logical na me text box. Click Apply . 10. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 11 . Click Up to go to the In terface Configuration page. 12. Click On button that corresponds to the logical interface you configured. Click Apply . The Gigabit Ethernet interface is now available for IP traffic and routing. 13. T o make your change s pe rmanent, click Save. Point-to-Point Over Ethernet Point-to-Point Over Ethernet (PPPoE) for IPSO pr ovides you with the ability to create multiple point-to-point co nn ectio ns f rom your Ethernet ne twork to your ISP . Configuration is simple and your network can be connected over a bridging device such as a DSL modem. Configuring PPPoE T o configure PPPoE 1. Click Interfaces under Interface Co nfiguration in the tree view . 2. Click the pppoe0 link. The PPPoE physical interface page is displayed. Note The PPPoE physical interface and the assoc iated link trap is on by de fault. If you wish to change either setting, click the appropriate se tting next to the feature you wish to enable or disable and click Apply . 3. Click PPPOE Profile Link. The PPPOE Profile Configuration page is displa yed. Here you can cr eate PPPoE profiles, change profiles, and view existin g profiles on your system. 4. Enter a name for the profile and, optionally , a description.
2 44 Nokia Network Voyager for IPSO 4.0 Reference Guide 5. In the Ethernet Interface drop-down box, select the Ethernet interface you wish to associate with the PPPoE logical interface in the. 6. In the Mode drop-do wn box, select a connection mode. 7. In the T imeout text-box, enter a time in seconds. 8. (Optional) In the Peername text-box, enter the name of the PPPoE server . Note If you use the Peername field , only the P PPo E server named in the field will be al lowed to connect to the system. 9. In the MTU text-box, enter the maximum byte si ze to be transmitted. The default is 1492 bytes. 10. Enter a value in the MSS Clamping text box if end devices connected to this interface are experiencin g co nn ec tiv ity prob le ms with speci fic destinations. See “Configuring MSS Clamping” for more information. 11 . In the Authentication T ype drop-down box, sel ect an authentication type. If you selected P AP or CHAP , you must enter a user name in the Username text box and a password in the Password text box. 12. Click Apply 13. Click Save to make your changes perman en t. T o create more configuration profiles, repeat these steps. 14. Display the Interface Configura tion page. 15. Click the link for the physical PPPoE interface. 16. Ch ose a configuration profile you c reated in the preceding steps from the Create a new interface with PPPoE pro file drop-down box. 17. Click Apply . 18. Click the lin for the logical in terface you wish to configure. This takes you to the Logical interface page. 19. In the Interfa ce type drop-down box, select an interface type.  If you select Static Interface, you must provide the IP address of the logical interface in the Local Address text box and the IP address of remote point-to-point interface in the Remote Address text box.  If you select Unnumbered, the proxy interface should be a logical interface of the physical interface that is associated the PPPoE profile.  If you select Dynamic, the Local Address should be the IP address of the logical interface. The Remote Address should be the name of the logical interface.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 45 Note The PPPoE logical interface is on by default and the associated link trap is disabled by default. If you wish to change either setting , click the appropriate setting next to the feature you wish to enable or disable and click Apply . 20. Click Apply . 21. Click Save to make your changes permanent. T o create PPPoE logical interfaces 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the pppoe0 link. 3. In the Create a new interface with PPP oE profile, select a profile name. 4. Click Apply . 5. Click Save to make your changes permanent. T o delete PPPoE logical interfaces 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the pppoe0 link. 3. Click Delete in the Logical interfaces box as sociated with the PPPoE profile to delete. 4. Click Apply . 5. Click Save to make your changes permanent. T o change configuration profiles 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the pppoe0 link. 3. Click the name of the PPPoE profile in the PPPoE Profil e field. 4. Make changes to the profile as needed. See (l ink to Configuring PPPo E steps 8 through 15.) 5. Click Apply . 6. Click Save to make your changes permanent. T o delete configuration profiles Y ou must first delete the configurati on profile interface before you can delete a configuration profile. For more information, see “T o delete PPPoE logical interfaces.” 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the Interfaces link. 3. Click the pppoe0 link. 4. Click the PPPoE Profile link.
2 46 Nokia Network Voyager for IPSO 4.0 Reference Guide 5. Click Delete. 6. Click Apply . Configuring MSS Clamping When end devices use path MTU discovery , it can cause connectivity problems when their connections pass through PPPoE interfaces. Use the MSS Clamping field to prevent these problems by reducing the maximum segment size (M SS) that is advertised across the outgoing link. IPSO advertises the value in th is field as the MSS for packets that transit this interface. If a connected device (such as a host system) adverti ses a greater MSS, IPSO advertises the value in this field instead of the value advertised by the device. There is no default value for the MSS Clamping field. If you do not enter a value, the MSS advertis ed by end devices is always advertised across the link. If hosts connected to this interface experience c onnectivity problems with some destinations, use this field to restrict the MSS that they can adve rtise. Entering a value of 1452 will probably solve any such problems. See RFC 2923 for more information about how pa th MTU discovery that can caus e connectivity problems. V irtual LAN Interfaces Nokia IPSO supports virtual LAN (VLAN) inte rfaces on all supported Ethernet interfaces. VLAN interfaces lets you configure subnets with a secure private link to Check Point FW -1/ VPN-1 with the existing topology . VLAN enables the multiplexing of Ethernet traf fic into channels on a single cable. The Nokia implemen tation of VLAN supports adding a logical interface w ith a VLAN ID to a physical interface. In a VLAN packet, the OSI La yer 2 header , or MAC header , contains four more bytes than the typical Ethern et header for a total of 18 bytes. When traf fic arrives at the physical interface, the system examines it fo r the VLAN layer-two header and accepts and forwards the traffic if a VLAN logical interface is configured. If the traffic that arrives at the physical interface does not have a VLAN header , it is directed to the channel 0, or untagged, interface. In the Nokia implem entation, the untagged channel-0 interface drops VLAN packets that are sent to the subnets on that interface. Outgoing traffic from a VLAN in terface is tagged with the VL AN header . The Nokia appliance can receive and generate fully conformant IEEE 802.1Q tags. The IEEE802.1Q standard defines the technology for virtual bridged networks. The Nokia implementati on is completely interoperable as a router , not as a switch. IPSO supports a maximum of 1015 VLAN inte rfaces. However , if you do not explicitly configure the system to support this number (in the Maxi mum Number of VLANs Allowed text box), the default maximum is 950 VLAN interface s.This is system limit and not limited to specific interface.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 47 T o configure a VLAN Interface 1. Click Interfaces under Interface Co nfiguration in the tree view . 2. Click the link to the physical Ethernet interface for which you want to enable a VLAN interface. The physical interface page fo r that interface is displayed. 3. Enter a value to identify the VLAN interface in the Create a new VLAN ID text box. The range is 2 to 4094. The values 0 and 4095 are reserved by the IEEE standard. VLAN ID 1 is reserved by conventio n. There is no default. 4. Click Apply . The new logical interface for the VLAN appear s in the Logical Interfaces field with the name eth-sXpYcZ , where X is the slot number, Y is the physical port number and Z is the channel number . The channel numbers incremen t starting with 1 with each VLAN ID that you create. 5. Click Save to make your changes permanent. Repeat steps 2 through 4 for each VLAN interface to create. 6. T o assign an IP address to the new logical VLAN interface, click th e link for the logical interface in the Interface field of the Logical Interfaces table. Enter the IP address in the New IP address text box. Enter the mask le ngth in the New mask length t ext box. 7. Click Apply . 8. Click Save to make your changes permanent. The new logical interface appears as active on the interface configuration page. Click Up to view that page. (Optional) T o disable the interface, click off in the Active field in the row for the logical interface. 9. Click Apply . 10. Click Save to make your change permanent. Note Y ou can assign multiple IP addresses to each logical VLAN interface. T o delete a VLAN Interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the link for the physical in terface for whi ch to delete a VLAN interface in the Physical field. This action takes you to the physical interface page for the interfac e. 3. In the Logical Interface table, click Delete in the row for the logical VLAN interface to delete. 4. Click Apply .
2 48 Nokia Network Voyager for IPSO 4.0 Reference Guide 5. Click Save to make your change perman en t. The entry for the logical VLAN interface disappears from the Logical Interfaces table. T o define the maximum number of VLANs 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Enter a numb er in the Maximum Numb er of VLANs Allowed text box. The maximum value is 1015. 3. Click Apply . 4. Click Save to make your change perman en t. VLAN Example T opology The following topolog y represents a fully redunda nt firewall with load sharing and VLAN. Each Nokia appliance running Check Point FW -1 is co nfigured with the V irt ual Router Redundancy Protocol (VRRP). This protocol provides dynamic failover of IP addresses from one router to another in the event of failure. For more information see VRRP Description. Each appliance is configured with Gigabit Ethernet and supports multiple VL ANs on a single cable. The appliances receive and forward VLAN-tagged traffic to subnets configured for VLAN, creating a secure private network. In addition, the appliances are configured to create VLAN-tagged messages for output. NOK/CP FW-1 NOK/CP FW-1 FW-1 sync switch switch Un tagged VLAN tagged Un tagged VLAN switch VLAN switch GSR GS Multiple VLANs on single cable gigabit Ethernet gigabit Ethernet gigabit Ethernet gigabit Ethernet VRRP pair VRRP pair 00203
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 49 FDDI Interfaces T o configure an FDDI Interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link yo u want to configure in the Physical column. Example: fddi-s2p1 3. Click Full or Half in the Physical Configuration table Duplex field. 4. Click Apply . Note Set device attached to a ring topology to half duplex. If the de vice is run nin g in point-to- point mode, set the duplex setting to full. Th is setting must be the same for all hosts on the network to which the device connect s. 5. Click the logical interface name in the Interfa ce column of th e Logical Interfaces table to go to the Interface page. 6. Enter the IP address for the device in the New IP address text box. 7. Enter the subnet mask length in the New mask length text box. Click Apply . Each time you click Apply , the configured IP ad dress a nd mask length are added to the table. The entry field s remain blank to allow you to ad d more IP addresses. T o enter another IP address and IP subnet mask length, repeat steps 6 through 7. 8. (Optional) Change the interface’ s logical name to a more meaningful on e by typing the preferred name in the Logi cal na me text box. 9. Click Apply . 10. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 11 . Click Up to go the Interface Configuration page. 12. Click On button that corresponds to the logical interface you configured. Click Apply . The FDDI interface is now availa ble for IP traf fic and routing. 13. Click Save to make your changes permanent.
2 50 Nokia Network Voyager for IPSO 4.0 Reference Guide T o change the duplex setting of an FDDI interface Note If the duplex setting of an FDDI interface is in correct, it might not rece ive data, or it might receive duplicates of the dat a it sends. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to change in the Physical column. Example: fddi-s2p1 3. Click Full or Half in the Physical Configuration table Duplex field. 4. Click Apply . Note Set device attached to a ring topology to half duplex. If the device is running in point-to- point mode, set the duplex settin g to full. This sett ing must be the same for all hosts on the network to which the device connects. 5. Click Save to make your changes pe rmanent. T o change the IP address of an FDDI interface Note Do not change the IP address you u se in your browser to access Network V oyager . If you do, you can no longer access the IP security platform device with your browser . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link for which to ch ange the IP address in the Logical column. Example: fddi-s2p1c0 3. T o remove the old IP address, click the delete check box that corresp onds to the address to delete. 4. Click Apply . 5. T o add the new IP address, enter the IP addre ss for the device in the New IP address text box. 6. Enter the subnet mask length in the New mask length text box. 7. Click Apply . Each time you click Appl y , the new IP address and mask length are added to the table. The entry fields remain blank to allow you to add more IP addresses. 8. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 51 ISDN Interfaces Integrated Services Digital Network (ISDN) is a sy stem of dig ital phone connections that allows voice, digital network services, and video data to be transmitte d simultaneously using end-to- end digital connectivity . The Nokia IP security platform of fers support for an ISDN Basic Rate Interface (BRI) physical interface. The ISDN BRI compri ses one 16 Kbps D-channel for signalling and control, and two 64 Kbps B-channels for information transfer . No kia’ s physical interface is certified to conform to the European T elecomm unications S tandards Institu te (ETSI) ISDN standard. The physical interface is the manageable represent ation of the physical connection to ISDN. One physical interface is visible in Network V oya ger for every ISDN BRI card in the Nokia appliance chassis. The physical in terface enables management of the parameters specific to each ISDN connection. The physical interface permits enabling or disabling of the ISDN connection and is the entity under which logical interfaces are created. The logical interface is the logica l communication end point. It co ntains all information used to set up and maintain the ISDN call. The logical interface includes:  Data link encapsulation and addressing  Call connection information such as call dire ction, data rate, and the number to call  Authentication information such as nam es, passwords, and authentication method  Bandwidth allocation for Multilink PPP After configuring the physical in terface, then creating and configur i ng the logical interfaces, the Nokia appliance is ready to make and accept IS DN calls. Detailed information on how to create and configure ISDN interfac es begins in “T o configure an ISDN physical interface.” The ISDN interface support s the following features.  Port —ISDN Basic Rate S/T interface with RJ45 connector  ISDN signaling —ETSI EURO-ISDN (ETS 300 102)  B-channel pr otocols —IETF PPP (RFC 1661 and 1662); IETF Multilink PPP (RFC 1990)  Security —P AP (RFC 1334), CHAP (R FC 1994), and ISDN Caller I D  Dial-on-demand r outin g —you can configure the ISDN interfa ce so that only certain types of traffic establish and ma intain an ISDN connection. Circuits are automatically remo ved if they are not required.  Dynamic ba n dwidth alloca ti on —you can configure the ISDN interface to add or remove additional bandwidth as the traffic requires it.  Multiple destination support— you can configure the ISDN interface to connect to two different destinations simultaneously .  Dial-in support —you can configure the ISDN interface to accept incoming calls from remote sites. T o configure an ISDN physical interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical column.
2 52 Nokia Network Voyager for IPSO 4.0 Reference Guide Example: isdn-s2p1 3. In the Switch T ype pull-down menu, in the Phys ical Configuration table, select the service provider-switch type that corresponds to the interface network conn ection. 4. In the Line T o pology field in the Physical Configuration table, click Point-to-Point or MultiPoint to describe the conn ection type of the interface. 5. Click Automatic or Manual in the TEI Option (t erminal-endpoint identifier) field in the Physical Configuration table. Generally , automatic TEIs are used with multip oint connections, while fixed TEIs are used in point-to-point configuratio ns. 6. Click Apply . 7. (Optional) If you selected Manual as the TEI option, enter the TEI assigned to the ISDN interface in the TEI field. 8. In the Physical Configuration table, click First-Call or PowerUp in th e TEI Assign field to specify when the ISDN Layer 2 (TEI) negotiation to occur .  First-Call—ISDN TEI negotiation should occur when the first ISDN call is placed or received. The first-call option is mainly used in Eu ropean ISDN switch types (for example, ETSI).  PowerUp—ISDN TEI nego tiatio n should o ccur when the route r is powered on. 9. Click Apply . 10. Click Save to make your changes perman en t. T o configure an ISDN logical interface to place calls 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Physical column, click on the IS DN physical-name interface link to configure. Example: isdn-s2p1 3. In using the Encapsulation text box in the Create new Logical In terface table, select whether to run PPP or multilink PPP on the interface. 4. Click Apply . A newly created logical interface appears in th e Inte rface column of the Logical Interfaces table. 5. Click the logical interface name in the Interface column of the Logical Interfaces table to go to the Interface page. 6. If the interface should b e unnumbered, perform steps a and b. If the interface should be numbered, skip to step 7 . In unnumbered mode the inte rface does not have its own unique IP address—the address of another interface is used. a. Click Y es next to Unnumbered interface. b. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 53 c. Use the Proxy interface pull-down menu to select the logical inte rface from which the address for this interface is taken. 7. Enter the IP address for the local end of the connection in the Local address text box in the Interface Information table. Y ou must enter a valid IP address. IPSO does not support dynamically assigned IP addresses for ISDN interfaces. Do not enter 0.0.0.0. 8. Enter the IP address of the remo te end of the connec tion in the Remote ad dress text box in the Interface In formation table. 9. (Optional) Enter a string comment in the Descr iption text box in the Connection Information table to describe the purpose of the logical interface, for example, Connection to Sales Office . 10. Click Outgoing in the Co nnection Information table. 11 . (Optional) Enter the value for th e idle timeout in the Idle T i me text box in the Connection Information table. This time entry defines the time in seconds that an active B-channel can be idle before it is disconnected. A value of zero in dicates that the active B-chan nel will never disconnect. The range is 0 to 99999. The default value is 120. 12. (Optional) Enter the value for the minimum ca ll time in the Minimum Call Time text box in the Connection In formation table. This entry defines the minimum number of seconds a call must be connected before it can be disconnected by an idle timeout. A value of 0 indicates that the call can be disconnected immediately upon expiration of the idle timer . If the service pro vider ha s a minimum char ge for each call, Nokia recommends the minimum call time be set to this value. The range is 0 to 99999. The default value is 1 20. 13. Click the 64 Kbps or 56 Kbps radio button in the Rate field in the Connection Information table to set the data rate for outgoing calls. 14. Ente r values for a remote numb er and subaddress in the Remote Number and (optional) Remote Sub Number text boxes in the Connection Information table. 15. (Optional) Enter values for a calling number and subaddress in th e Calling Number and Calling Sub Number text boxes in the Connection Information table. The calling number and subaddress are inserted in a SETUP message when an outgoing call is made. Note The Authenticatio n t able en tries, which follow , allow the user to ma nage the pa rameter s used to authenticate both ends of the commu nication link. 16. In the T o Remote Host section of the Authenti cation table, in the Name text box, enter the name that needs to be retu rned to a remote host when it attempts to authenticate this host.
2 54 Nokia Network Voyager for IPSO 4.0 Reference Guide 17. In the T o Remot e Host section of the Authentication table, in the Password t ext box, enter the password to be returned to the remote host for P AP authentication, or the secret used to generate the challeng e respon se for CHAP authentication. Note The T o Remote Host information must be the same as the From Remote Host information (or its equivalent ) at the re m ote en d of the link . 18. In the From Remote Host s ection of the Authentication ta ble select the authentication method used to authen ticate the remote host. 19. In the From Remote Host section of the Authentication table, in the Name text box, enter the name that will be returned from the remote host when this host attemp ts to authenticate the remote host. 20. In the From Remote Host section of the Authentication table, in the Password text box, enter a password to be returned by th e remote host for P AP authenti cation, or the secret used to validate the challenge respon se for CHAP authentication. Note The From Remote Host information must be th e same as the T o Remote Host information (or its equivalent ) at the re m ote en d of the link . Note The Bandwidth Allocation t able entries that follow allow the network administrator to manage the p arameters that are used to deter mi ne when to add or re move an additional B-channel only when using Multilink PPP . 21. In the Bandwidth Allocation table, in the Ut ilization Level text box, enter a percentage bandwidth use le ve l at which the additional B-cha nnel is added or removed. When the measured use of an ou tgoing B-channel ex ceeds the utilization level threshold for a period greater than the use period, the second B-channel is brought into operation. When the outgoing B-channel use falls bel ow the use level for a period greater than the value of the use period, the second B-chan nel is removed from operation. A use level of zero means that the second B- channel is never brought into operation. T o bring the second B-channel into operation quickly , set the use le vel to a low nu mber , such as one. 22. In the Bandwidth Allocation table, in the Utiliz ation Period text box, enter the use period. This value specifies the number of seconds th e outgoing B-channel use must remain above the use level before a second channel is brough t into operation. When a second B-channel has been added, this value speci fies the number of seconds th a t the use of the outgoing B- channel must be below the use level befo re the second B-channel is removed from operation.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 55 A use period set to zero will cause the second B-channel to be brought into operation immediately; the utilization level has been exce eded. It will also caus e the second B-channel to be removed from operation; immediately the measured u tilization drops below the use level. 23. Click Apply . 24. Click Save to make your changes permanent. For troubleshooti ng information, see “ISDN Tr o ubl eshooting.” T o configure an ISDN interface to receive calls 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface to co nfigure in the Physical column. Example : isdn-s2p1 3. Select whether to run PPP or multilink PP P on the interface from the Encapsulation text box in the Create New Logical Interf ace table; then click Apply . A new logical interface appears in the Interf ace c olumn of the Logical Interfaces table. 4. Click the logical interface name in the Interface column of th e Logical Interfaces table to go to the Interface page. 5. Enter the IP address for the local end of the connection in the Local address text box in the Interface Information table. 6. Enter the IP address of the remo te end of the connec tion in the Remote ad dress text box in the Interface In formation table. 7. Click Incoming in the Co nnection Information table. 8. Click Apply . 9. T o configure the list of incoming numbers with permission to call into this interface, click the Incoming Numbers link. Note If no incoming call numbers are configured, all incomi ng calls will be accepted. 10. In the T o Remote Host section of the Authenti cation table, in the Name text box, enter the name to be returned to a remote host wh en it attempts to au thenticate this host. 11 . In the T o Remote Host section of the Authenti cation table, in t he Password text box, enter the password to be returned to the remote host for P AP authentication, or the secret used to generate the challeng e respon se for CHAP authentication. Note The T o Remote Host information must be the same as the From Remote Host information (or its equivalent ) at the re m ote en d of th e link .
2 56 Nokia Network Voyager for IPSO 4.0 Reference Guide 12. In th e From Remote Host section of the Authen tication table select the authentication method used to authen ticate the remote host. 13. In the From Remote Host section of the Authentication table, in the Name text box, enter the name that is returned from the remote host when this host attempts to authenti cate the remote host. 14. In the From Remote Host section of the Authentication table, in the Password text box, enter a password to be returned by th e remote host for P AP authenti cation, or the secret used to validate the challenge respon se for CHAP authentication. Note The From Remote Host in formation must be the same as the T o Remote Host information (or its equival ent) at the remote end of the link. 15. Click Save to make your changes perman en t. For troubleshooti ng information, see “ISDN Tr o ubl eshooting.” Configuring Calling Line-Identification Screening Y ou can filter incoming calls to the Nokia applianc e by using the calling number in the received SETUP message. The network must support Calling Line Identification (CLID) to filter calls by using the calling number . When an incoming call is rece ived, the calling number in th e received SETUP message is checked against the incoming numbers configured on each logi cal interface. The calling number is compared with each incoming call using the right-most-digits algorithm. A number matches if the shortest string between the received calling number and the incoming number is the same. For example, if the calling number received was 345 and the logical interface has an incoming number of 12345, then this is deemed a match. The call is answered on the interface that is configured with the inco ming number with the highest number of matchi ng digits. If no matchi ng incoming number is found, the call is rejected. If no incoming numbers are config ured on an interface, any inco ming call is deemed a match. Detailed information on how to add and delete incoming numbers to the logical interface follows. T o add an incoming number 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link in the Physical column. Example : isdn-s2p 1 3. Click the logical interface link in the Logical Interfaces table. 4. Click the Incoming Numbers link.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 57 In the Number text box, enter the t elephone number on wh ich to accept incoming cal ls. An x is used to repre sent a wild-card charac ter . 5. Click Apply . 6. Click Y es in the Callback field for the incoming call to be di sconnected, an d an outgoing call attempted; otherwise, click No to have the incoming call answered. If Callback is set to Y es, the Nokia appliance uses the number in the Remote Number field on the logical interface to make the outgoing call. 7. If Callback is set to Y es, enter the valu e for the timeout in the timeout field. This is the amount of time (in seconds) that th e Nokia appliance waits before placing a call back to the remote system. The range is 0 to 999. The default is 15. 8. Click Apply . 9. Click Save to make your changes permanent. For troubleshooti ng information, see “ISDN Tr o ubl eshooting.” T o remove an incoming number 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link in the Physical column. Example: isdn-s2p1 3. Click the logical interface link in the Logical Interfaces table. 4. Click the Incoming Numbers link. 5. Find the incoming number to remove in the Numbers table, click its corresponding Delete button, and then click Apply . 6. Click Save to make your changes permanent. T o configure an interface to place and receive calls 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical column. Example : isdn-s2p1 3. Select whether to run PPP or multilink PP P on the interface from the Encapsulation text box in the Create New Logical Interface section. 4. Click Apply . A new logical interface appear s in the Interface column. 5. Click the logical interface name in the Interface column of the Logical interfaces table to go to the Interface page. 6. Enter the IP address for the local end of th e connection in the Local address text box. 7. Enter the IP address of the remote end of th e co nnection in the Remo te add ress text box. 8. Click Both Direction.
2 58 Nokia Network Voyager for IPSO 4.0 Reference Guide 9. Click Apply . Note Follow step s 8 through 21 i n “T o configure an ISDN logical interface to place calls” to set the information for outgoing calls. For more informati on about how to set up incoming numbers see “T o add an incoming number” . 10. Click Save to make your changes perman en t. For troubleshooti ng information, see “ISDN Tr o ubl eshooting.” Dial-on-Demand Routing (DDR) List s As ISDN connections attract charges to establish an d maintain connections, it is useful to have only certain types of packets cause the connection to be set up. It is also useful to have timers determine how long the connectio n should be maintained in the absence of these packets. A Dial-on-Demand Routing (DDR) l ist is used to determine the packets th at should bring up and maintain an ISDN connection. This section expl ains how to configure DDR lists for ISDN interfaces. A DDR list is composed of one or more rules that are used to determine if a packet is inter esting . Interesting packets are those that establish and ma intain a connection. Each rule has a set of values used to match a packet and an action to take when a matc h occurs. The following are th e possible actions:  Accept —this is an interesting packet.  Ignore —this is not an interesting packet.  Skip —this rule is ignored. When a packet matches a rule in the DDR list with an accept action, that packet is regarded as interesting. An interesting pack et causes the ISDN interface to set up a call by using the is passed over the interface. The traf fic passed could include tra f fic, which configur ed in the DDR list, with an ignor e action. If no packets that match an ac cept rule in the DDR list are transmitted in the configured idle time, th e connection is automatically disc onnected. A DDR list is created with a default rule that matches al l packets. The associated action is accept . This action can be set to skip so that all unmatche d packets are deemed uninteres ting . Note Setting a rule to skip ef fectively turns the rule off. It is important to understand the difference between Access lists and DDR lists and how the two interoperate. When a packet is sent over an interface, any Access lis t applied to that interface is checked first. If the packet matc hes any rule in the Access list, the associa te d action is taken. Therefore, if the packet matche d a rule in the Access list that had an associated action of drop,
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 59 the packet is never sent over the ISDN interface. After the packet is checke d against the Access list, the DDR list applied to the interface (if any) is then checked. Note A DDR list, therefore, on ly affect s which packet s will cause a c onnection to be established and maintained. If no DDR list is applied to an ISDN interface, all traffic received by the interface is deem ed interesting. T o create a DDR list 1. Click Dial on Demand Rou ting under Configu ration > Traf fic Manageme nt in the tree view . 2. Enter a name for the DDR list in the Create New DDR List text box. 3. Click Apply . The DDR list name, Delete ch eck box, and Add Interfaces dr op-down window will appear . Only the default rule will display in the DDR list unti l you create your own rule. 4. Click Save to make your changes permanent. T o delete a DDR list 1. Click Dial on Demand Rou ting under Configu ration > Traf fic Manageme nt in the tree view . 2. Click the Delete check box next to the DDR list name to delete; then click Apply . The DDR list name disappears from the DDR List Configuration page. 3. T o make your changes permanent, click Save. T o add a new rule to a DDR list 1. Click Dial on Demand Rou ting under Configu ration > Traf fic Manageme nt in the tree view . 2. Locate the DDR list to which yo u want to add the new rule. 3. Click the Add New Rule Before check box. 4. Click Apply . The new rule appears above the default rule. Note When you create more rules, you can add rules be fore other rules. For example, if you have four rules—rules 1, 2, 3, and 4—you ca n place a new rule between rules 2 and 3 by checking the Add Rule Before check box on rule 3. 5. Click Save to make your changes permanent.
2 60 Nokia Network Voyager for IPSO 4.0 Reference Guide T o modify a rule 1. Click Dial on Demand Routin g under Configur ation > T raffic Management in the t ree view . 2. Locate the DDR list that cont ains the rule to modify . Y ou can modify the following items:  Action  Source IP address  Source mask length  Destination IP address  Destination mask length  Source port range—you can specify the source port range only if the selected protocol is either “any ,” “6,” “TCP ,” “17,” or “ UDP .”  Destination port range—you ca n specify the destination port range only if the selected protocol is either “any ,” “6,” “TCP ,” “17,” or “UDP .”  Protocol 3. Modify the values in one or more of the text boxes or drop-do wn window or deselect a button. Click Apply . 4. Click Save to make your changes pe rmanent. T o apply or remove a DDR list to/from an interface 1. Click Dial on Demand Routin g under Configur ation > T raffic Management in the t ree view . 2. Locate the appropriate DDR list. 3. T o apply a DDR list to the interface, select th e appropriate interface from the Add Interfaces drop-down window and click App ly . The new interface appears in the Selected Interfaces section. 4. T o remove a DDR list from an interface, clic k the Delete check box next to the interface under the Selected Interfaces section and click Apply . The interface disappears from th e Selected Interfaces section. 5. Click Save to make your changes pe rmanent. Example DDR List The following example illustrates how to configur e a DDR list so that RI P packets do not cause an ISDN connectio n to be established nor keep an active connection running. RIP packets can, however , be exchan ge d over an established ISDN connection. The DDR list is added to the isdn-s2p2c1 ISDN interface. 1. Click Dial on Demand Routin g under Configur ation > T raffic Management in the t ree view . 2. Enter NotRIP in the Create New DDR List text box.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 61 3. Click Apply . 4. Under the Existing rules for No tRIP table, click the Add New Rul e Before check box. 5. Click Apply . 6. Enter 520 in the Dest Port Range text box in the Existing rules for NotRIP table. 7. Select ignore from the Action dro p-down wind ow in the Existing rules for NotRIP tabl e. 8. Select isdn-s2p1c1 from the Add Interfaces d rop-down window . 9. Click Apply . 10. Click Save. ISDN Network Configuration Example The following figure shows the network conf iguration for the example d escribed below . A Nokia IP330 Security Platform at a remote br anch of fice connects to a Nokia IP650 Security Platform in a company’ s main of fice through ISDN by using PPP . Considering the nature of the traff ic being tr ansmitted and the charging rates on an ISDN network, the ISDN interface on th e Nokia IP330 in this example has its minimum-call timer set to four minutes and its idle tim er set to one minute. The Nokia IP330 is configured to send a username and passwo rd to the main office. The Nokia IP650 is configured so that only incomi ng calls that originate from the Nokia IP330 is answered. The PPP connection is in this exampl e, the default va lues for the ISDN interface are acceptable. Therefore, no configuration of the physical interface is required. 206.226.5.1 eth-s1p1 192.168.24.65 eth-s3p1 206.226.15.1 206.226.5.2 206.226.5.3 192.168.24.66 192.168.24.67 isdn-s4p1 00067 ISDN Cloud ISDN phone number 384020 206.226.15.2 isdn-s2p1 ISDN phone number 38400
2 62 Nokia Network Voyager for IPSO 4.0 Reference Guide T o configure the IP330 to place an outgoing call 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click isdn-s2p1 in the Phys ical column of the table. 3. Select PPP from the Encapsulation text box in the Create New Logical Interface table. Click Apply . A new logical interface appears in the Interf ace c olumn of the Logical Interfaces table. 4. Click the logical interface name in the Interface column of the Logical Interfaces table to go to the Interface page. 5. Enter 206.226.15.2 in the Local Address text box in the Interface In formation table. 6. Enter 206.226.15.1 in the Remote Address text box in the Interface Information table. 7. In the Connection Information table, enter Main Office in the Description text box so that the connection is easily identified. 8. Check Outgoing. 9. Enter 60 in the Idle T ime text box in the Connection In formation table. 10. Enter 240 in the Minimum Call T ime text box in the Connection Information table. 11 . Enter the number 384020 in the Remote Number text bo x in the Connection Information table. 12. Enter User in the Name text box under the T o Re mote Host heading in the Authentication table. 13. Enter Password in the Password text box un der the T o Remote Ho st heading in the Authentication table. 14. Click Apply . 15. Click Save. T o configure the IP650 to handle an incoming call 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click isdn-s4p1 in the Phys ical column of the table. 3. Select PPP from the Encapsulation text box in the Create New Logical Interface table. 4. Click Apply . A new logical interface appears in the Interf ace c olumn of the Logical Interfaces table. 5. Click the logical interface name in the Interface column of the Logical Interfaces table to go to the Interface page. 6. Enter 206.226.15.1 in the Local Address text box in the Interface In formation table. 7. Enter 2 06.226.15.2 in the Remote Address text box in the Interface Information table. 8. In the Connection Interface table, enter Remote Office in the Desc ription text box so that the connection is easily identified.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 63 9. Click Incoming. 10. Select CHAP as the authentication method in the Authentication table. 11 . Enter User in the Nam e text bo x under the Fr om Remote Host section in the Authentication table. 12. Ente r Password in the Password text box un der the From Remote Host section in the Authentication table. 13. Click Apply . 14. Click the Incoming Numbers link. 15. Enter 384000 in the Number text bo x under the Add In coming Call Information section. 16. Click Apply . 17. Click Save. Sample Call T races Sample traces for call setup between the Nokia IP Security platform follow . The traces were produced by issuing th e following command on each device: “ tcpdump -i <interface> .” T raf fic was generated by doing a “ ping 206.226.15.1 ” on the Nokia IP330. Note T o display the negotiated PPP values, run the tcpdump command with the -v switch.
2 64 Nokia Network Voyager for IPSO 4.0 Reference Guide The trace for connecting a call from the Nokia IP330 is: 06:23:45.186511 O > PD=8 CR= 23(Orig) SETUP:Bc:88 90. CalledNb:80 33 38 34 30 32 3 0.SendComp: 06:23:45.255708 I < PD=8 CR= 23(Dest) CALL-PROC:ChanId:89. 06:23:45.796351 I < PD=8 CR= 23(Dest) ALERT: 06:23:45.832848 I < PD=8 CR= 23(Dest) CONN:DateTime:60 06 0c 05 2d. 06:23:45.833274 O B1: ppp-lc p: conf_req(mru, magicnum) 06:23:45.971476 I B1: ppp-lc p: conf_req(mru, authtype, magicnum) 06:23:45.971525 O B1: ppp-lc p: conf_ack(mru, authtype, magicnum) 06:23:48.966175 I B1: ppp-lc p: conf_req(mru, authtype, magicnum) 06:23:48.966217 O B1: ppp-lc p: conf_ack(mru, authtype, magicnum) 06:23:49.070050 O B1: ppp-lc p: conf_req(mru, magicnum) 06:23:49.078165 I B1: ppp-lc p: conf_ack(mru, magicnum) 06:23:49.085662 I B1: challe nge, value=0311bb3b42dec57d1108c728e575 ecc22ddf0a06b3d0b1fe46687c97 0bb91fa4688d417bf72a0bca572c7e4e16, name= 06:23:49.085729 O B1: respon se, value=dd379d2b5e692b6afef2be e361e32bca, name=User 06:23:49.094922 I B1: succes s 06:23:49.094969 O B1: ppp-ip cp: conf_req (addr) 06:23:49.097161 I B1: ppp-ip cp: conf_req (addr) 06:23:49.097194 O B1: ppp-ip cp: conf_ack (addr) 06:23:49.102159 I B1: ppp-ip cp: conf_ack (addr) 06:23:49.102200 O B1: 206.22 6.15.2 > 206.226.15.1: icmp: echo request 06:23:49.102224 O B1: 206.22 6.15.2 > 206.226.15.1: icmp: echo request 06:23:49.102241 O B1: 206.22 6.15.2 > 206.226.15.1: icmp: echo request 06:23:49.102257 O B1: 206.22 6.15.2 > 206.226.15.1: icmp: echo request 06:23:49.128295 I B1: 206.22 6.15.1 > 206.226.15.2: icmp: echo reply 06:23:49.139918 I B1: 206.22 6.15.1 > 206.226.15.2: icmp: echo reply 06:23:49.151558 I B1: 206.22 6.15.1 > 206.226.15.2: icmp: echo reply 06:23:49.163297 I B1: 206.22 6.15.1 > 206.226.15.2: icmp: echo reply 06:23:49.220161 O B1: 206.22 6.15.2 > 206.226.15.1: icmp: echo request 06:23:49.246309 I B1: 206.22 6.15.1 > 206.226.15.2: icmp: echo reply The trace for re ceiving an incoming on IP650 follows: 15:10:09.141877 I < PD=8 CR= 36(Orig) SETUP:SendComp:Bc:88 90.ChanId:89.CallingNb:00 83 33 38 34 30 30 30.CalledNb:80 33 38 34 30 32 30. 15:10:09.186313 O > PD=8 CR= 36(Dest) CONN: 15:10:09.250372 I < PD=8 CR= 36(Orig) CONN ACK: 15:10:09.425571 O B1: ppp-lc p: conf_req(mru, authtype, magicnum) 15:10:09.434996 I B1: ppp-lc p: conf_ack(mru, authtype, magicnum) 15:10:12.420103 O B1: ppp-lc p: conf_req(mru, authtype, magicnum) 15:10:12.429646 I B1: ppp-lc p: conf_ack(mru, authtype, magicnum) 15:10:12.532897 I B1: ppp-lc p: conf_req(mru, magicnum) 15:10:12.532943 O B1: ppp-lc p: conf_ack(mru, magicnum) 15:10:12.533133 O B1: challenge,value=0311bb3b42de c57d1108c728e575ecc22ddf0a06b3d0b1fe46687c9
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 65 70bb91fa4688d417bf72a0bca572 c7e4e16, name=15:10:12.549898 I B1:response,value=dd379d2b5e 692b6afef2bee361e32bca, name=User 15:10:12.549968 O B1: succes s 15:10:12.550039 O B1: ppp-ip cp: conf_req (addr) 15:10:12.557258 I B1: ppp-ip cp: conf_req (addr) 15:10:12.557300 O B1: ppp-ip cp: conf_ack (addr) 15:10:12.559629 I B1: ppp-ip cp: conf_ack (addr) 15:10:12.573896 I B1: 206.22 6.15.2 > 206.226.15.1: icmp: echo request 15:10:12.574017 O B1: 206.22 6.15.1 > 206.226.15.2: icmp: echo reply ISDN T roubleshooting Logging ISDN sends messages to the system message log. Whether a message is sent to the log or not depends on the logging setting of the ISDN interface. Log messag es are of one of the followi ng levels of severity .  Error —an error condition occurred  Wa r n i n g —a warning condition  Informational —a normal event o f note Setting a logging to a particular level means all messages of this severity and higher are sent to the message log. For example, if you set logging to Error , a ll error messages are sent to the message log. ISDN logs messages for the following informational events:  ISDN Layer 1 protocol activated o r deactivated  Expiration of Layer 1, Layer 2, and Layer 3 timers  An attempted outgoing call  An incoming call being received  A call being connected  A call being disconnected T o set level of messages logged 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical column. Example : isdn-s2p1 3. From the pull-down menu in the Logging field, select the leve l of messages for ISDN to log. All messages of this level and be low are sent to the message log. T o view the message log 1. Click Monitor on the home page. 2. Click the V iew Message Log link under the System logs heading.
2 66 Nokia Network Voyager for IPSO 4.0 Reference Guide The most recent system log messages appear . T racing Y ou can use the tcpdump utility to trace ISDN D-channel traffic (Q.921 and Q.931 protocols) and B-channel traf fic (PPP/multilink PPP and TCP/IP protocols). When running tcpdump on an ISDN interface, if no options are given on the comman d line, the following messages are decoded and displayed:  Q.931 messages  PPP messages and the fields inside them  Any IP traffic on the B-channels If -e option is specified on the command line, in addition to th e preceding messages, all Q.921 messages are also decoded and displayed. If the -v option is used, Q.931 messages are displayed. Also the fields in all PPP messages and their values are displayed in an extended format. T o trace ISDN traffic using tcpdump 1. Create a telnet session and log in to the firewall. 2. Enter tcpdump -i <isdn-interface> T roubleshooting Cause Codes Use the following debug command s to display the ISDN cause code fields in the following table: i=0xy1y2z1z2 a1a2 T able 5 ISDN Cause Code Fields Cause Code Description y1 8 - ITU-T standard coding y2 0 - User 1 - Private network serving local user 2 - Public network serving local user 3 - T ransi t network 4 - Public network serving remote user 5 - Private network serving remote user 7 - International network A - Network beyond Internetworking point
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 67 ISDN Cause V alues Descriptions of the cause-value field of th e cause-information element are shown in the following ISDN cause value table. Cause-value numbers are not consecutive. z1 Class of cause value z2 V alue of cause value a1 (Optional) Diagnostic field that is always 8. a2 (Optional) Diagnostic field that is one of the following value s: 0 is Unknown, 1 is Permanent, and 2 is Transient T able 6 Cause V alues Cause Cause Description Diagnostics 1 Unallocated (unassigned) number Note 12 2 No route to specified transit netwo rk T ransit-network identity (No te 1 1) 3 No route to destination Note 12 6 Channel unacceptable 7 Call awarded and being delivere d in an established channel 16 Normal call clearing Note 12 17 User busy 18 No user responding 19 No answer from user (user alerted) 21 Call rejected User-supplied diagnostic (Notes 4 & 12) 22 Number changed 26 Non-selected user clearing 27 Designation out of order 28 Invalid number format 29 Facility rejected Facility identi fication (Note 1) T able 5 ISDN Cause Code Fields Cause Code Description
2 68 Nokia Network Voyager for IPSO 4.0 Reference Guide 30 Response to ST A TUS ENQUIRY 31 Normal, unspecified 34 No circuit or channel available Note 10 38 Network out of order 41 T emporary failure 42 Switching-equipment congestion 43 Access information discarded Discard ed information-eleme nt identifier(s) (Note 6) 44 Requested circuit / channel not available Note 10 47 Resources unavailable or unspe ci fied 49 Quality of service unavai lable. See ISDN Cause Values t able. 50 Requested facility not subscrib ed Facility identificati on (Note 1) 57 Bearer capability not authorized Note 3 58 Bearer capability not presently available Note 3 63 Service or option not available or specified Note 3 65 Bearer capability not implemented Note 3 66 Channel type not implemented Channel T ype (Note 7) 69 Requested facility not implemen ted Facility Identification (Note 1) 70 Only restricted digital-information bea rer is available 79 Service or option not available or specified 81 Invalid call-reference value 82 Identified channel does not exist Channel identity 83 A suspended call exi sts, but call identity doe s not exist 84 Call identity in use 85 No call suspended T able 6 Cause V alues Cause Cause Description D iagnostics
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 69 Notes for Ta b l e 6 :  Note 1 —The coding of facility identification is network dependent.  Note 2 —Incompatible parameter is composed of incompatible in formation el ement identifier .  Note 3 —The format of the diagnostic field fo r cause 57, 58, and 65 is show n in the ITU-T Q.931 specification.  Note 4 —User-supplied diagnostic field is enco ded according to the user specification, subject to the maximum length of the cause- information element. The coding of user- supplied diagnostics should be made in such a way that it do es not conflict with the codi ng described in T able B-2.  Note 5 —New destination is formatted as the ca lled-party number information element, including information element id entifier . Transit network selec tion might also be included. 86 Call having the req uested-call identity has been cleared Clearing cause 88 Incompatible destination Incompatible parameter (Note 2) 91 Invalid transit-netw ork selection 95 Invalid message, unspe cified 96 Mandatory informa tion element is missing Information element identifiers Information-element identifi ers is missing 97 Message type non-existent or not implemented Message type 98 Message not compatible with call state or message type or not implemented Message type non-existent 99 Information-element non-exi ste nt or not implemented Information-element identifi ers not implemented (Notes 6 & 8) 100 Invalid-information element Information-element identi fiers contents (Note 6) 101 Message not compatible with call Message type state 102 Recovery on timer expires T imer number (Note 9) 1 1 1 Protocol error , unspecified 127 Internetworking, unspecified T able 6 Cause V alues Cause Cause Description Diagnostics
2 70 Nokia Network Voyager for IPSO 4.0 Reference Guide  Note 6 —Locking and non-locki ng sh ift pro cedures described in the ITU-T Q.931 specification apply . In principle, information element identifiers are in the same order as the information elements in the received message.  Note 7 —The following coding applies: Bit 8, extension bit Bits 7 through 5, spare Bits 4 through 1, according to T able 4-1 5/Q.931 octet 3.2, channel type in ITU-T Q.931 specification.  Note 8 —When only the locking shi ft- information element is includ ed and no variable length information-element identifier follows, it means th at the codeset in the locking shift itself is not implemented.  Note 9 —The timer number is co ded in IA5 characters. The following coding is used in each octet: Bit 8, Spare “0” Bits 7 through 1, IA5 character  Note 10 —Examples of the cause values to be used for various bu sy or congested conditions appear in Annex J of the ITU-T Q.931 specification.  Note 1 1 —The diagnostic field c ontains the entir e transit network selection or network- specific facilities informatio n element, as applicable.  Note 12 —For the coding that is used, see ISDN Cause Codes table. ISDN Bearer-Cap able V alues The ISDN bearer-capability values that display in the SETU P packet using the tracing tcpdump command follows: 0x8890 for 64 Kbp s or 0x218F for 56 Kbps V alue Description 88 ITU-T coding standard; unrestricted d igital information 90 Circuit mode, 64 Kbps 21 Layer 1, V .1 10 / X.30 8F Synchronous, no in-band neg otiation , 56 Kpbs
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 71 T oken Ring Interfaces T o configure a T oken Ring interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical column. Example: tok-s3p1 The physical interface setup page ap pears. 3. In the Ring Speed column of the Physical conf iguration table, select the desired value: 16 Mbit/sec or 4 Mbit/sec. There is no default value. 4. In the MTU field, enter the desired value. The minimum for both ring speeds is 56 0. The maximum MTU for 4 Mbs is 4442, and th e maximum MTU for 16 Mbs is 17792. 5. In the Allow Source routes (Multi-Ri ng) field, select On or Off. Default is On. This feature specifies wh ether or not to support source routes. 6. In the Select Use Broadcast instead of Multicast field, se lect On or Of f. Default is Off. This option sp ecifies the mapping of an IP multicast address. When the option is on, it maps a multicast address to an all-ring broadcast address: [ ff:ff:ff:ff:ff:ff ]. When the option is of f, it maps a multicast IP address to an IEEE- assigned IP multicast group address: [noncanonical form: c0:00:00:04:00:00 ]. 7. Click the logical interface name in the Interface column of the Logical interfaces table to go to the Interface page. 8. In the Active column of the Logical interfaces table, select On or Off. Default is On. This setting enables or disables the logi cal interface. Use this switch to control access to the network or virtual circu it that corresponds to the logical interface. 9. Click Apply . Click Up to return to the interface configuration page. 10. Click the logical interface link to configure in the Logical column. Example : tok-s3p1c0 The logical interface setup page appears. 11 . Enter the IP address for the device in the New IP address text box. 12. Enter the IP subnet mask length in the New Mask Length text box. Click Apply . Each time you click Apply , the configured IP ad dress a nd mask length are added to the table. The entry field s remain blank to allow you to ad d more IP addresses.
2 72 Nokia Network Voyager for IPSO 4.0 Reference Guide 13. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical na me text box. Click Apply . 14. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 15. Click Save to make your changes perman en t. T o deactivate a T oken Ring interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Active column of the interface to deactivate, click of f. 3. Click Apply . 4. Click Save to make your changes pe rmanent. T o change a T oken Ring interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Physical column, c lick the physical interface link to ch ange. Example: tok-s3p1. T o change only the properties of a logical interface, proceed to Step 6. The Physical Interface Setup page appears. 3. Perform the following procedures to make the desired changes. If no change is desired, skip this step. a. In the Ring Speed column of the Physical configuration table, sele ct the desired value: 16 Mbit/sec or 4 Mbit/sec. There is no default value. b. In the MTU field, enter the desired value. The minimum for both ring speeds is 560. The maximum MTU for 4 M bs is 4442, and the maximum MTU for 16 Mbs is 1779 2. c. In the Allow Source routes (Multi-Ring) fiel d, select On or Off. Default is On. d. In the Select Use Broadca st instea d of Multicast, select On or Off. Default is Of f. e. In the Active column of the Logical interfaces table, select On or Off. Default is On. 4. Click Apply . 5. Click Up to return to the interface configuration page. 6. (Optional) T o change a logical interface link, c lick the logical interface link to change in the Logical column. Example: tok-s3p1c0 The Logical Interface setup page appears. 7. Perform the following procedures to make the desired changes.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 73 If no change is desired, skip the step. a. T o change the IP address, enter the appropri ate IP address in the New IP address field,. There is no default. b. In the New mask length field, enter the approp riate value. The range is 8 to 30, and there is no default. c. T o delete an IP address , click the Delete box. Note Changing an IP address and dele ting an IP add ress at the same time prevent s multiple addresses from being assigned to a single inter face. 8. Click Apply . 9. Click Save. T oken R ing Example This section describes how you might use Network V oyager to configure the interfaces of your IP security platform in an example network. In a company’ s main office, IP650 A terminates a serial line to an Internet service provider , running PPP with a keep alive value of 10. IP650 A also provides Internet access for an FDDI ring and a remo te branch office connected a with T oken Ring. The branch of fice contai ns IP650 B, which routes t raffic be tween a local fast Ethe rnet network and a T oken Ring. IP650 B provides access to th e main office and the Internet. This example configures the T oke n Ring interface on IP650 A.
2 74 Nokia Network Voyager for IPSO 4.0 Reference Guide The following figu re shows the network configuratio n for this example. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Select tok-s2p1 in the Physical column of the table. 3. Set the desired value in the Ring Speed co lumn of the Physical configuration table. Note This setting must be the same for all host s on the ne twor k to which the device co nne ct s. 4. Enter the desired MTU value. 5. In the Allow Source routes (Multi- Ring) field, select On or Of f. 6. In the Select Use Broadcast instead of Multicast, select On or Off. 7. Under the Active column of the Logical interfaces table, select On or Off. 8. Click Apply . Click Up to return to the interface configuration page. 9. Click the logical interface link to configure in the Logical column. Nokia Platform A Nokia Platform B tok-s2p1c0 (192.168.3.2) tok-s1p1c0 (192.168.3.1) ser-s1p1c0 (192.168.2.1) eth-s2p1c0 (192.168.4.1/24) 192.168.4.xxx FDDI 192.168.1.xxx (192.168.1.1/24) 192.168.3.4 192.168.3.5 fddi-s3p1c0 (192.168.2.93) Provider 00038 Server Server Server (Optional) Server (Optional) Server T oken Ring MAU
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 75 10. In the New IP Addres s field, enter the appropriate IP address. 11 . In the New Mask Length field, enter the appropriate value. 12. Click Apply . 13. Click Save. Point-to-Point Link over A TM T o configure an A TM interface Note Y ou cannot configure an A TM interface with an IP addre ss until at least one logi cal interfac e is created for the in terface. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physi cal column on the Interface Configuration page. Example: atm-s2p1 The Physical Interface page is displayed. 3. Select SONET or SDH as the framing form at in the Physical Configuration table. Note SONET and SDH settings are available on ly if the A TM interface card supports them. The setting should matc h the type of transmission netw ork to which the interface is connected. 4. Select Freerun or Loop T iming as the transmit clock choice in the Physical Config uratio n table. Note The T ransmit Clock settings are available only if the A TM interface card supports them . Freerun uses the internal clock. If two A TM inte rfaces are directly connected, at le ast one of them must use the internal clock. Loop timing derives the transmit cloc k from the recovered receive clock 5. Select the VPI/VCI range in the VPI/VCI Range Configuration list box. 6. Select point-to-point in the T ype list bo x in the Create a new LLC/SNokia Platform RFC1483 interface section. Enter the VPI/VCI number in the VPI/VCI text box.
2 76 Nokia Network Voyager for IPSO 4.0 Reference Guide 7. Click Apply . A new logical interface appears in the Interface column. The new interfa ce is on by default. Y ou can add more A TM logical inte rfaces by repeating this action. 8. Click the logical interface name in the Interface column of the Logical Interfaces table to go to the Logical Interface page. 9. Enter the IP address for the local end of the PVC in the Local Address text box. 10. Enter the IP address of the remote end of the PVC in the Remote Address tex t box. Click Apply . 11 . Enter a number in the IP MTU text box to co nfigure the device’ s maximum length (in bytes) of IP packets transmitted in this interface. Click Apply . The default value is 1500 . Note The maximum packet size mu st m atc h th e MT U of the link partner . 12. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical Name text box. 13. Click Apply . 14. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 15. Click Apply . 16. Click Save to make your changes perman en t. T o change the VPI/VCI of an A TM interface Note T o move an IP address from one PVC to ano ther , you must first delete the logical interface for the old PVC, then create a new logical interface for the new PVC. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical column. Example: atm-s2p1 3. Find the A TM logical interface you wish to remove in the Logical Interfaces table and click the corresponding Delete button. 4. Click Apply . The logical interface disappears from the list. Any IP addresses configured on this interface are also removed. 5. Select the VPI/VCI range in the VPI/ VCI Range Configuration selection box .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 77 6. Select point-to-point in the T y pe selection box in the Create a new LLC/SNokia Platform RFC1483 interface section. Enter the VPI/ VCI number in the VPI/VCI text box. 7. Click Apply . A new logical interface appears in the Interface column. The ne w interfa ce is turned on by default. 8. Click the logical interface name in the Interface column of th e Logical Interfaces table to go the Interface page. 9. Enter the IP address for the local end of the PVC in the Local Address text box. 10. Enter the IP address of the remote end of the PVC in the Remote Address text box. 11 . Click Apply . 12. (Optional) Enter the desired va lue in the IP MTU text box. 13. Click Apply . 14. (Optional) Change the interface’ s logical name to a more meaningful one by typi ng the preferred name in the Logical Name text box. 15. Click Apply . 16. Click Save to make your changes permanent. T o change the IP Address of an A TM interface Note Do not change the IP address you u se in your browser to access Network V oyager . If you do, you can no longer a ccess the IP s ecurity platfor m (unit) with your browser . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link for which to change the IP address in the Logical column. Example : atm-s2p1c8 3. Delete the current addresses from the Local Address and Remote Address text boxe s, and replace with new address entries. Click Apply . The original MTU value is retained. 4. Click Save to make your changes permanent T o change the IP MTU of an A TM interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Logical column, click the Logical interfa ces link for the item on which to change the IP address. Example: atm-s2p1 3. Enter a number in the IP MTU text box to co nfigure the device’ s maximum length (in bytes) of IP packets transmitted on this interface.
2 78 Nokia Network Voyager for IPSO 4.0 Reference Guide Note The maximum p acket size must match the MTU of the link partner . Packets longer than the length you specif y are fragmented bef ore tr an sm issio n . 4. Click Apply . 5. Click Save to make your changes pe rmanent. AT M E x a m p l e This section describes how you might configure the in terfaces of your IP security platform in an example network, using Network V oyager . The following figu re shows the network configuratio n for this example. In a company’ s main office, Nokia Platform A te rminates a serial line to an Internet service provider , running PPP with a ke epalive value of 1 0. Nokia Platform A also provides Internet access for an FDDI ring and a remote branch office connected through A TM PVC 93. The branch of fice contains Nokia Platform B, wh ich routes traffic between a local fast Ethernet network and A T M PVC 52. It provides access to the main office and the Internet. Nokia Platform A Nokia Platform B atm-s1p1c52 (192.168.3.1) atm-s2p1c93 (192.168.3.2) ser-s1p1c0 (192.168.2.1) eth-s2p1c0 (192.168.4.1/24) 192.168.4.xxx FDDI 192.168.1.xxx (192.168.1.1/24) fddi-s3p1c0 (192.168.2.93) Provider 00037 Server Server Server AT M Switch
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 79 T o configure the A TM interface on Nokia Platform A 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Select atm-s2p1 in the Phys ical column of the table. 3. Enter 93 in the VCI text box in the Create a new LLC/SNokia Platform RFC1483 interface section. The channel number of the interface is no lo nger the VCI number but an automatically allocated number . Therefore, the logical name of the interface in step 6 is something that depends on what other logical A TM interfaces there are. Find the newly created interface from the table before you continue. 4. Click Apply . 5. Click atm-s2p1c93 in the Logical Interface s table. The Interface page is displayed. 6. Enter 192.168.3.2 in the Local Address text box. 7. Enter 192.168.3.1 in the Remote Address text box. 8. Click Apply 9. Enter 9180 in the IP MTU text box. 10. Click Apply . 11 . Click Save. Note The steps for config uring the A TM interface on Nokia Platform B are the same except that you should s et the to 52 when you crea te the logica l interface an d reverse the IP addresse s should be reversed. IP over A TM (IPoA) T o configure an A TM logical IP subnet (LIS) interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical c olumn. Example: atm-s2p1 . The Physical Interface page is displayed. 3. Select SONET or SDH as the framing form at in the Physical Configuration table. The setting should matc h the type of transmission netw ork to which the interface is connected. 4. Select Freerun or Loop T iming as the transmit clock choice in the Physical Config uratio n table. Freerun uses the internal clock. If two A TM inte rfaces are directly connected, at le ast one of them must use the internal clock.
2 80 Nokia Network Voyager for IPSO 4.0 Reference Guide Loop timing derives the tran smit clock from the recovered receive clock. 5. Select the VPI/VCI range in the VP I/VCI Range Configuration list box. 6. Create a logical interface with the Create a new LLC/SNokia Platform RFC1483 interface section by selecting LIS in the T ype list box and entering the set of VPI/VCI numbers that the interface in the VP I/VCI text box will use. The set of VPI/VCIs can be given as a comma-separated list of VPI/VCIs or VPI/VCI ranges such as 1/42, 1/48, 1/50 to 60. 7. Click Apply . A new logical interface appears in the Interface column. The new interfa ce is on by default. Y ou can create multiple logical interf aces by repeating steps 6 through 7. 8. Click the logical interface name in the Interfa ce column of the Logical Interfaces table to reach the Logical Interface pa ge. 9. Enter the IP address of the interface in the IP Address text box. 10. Enter the IP subnet mask length in the Mask Length text box. 11 . Enter a number in the IP MTU text box to co nfigure the device’ s maximum length (in bytes) of IP packets transmitted in this interface. The default value and ra ng e depend on the hardware co nfiguration. The standard value is 9180. Click Apply . Note All hosts in the same LIS must use the sa me IP MTU in their interface to the LIS. 12. (Optional) Change the interfaces logical name to a more meaningful one by typing the preferred name in the Logical na me text box. Click Apply . 13. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 14. Click Apply . 15. Click Save to make your changes perman en t. T o change the VPI/VCIs of an A TM LIS Interface Note Do not change the VCI address of the co nnection you are using. If you do, you can no longer access the IP security platform with your browse r . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: atm-s2p1.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 81 The Physical Interface page appears. 3. Select the VPI/VCI range in the VPI/VCI Range Configuration list box. 4. Find the A T M logical interface to reconfigure in the Logical Interfaces table and e nter a new set of VPI/VCIs in the VPI/VCI field. 5. Click Apply . 6. Click Save to make your changes permanent. T o change the IP Address of an A TM LIS interface Note Do not change the IP address you u se in your browser to access Network V oyager . If you do, you can no longer access the IP security platform with your bro w ser . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link for which to change the IP address in the Logical column. Example: atm-s2p1c8 The Logical In terface page appea rs. 3. Enter the IP address fo r the interface in the IP Address text box. 4. Enter the IP subnet mask length in the Mask Length text box. 5. Click Apply . 6. Click Save to make your changes permanent. T o change the IP MTU of an A TM interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Logical column, click the Logical interface link for the item on which to change the IP MTU. Example: atm-s2p1c8. 3. Enter a number in the IP MTU text box to co nfigure the devices maximum length (in bytes) of IP packets transmitted on this interface. Note All hosts in th e same LIS must use the sa me IP MTU in their interface to the LIS. Packets longer than the length you spec ify are fragmented before transmission. 4. Click Apply . 5. Click Save to make your changes permanent.
2 82 Nokia Network Voyager for IPSO 4.0 Reference Guide IPoA Example This section describes how you might configure the in terfaces of your IP security platform in an example network, using Network V oyager . The following figu re shows the network configuratio n for this example. A company has five Etherne t networks in thre e separate locations. The networks are connected to each other with three routers that belong t o the same logical IP subnet over A TM. This example configures the A TM interface on Nokia Pl atform A. The interface is connected to Nokia Platform B through A TM PVC 42 and to No kia Platform C through A TM PNC 53. Nokia Platform B and Nokia Platform C are connected to each ot her through an A TM PVC; their A TM interfaces have already configured. T o configure the A TM interface on Nokia Platform A 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physi cal column. Example: atm-s2p1. The Physical Interface page appears. 3. Create a logical interfa ce in the Create a new LLC/SNokia Platfo rm RFC1483 interface section by selecting LIS in the T ype list box. 4. Enter 42,53 in the VCI(s) text box. 5. Click Apply . 6. Click the newly created interface (atm-s2p1c0) in the Logical Interfaces table to reach the Logical Interface page. 7. Enter 10.0.0.1 in the IP Address text box. 8. Enter 24 in the Mask Length text box. AT M Switch 00125 eth-s1p1c0 eth-s1p1c0 eth-s2p2c0 eth-s1p1c0 eth-s2p2c0 atm-s2p1c0 (10.0.0.1/24) PVC 42 to Nokia Platform B PVC 53 to Nokia Platform C atm-s3p1c0 (10.0.0.3/24) atm-s3p1c0 (10.0.0.2/24) Nokia Platform A Nokia Platform C Nokia Platform B
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 83 9. Click Apply . 10. (Optional) Change the interfaces logical name to a more meaningful name by ty ping the preferred name in the Logical na me text box. Click Apply . 11 . (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 12. Click Apply . 13. Click Save. Serial (V .35 and X.21) Interfaces T o configure a serial interface for Cisco HDLC 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical column. Example: ser-s2p1 3. (Optional) Click On or Of f in the Physical conf iguration table Internal Clock field to set the internal clock on the serial device. Set the internal clock to On when you are connecting to a device or system that does not provide a clock source. Otherwise, set the internal clock to Off. 4. Click Apply . 5. If you turned the internal clock on, enter a value in the Internal clock speed text box. If the device can generate only certain line rates, and the configured line rate is not one of these values, the device selects the next highest available line ra te. 6. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 7. Click Cisco HDLC in the Encapsulation field. 8. Click Apply . A logical interface appears in the Logical Interfaces table. 9. Enter a number in the Keepaliv e text box to configure the Ci sco HDLC keepalive interval. Click Apply . This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates.
2 84 Nokia Network Voyager for IPSO 4.0 Reference Guide 10. Click the logical interface name in the Inte rface column of the Logical interfaces table. The Interface page appears. 11 . Enter the IP address for the local end of the link in the Local address text box. 12. Enter the IP address of the remote end of the link in the Remote address te xt box. Click Apply . 13. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical na me text box. Click Apply . 14. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 15. Click Save to make your changes perman en t. T o configure a Serial Interface for PPP 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. (Optional) Click On or Of f in th e P hysical conf iguration table Internal Clock field to set the internal clock on the serial device. Click Apply . Set the internal clock to On when you are connecting to a device or system that does not provide a clock source. Otherwise, set the internal clock to Off. 4. If you turned the internal clock on, enter a value in the Internal clock speed text box. If the device can generate only certain line rates, and the configured line rate is not one of these values, the device selec ts th e next highest available line rate. 5. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click the PPP radio button in the Encapsulation field. 7. Click Apply . A logical interface appears in the Logical Interfaces table. 8. Enter a numb er in the Keepa live text box to configure the PPP keepalive interval. This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep aliv e value configured on the system at the other end of a point-to-point link, or the link sta te fluctuates.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 85 9. Click Apply . 10. Enter a number in the Keepa live maximum failures text box. This value sets the number of times a remote system can fail to send a keepalive protocol message within a keepalive interval befo re the systems c onside r s the link down. 11 . Click Apply . 12. Click the Advanced PPP Options link. The PPP Advanced Options page appears. 13. Click Y es or No in the Negotiate Magic Number field. Clicking Y es enables the interface to send a request to negotiate a magic number with a peer . 14. Click Y es or No in the Negotia te Maximum Receive Unit field. Clicking Y e s enables the interface to send a request to negotiate an MRU with a peer . 15. Click Apply . 16. Click Up to return to the Physical Interface page. 17. Click the logical interface name in the Interface column of th e Logical Interfa ces table to go to the Interface page. 18. Ente r the IP address for the local end of the link in the Local address text box. 19. Enter the IP address of the remote end of th e link in the Remote ad d ress text box. Click Apply . 20. (Optional) Change the interfaces logical name to a more meaningful name by ty ping the preferred name in the Logical na me text box. Click Apply . 21. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 22. T o make your change s pe rmanent, click Save. T o configure a serial interface for frame relay 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physi cal column. Example: ser-s2p1. 3. (Optional) Click On or Of f in the Physical conf iguration table Internal Clock field to set the internal clock on the serial device. Set the internal clock to On when you are connecting to a device or system that does not provide a clock source. Otherwise, set the internal clock to Off. 4. Click Apply . 5. If you turned the internal clock on, enter a value in the Internal clock speed text box. If the device can generate only certain line rates, and the configured line rate is not one of these values, the device selects the next highest available line ra te.
2 86 Nokia Network Voyager for IPSO 4.0 Reference Guide 6. Click Full Duplex or L oopback radio in the Channel Mod e field. Full duplex is the normal mode of operation. 7. Click the Frame relay radio button in the Encapsulation field. 8. Click Apply . 9. Enter a number in the Keepaliv e text box to configure the fra me relay keepalive interval. This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep aliv e value configured on the system at the other end of a point-to-point link, or the link sta te fluctuates. 10. Click Apply . 11 . Click DTE or DCE in the Interface T ype field. DTE is the usual operating mode when the device is connecte d to a Frame Rela y switc h. 12. Click On or Off in the Active S tatus Monitor field. This actions sets the monitoring of the conn ection-active status in the LMI status message. 13. (Optional) Click the Advanced Fram e Relay Options lin k to go to the Frame R elay Advanced Options page. The Frame Relay Ad vanced Options page allows you to co nfigure frame relay protocol and LMI parameters for this device. Note The values you enter depend on the settin gs of the frame relay switch to which you are connected or to the subscription provided by your service provider . 14. From the Frame Relay Advanced Options page, click Up to return to the Physical Interface page. 15. Enter the DLCI number in the Creat e a new interface DLCI text box. 16. Click Apply . A new logical interface appears in the Interface column. The DLCI number appe ars as the channel number in the logical interface na me. The new int erface is on by default. 17. (Optional) Enter another DLCI number in th e DLCI text box to config ure another frame relay PVC. 18. Click Apply . Each time you click Appl y after you enter a DLCI, a new logical interface appears in the Interface column. The DLCI entry field remains blank to allow you to add more frame relay logical interfaces.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 87 19. Click the logical interface name in the Interface column of the Logical interfaces ta ble to go the Interface page. 20. Ente r the IP address for the local end of the PVC in the Loca l address te xt box. 21. Enter the IP address of the remote end of the PVC in the Remote address text box. Click Apply . 22. (Optional) Change the interfaces logical name to a more meaningful name by ty ping the preferred name in the Logical na me text box. 23. Click Apply . 24. Click Save to make your changes permanent. Serial Interface Example This section describes how you might configure the in terfaces of your IP security platform in an example network, using Ne twork V oyager . The following figu re shows the network configuratio n for this example. In a company’ s main office, Nokia Platform A te rminates a serial line to an Internet service provider , running PPP with a ke epalive value of 1 0. Nokia Platform A also provides Internet access for a FDDI ring and a remote branch office connected through A TM PVC 93. Nokia Platform A Nokia Platform B atm-s1p1c52 (192.168.3.1) atm-s2p1c93 (192.168.3.2) ser-s1p1c0 (192.168.2.1) eth-s2p1c0 (192.168.4.1/24) 192.168.4.xxx FDDI 192.168.1.xxx (192.168.1.1/24) fddi-s3p1c0 (192.168.2.93) Provider 00037 Server Server Server AT M Switch
2 88 Nokia Network Voyager for IPSO 4.0 Reference Guide The branch of fic e co ntains Nok ia Platfo rm B, whic h routes traffic between a local Fast Ethernet network and A T M PVC 52. It provides access to the main office and the Internet. T o configure the serial interface on Nokia Platform A 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Select ser-s1p1 in the Physical column of the table. 3. Click PPP in the Encapsulation field. 4. Click Apply . 5. Enter 10 in the Keepalive text box. 6. Click Apply . 7. Click ser -s1p1c0 in the l ogical interfaces table to go to the Interface page. 8. Enter 192.168.2.1 in the Local address text box. 9. Enter 192.168.2.93 in the Remote address text box. 10. Click Apply . 11 . (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical na me text box. 12. Click Apply . 13. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 14. Click Apply . 15. Click the Up button to go to the Interfaces page. 16. Click the On radio button for ser-s1p1c0. 17. Click Apply . 18. Click Save. T1(with Built-In CSU/DSU) Interfaces T o configure a T1 Interface for Cisco HDLC 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the interface link to configure in the Physical column. Example: ser-s2p1. 3. (Optional) Click On or Off in the Internal Cl ock field to set the internal clock on the T1 device. If you are connecting to a device or system th at does not provide a clock source , set Internal Clock to On; otherwise, set it to Of f. Internal clocking for T1 is fixed at 1.544 M bps. T o configure slower speeds, you must c onfigure fractional T1 on the Advanced T1 CSU/DSU Options page.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 89 4. Click Apply . 5. Click the Full Duplex or Loopback ra dio button in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click AMI or B8ZS in th e T1 Encoding field to sel ect the T1 encoding. This setting must match the line encoding of th e CSU/DSU at the other end of the point-to- point link. 7. Click Apply . 8. Click Superframe (D4) or Extend ed SF in the T1 Framing fiel d to select the T1 Framing format. Use T1 framing to divide the data stream into 64 Kbps channels and to synchronize with the remote CSU/DSU. This setting must match the frame format that the CSU/DSU uses at the other end of the point-to-point link. 9. Click Apply . 10. Click 64bps or 56bps in the T1 Channel Speed field to select the DS 0 channel spee d for the T1 line. Some older trunk lines use the least-significant bit of each DS0 channel in a T1 frame for switching-equipment signaling. T1 frames d esigned for data transfer can be set to not use the least-significant bit of each DS0 channel. This se tting allows data to be sent over these trunk lines without corruption but at a reduced throughput. This mode is called the 56 Kbps mode because each DS0 channel now h as an effective throughpu t of 56 Kbps instead of 64 Kb ps. All T1 functions still work in the 56 Kbps mo de, including all framing modes and fractional T1 configurations. 11 . If you selected Extended SF as the T1 Framing format, click ANSI or None in the FDL T ype field to select the FDL type. 12. Click Cisco HDLC in the Encapsulation field. 13. Click Apply . A logical interface appears in the Logical interfaces table. 14. Enter a number in the Keepaliv e text box to configure the Ci sco HDLC keepalive interva l . Click Apply . This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 15. (Optional) Click the Advanced T1 CSU/DSU Options link to select advanced T1 options.
2 90 Nokia Network Voyager for IPSO 4.0 Reference Guide The T1 CSU/DSU Advanced Options page allows you to configure fractional T1 channels, line build-out values and other advanced settings for the T1 device. Th e values you enter on this page are dependent on the subs cription provided by your service pro vider . 16. From the Advanced T1 CSU/DSU Options page, click Up to return to the physical interface page. 17. Click the logical interface name in the Interface column of the Logical interfaces table to go to the Interface page. 18. Enter the IP address for the local end of the link in the Local address text box. 19. Enter the IP address of the remote end of the link in the Remote address te xt box. Click Apply . 20. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical na me text box. Click Apply . 21. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 22. Click Apply . 23. Click Save to make your changes perman en t. T o configure a T1 Interface for PPP 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the interface link to configure in the Physical column. Example: ser-s2p1. 3. (Optional) Click On or Off in the Internal Cl ock field to set the internal clock on the T1 device. When you connect to a device or system that does not provide a clock source, set Internal Clock to On; otherwise, set it to Of f. Internal clocking for T1 is fixed at 1.544 M bps. T o configure slower speeds, you must c onfigure fractional T1 on the Advanced T1 CSU/DSU Options page. 4. Click Apply . 5. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click AMI or B8ZS in the T1 Encoding field to select th e T1 encoding. This setting must match t he line encoding of the CS U/DSU at the other end of the point-to- point link. 7. Click Apply . 8. Click Superframe (D4) or Extend ed SF in the T1 Framing fiel d to select the T1 Framing format.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 91 Use T1 framing to divide the data stream into 64 Kbps channels and to synchronize with the remote CSU/DSU. This setting must match the frame format used by the CSU/DSU at the other end of the point-to-point link. 9. Click Apply . 10. Click 64bps or 56bps in the T1 Channel Speed field to select the DS 0 channel spee d for the T1 line. Some older trunk lines use the least-significant bit of each DS0 channel in a T1 frame for switching-equipment signaling. T1 frames d esigned for data transfer can be set to not use the least-significant bit of each DS0 channel. This se tting allows data to be sent over these trunk lines without corruption but at a reduced throughput. This mode is called the 56 Kbps mode because each DS0 channel now h as an effective throughpu t of 56 Kbps instead of 64 Kb ps. All T1 functions still work in the 56 Kbps mo de, including all framing modes and fractional T1 configurations. 11 . If you selected Extended SF as the T1 Framing format, click ANSI or None in the FDL T ype field to select the FDL type. 12. Click the PPP in the Encapsulation field. 13. Click Apply . A logical interface appears in the Logical Interfaces table. 14. Enter a number in the Keepa live text box to configure the PPP keepalive interval. This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 15. Click Apply . 16. Enter a number in the Keepa live maximum failures text box. This value sets the number of times a remote system may fail to send a keepalive protocol message within a keepalive interval befo re the systems c onside r s the link down. 17. Click Apply . 18. (Optional) Click the Advanced T1 CSU/DSU Options link to select advanced T1 options. The T1 CSU/DSU Advanced Options page allows you to configure fractional T1 chan nels, line build-out values, and other advanced settings for a T1 device. Th e values you enter on this page depend on the sub scription provided by your service provid er . 19. From the Advanced T1 CSU/DSU Options page, click Up to return to the physical interface page. 20. Click the Advanced PPP Options link. The PPP Advanced Options page appears.
2 92 Nokia Network Voyager for IPSO 4.0 Reference Guide 21. Click Y es or No in the Negotiate Magic Number field. Clicking Y es enables the interface to send a requ est to negotiate a magic numbe r with a peer . 22. Click Y es or No in the Negotiate Maximum Receive Unit field. Clicking Y e s enables the inte rface to send a request to negotiate an MRU with a peer . 23. Click Apply . 24. Click Up to return to the Physical Interface page. 25. Click the logical interface name in the Interface column of the Logical Interfa ces table to go to the Interface page. 26. Enter the IP address for the local end of the link in the Local address text box. 27. Enter the IP address of the remote end of the link in the Remote address box. Click Apply . 28. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical na me text box. 29. Click Apply . 30. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 31. Click Apply . 32. Click Save to make your changes perman en t. T o configure a T1 interface for frame relay 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. (Optional) Click On or Off in the Internal Cl ock field to set the internal clock on the T1 device. If you’re connecting to a device or system that does not provide a clock source, set Internal Clock to On; otherwise, set it to Of f. Internal clocking for T1 is fixed at 1.544 M bps. T o configure slower speeds, you must c onfigure fractional T1 on the Advanced T1 CSU/DSU Options page. 4. Click Apply . 5. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click the AMI or B8ZS radio button in the T1 Encoding field to select the T1 encoding. Click Apply . This setting must match t he line encoding of the CS U/DSU at the other end of the point-to- point link. 7. Click Superframe (D4) or Extend ed SF radio button in the T1 Fr aming field to select the T1 Framing format.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 93 Use T1 framing to divide the data stream into 64Kb ps channels a nd to synchronize with the remote CSU/DSU. This setting must match the frame format used by the CSU/DSU at the other end of the point-to-point link. 8. Click Apply . 9. Click 64bps or 56bps in the T1 Channel Speed field to select the DS 0 channel speed for the T1 line. Some older trunk lines use the least-significant bit of each DS0 channel in a T1 frame for switching-equipment signaling. T1 frames designed for data transfer can be set to not use the least-significant bit of each DS0 channel. This se tting allows data to be sent over these trunk lines without corruption but at a reduced throug hput. This mode is called the 56 Kbps mode because each DS0 channel now h as an effective throughpu t of 56 Kbps instead of 64 Kb ps. All T1 functions still work in the 56 Kbps mo de, including all framing modes and fractional T1 configurations. 10. If you se lected Extended SF as the T1 Framing format, click ANSI or None in the FDL T ype field to select the FDL type. 11 . Click Frame relay in th e Encapsulation field. 12. Click Apply . 13. Enter a number in the Keepaliv e text box to configure the fra me relay keepalive interval. This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 14. Click Apply . 15. Click DTE or DCE in the Interface T ype field. DTE is the usual operating mode when the device is connected to a Frame Relay switch. 16. Click On or Off in the Ac tive S tatus Monitor field. Sets the monitoring of the connection-a ctive status in the LMI status message. 17. Click Apply . 18. (Op tional) Click Adva nc ed T1 CSU/DSU Options link to select ad vanced T1 options. The T1 CSU/DSU Advanced Options page allows you to configure fractional T1 channels, line build-out values and other advanced settings for the T1 device. Th e values you enter on this page depend the subs cription provided by your service pro vider . 19. From the Advanced T1 CSU/DSU Options page, click Up to return to the physical interface page. 20. (Optional) Click the Advanced Fram e Relay Options lin k to go to the Frame Relay Advanced Options page.
2 94 Nokia Network Voyager for IPSO 4.0 Reference Guide The Frame Relay Ad vanced Options page allows you to co nfigure frame relay protocol and LMI parameters for this device. Note The values you enter depend on the settin gs of the frame relay switch to which you are connected or to the subscription provided by your service provider . 21. From the Frame Relay Advanced Options page, click Up to return to the Physical Interface page. 22. Enter the DLCI number in the Creat e a new interface DLCI text box. 23. Click Apply . A new logical interface appears in the Interface column. The DLCI number appe ars as the channel number in the logical interface na me. The new int erface is on by default. 24. (Optional) Enter another DLCI number in th e DLCI text box to config ure another frame relay PVC. 25. Click Apply . Each time you click Appl y after entering a DLCI, a new logical interface appears in the Interface column. The DLCI entry field remains blank to allow you to add more frame relay logical interfaces. 26. Click the logical interface name in the Interface column of the Logical Interfa ces table to go to the Interface page. 27. Enter the IP address for the local end of the PVC in the Local address text box. 28. Enter the IP address of the remote end of the PVC in the Remote address text box. 29. Click Apply . 30. (Optional) Change the interface’ s logical name to a more meaningful one by typ ing the preferred name in the Logical na me text box. 31. Click Apply . 32. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. 33. Click Apply . 34. Click Save to make your changes perman en t. T1 Interface Example This section describes how y ou might use Network V oyager to configure the interfaces of yo ur IP security platform in an example network.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 95 The following figu re shows the network configuratio n for this example. In a company’ s main office, Nokia Platform A te rminates a T1 line to an Internet service provider , running PPP with a keepal ive value of 10. The T1 line uses B8ZS line encoding, Extended Super Frame, T1 frami ng, and 64 Kbps channels. Nokia Platform A also provides In ternet acces s for an FD DI ring and a remote branch office connected through A TM PVC 93. The branch of fice contains Nokia Platform B, wh ich routes traffic between a local fast Ethernet network and A T M PVC 52. It provides access to the main office and the Internet. T o configure the serial interface on Nokia Platform A 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the link. 3. Select ser-s1p1 in the Physical column of the table. 4. Click B8ZS in the T1 Encoding field. 5. Click Extended SF in the T1 Framing field. 6. Click 64 Kbps in th e T1 Channel Speed field. 7. Click PPP in the Encapsulation field. 8. Click Apply . 9. Enter 10 in the Keepalive text box. Nokia Platform A Nokia Platform B atm-s1p1c52 (192.168.3.1) atm-s2p1c93 (192.168.3.2) ser-s1p1c0 (192.168.2.1) eth-s2p1c0 (192.168.4.1/24) 192.168.4.xxx FDDI 192.168.1.xxx (192.168.1.1/24) fddi-s3p1c0 (192.168.2.93) Provider 00037 Server Server Server AT M Switch
2 96 Nokia Network Voyager for IPSO 4.0 Reference Guide 10. Click Apply . 11 . Click ser-s1p1c0 in the l ogical interfaces table to go to the Interface page. 12. Enter 192.168.2.1 in the Local address text box. 13. Enter 192.168.2.93 in the Remote address text box. 14. Click Apply . 15. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logical na me text box. Click Apply . 16. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 17. Click Up to go to the Interfaces page. 18. Click On for ser-s1p1c0. 19. Click Apply . 20. Click Save. E1 (with Built-In CSU/DSU) Interfaces T o configure an E1 interface for Cisco HDLC 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. (Optional) Click On or Off in the Internal Cl ock field to set the internal clock on the E1 device. Click Apply . If you are connecting to a device or system th at does not provide a clock source , set Internal Clock to On; otherwise, set it to Off. Internal clocking for E1 is fixed at 2.048 Mbp s/sec. T o configure slower speeds, you must c onfigure fractional E1 on the Advanced E1 CSU/DSU Options page. 4. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 5. Click AMI or HDB3 in the E1 Encodi ng field to select the E1 encoding. Click Apply . This setting must match t he line encoding of the CS U/DSU at the other end of the point-to- point link. 6. Click E1 (channel 0 framing) or No Fra ming in the E1 Framing field to select the E1 framing format.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 97 Use E1 framing to select whether timeslot-0 is used for exchanging signaling data. 7. Click On or Of f for th e E1 CRC-4 Framing field. Note This option appears only if you set the E1 Framing field to E1 (channel 0 framing). This option chooses the frami ng format for timeslot-0. On means that CRC-multiframe format is used; the informatio n is protected by CRC-4. Of f m eans that double-frame format is used. This setting must ma tch the setting of the CSU/DSU at the other end of the link. 8. Click On or Of f for the E1 T imeslot-16 Framing. Click Apply . Note This option appears only if you set the E1 Framing field to E1 (channel 0 framing). This option controls whether tim eslot-16 is used in channel associated signaling (CAS). Setting this value to On means that timeslot-16 can not be used as a data channel. See fractional settings on the Advanc ed E1 CSU/DSU Options page. 9. Click Cisco HDLC in the Encapsulation field. Click Apply . A logical interface appears in the Logical Interfaces table. 10. Enter a number in the Keepaliv e text box to configure the Ci sco HDLC keepalive interva l . Click Apply . This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. The range is 0- 255. The default is 10. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 11 . (Optional) Click the Advanced E1 CSU/DSU Options link to select advanced E1 options. The E1 CSU/DSU Advanced Options page allows you to config ure fractional E1 channels and other advanced settings for the E1 device. The values you enter on this page depend on the subscription provided by your servi ce provider . 12. From the Advanced E1 CSU/DSU Options page, click Up to return to the physical interface page. 13. Click the logical interface name in the Interface column of th e Logical Interfa ces table to go to the Interface page.
2 98 Nokia Network Voyager for IPSO 4.0 Reference Guide 14. Enter the IP address for the local end of the link in the Local Address text box. 15. Enter the IP address of the remote end of the link in the Remote Address text box. Click Apply . 16. (Optional) Change the interface’ s logical name to a more meaningful one by typ ing the preferred name in the Logical na me text box. Click Apply . 17. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 18. Click Save to make your changes perman en t. Note T ry to ping the remote system from the command prompt. If the remote system does not work, conta ct your service provi der to confirm the configuration. T o configure an E1 interface for PPP 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. (Optional) Click On or Off in the Internal Cl ock field to set the internal clock on the E1 device. Click Apply . If you’re connecting to a device or system that does not provide a clock source, set Internal Clock to On; otherwise, set it to Of f. Internal clocking for E1 is fixed at 2.048 Mbits/sec. T o configure slower speeds, you must c onfigure fractional E1 on the Advanced E1 CSU/DSU Options page. 4. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 5. Click AMI or HDB3 in the E1 Encodi ng field to select the E1 encoding. Click Apply . This setting must match t he line encoding of the CS U/DSU at the other end of the point-to- point link. 6. Click E1 (channel 0 framing) or No Fra ming in the E1 Framing field to select the E1 Framing format. Use E1 framing to select whether timeslot-0 is used for exchan ging signaling data. 7. Click On or Of f for the E1 CRC-4 Framing field.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 99 Note This option appears only if you have set th e E1 Framing field to E1 (channel 0 framing). This button chooses the frami ng format for timeslot-0. On means that CRC-multiframe format is used; the informatio n is protected by CRC-4. Of f m eans that double-frame format is used. This setting must ma tch the setting of the CSU/DSU at the other end of the link. 8. Click On or Of f for the E1 T imeslot-16 Framing. Click Apply . Note This option appears on ly if you set the E1 Framing field to E1 (channel 0 framing). This value controls whether ti meslot-16 is used in channel associated signaling (CAS). Setting this value to On means that timeslot-16 cannot be used as a data channel. See fractional settings on the Advanced E1 CSU/DSU Options page. 9. Click PPP in the Encapsulation field. Click Apply . A logical interface appears in the Logical Interfaces table. 10. Enter a number in the Keepa live text box to configure the PPP keepalive interval. Click Apply . This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. The range is 0- 255. The default is 5. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 11 . Enter a number i n the Keepa live Maximum Failures text box. This value sets the number of times a remote system may fail to send a keepalive protocol message within a keepalive interv al before the systems consider the link down. The range is a positive integer . The default is 30. 12. Click Apply . 13. (Optional) Click the Advanced E1 CSU/DSU Options link to select advanced E1 options. The E1 CSU/DSU Advanced Options page allows you to config ure fractional E1 channels and other advanced settings for an E1 device. The values you en ter on this page depend on the subscription provided by your servi ce provider .
2 100 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 14. From the Advanced E1 CSU/DSU Options page, click Up to return to the physical interface page. 15. Click the Advanced PPP Options link. The PPP Advanced Options page appears. 16. Click Y es or No in the Negotiate Magic Number field. Clicking Y es enables the interface to send a requ est to negotiate a magic numbe r with a peer . 17. Click Y es or No in the Negotiate Maximum Receive Unit field. Clicking Y e s enables the inte rface to send a request to negotiate an MRU with a peer . 18. Click Apply . 19. Click Up to return to the Physical Interface page. 20. Click the logical interface name in the Interface column of the Logical Interfa ces table to go to the Interface page. 21. Enter the IP address for the local end of the link in the Local Address text box. 22. Enter the IP address of the remote end of the link in the Remote Address text box. Click Apply . 23. (Optional) Change the interface’ s logical name to a more meaningful one by typ ing the preferred name in the Logical na me text box. Click Apply . 24. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 25. Click Save to make your changes perman en t. Note T ry to ping the remote system from the command prompt. If the remote system does not work, conta ct your service provi der to confirm the configuration. T o configure an E1 interface for frame relay 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the interface link to configure in the Physical column. Example: ser-s2p1. 3. (Optional) Click On or Off in the Internal Cl ock field to set the internal clock on the E1 device. Click Apply . If you’re connecting to a device or system that does not provide a clock source, set Internal Clock to On; otherwise, set it to Of f. Internal clocking for E1 is fixed at 2.048 Mbits/sec. T o configure slower speeds, you must c onfigure fractional E1 on the Advanced E1 CSU/DSU Options page.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 101 4. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 5. Click AMI or HDB3 in the E1 Encoding field to select the E1 encoding. Click Apply . This setting must match the line encoding of th e CSU/DSU at the other end of the point-to- point link. 6. Click E1 (channel 0 framing) or No Fra ming in the E1 Framing field to select the E1 Framing format. Use E1 framing to select whether timeslot-0 is used for exchanging signaling data. 7. Click On or Of f for th e E1 CRC-4 Framing field. Note This option appears only if you have set th e E1 Framing field to E1 (channel 0 framing). This button chooses the frami ng format for timeslot-0. On means that CRC-multiframe format is used; the information is protected by CRC-4. Of f means that doubleframe format is used. This setting must match the setting of the CSU/DSU at the other end of the link. 8. Click On or Of f for the E1 timeslot-16 Framing. Click Apply . Note This option appears only if you set the E1 Framing field to E1 (channel 0 framing). This value controls whether tim eslot-16 is used in channe l associated signaling (CAS). Setting this value to On means that timeslot-16 can not be used as a data channel. See fractional settings on the Advanced E1 CSU/DSU Options page. 9. Click Frame Relay in the Encapsulation field. Click Apply . 10. Enter a number in the Keepaliv e text box to configure the fra me relay keepalive interval. Click Apply . This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test fo r an active remote system. The range is 0 to 255. The default is 10. Note This value must be identical to the keepalive value configured on the system at the other end of a point-to -point link, or the link state fluctuat es. 11 . Click DTE or DCE in the Interface T ype field.
2 102 Nokia Network Voyager for IPSO 4.0 Refe rence Guide DTE is the usual operating mode when the device is connecte d to a frame re lay switch. 12. Click On or Off in the Active S tatus Monitor field. Click Apply . This value sets the monitoring of the connection-active status in the LMI status message. 13. (Optional) Click the Advanced E1 CSU/DSU Options link to select advanced E1 options. The E1 CSU/DSU Advanced Options page allows you to config ure fractional E1 channels and other advanced settings for the E1 device. Th e values you enter on this page depend on the subscription provided by your service prov ider . 14. From the Advanced E1 CSU/DSU Options page, click Up to return to the physical interface page. 15. (Optional) Click the Advanced Fram e Relay Options lin k to go to the Frame R elay Advanced Options page. The Frame Relay Ad vanced Options page allows you to co nfigure frame relay protocol and LMI parameters for this device. Note The values you enter depend on the settin gs of the frame relay switch to which you are connected or to the s ubscription tha t your servic e provider provides. 16. From the Frame Relay Advanced Options page, click Up to return to the Physical Interface page. 17. Enter the DLCI number in the Creat e a New Inte rface DLCI text box. Click Apply . A new logical interface appears in the Interface column. The DLCI number appe ars as the channel number in the logical interface name. The new interface is turned on by default. 18. (Optional) Enter another DLCI number in th e DLCI text box to config ure another frame relay PVC. Click Apply . Each time you click Appl y after you enter a DLCI, a new logical interface appears in the Interface column. The DLCI entry field remains blank to allow you to add more frame relay logical interfaces. 19. Click the logical interface name in the Interface column of the Logical Interfa ces table to go to the Interface page. 20. Enter the IP address for the local end of the PVC in the Local Address text box. 21. Enter the IP address of the remote end of the PVC in the Remote Address tex t box. Click Apply . 22. (Optional) Change the interface’ s logical name to a more meaningful one by typ ing the preferred name in the Logical na me text box.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 103 Click Apply . 23. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 24. Click Save to make your changes permanent. Note T ry to ping the remote system from the comm and prompt. If the remote system does not work, contact your service pr ovi der to confirm the configuration. HSSI Interfaces T o configure an HSSI interface for Cisco HDLC 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the interface link to configure in the Physical column. Example: ser-s2p1. 3. (Optional) Click On or Of f in the Physical conf iguration table Internal Clock field to set the internal clock on the serial device. Click Apply . Set the internal clock to On when you are connecting to a device or system that does not provide a clock source. Otherwise, set the internal clock to Off. 4. If you turned the internal clock on, enter a value in the Internal clock speed text box. If the device can generate only certain line rates, and the configured line rate is not one of these values, the device selects the next highest available line ra te. 5. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click Cisco HDLC in the Encapsulation field. Click Apply . A logical interface appears in the Logical Interfaces table. 7. Enter a number in the Keepaliv e text box to configure the Ci sco HDLC keepalive interval. Click Apply . This value sets the interval, in seconds, betw een keepalive protocol message transmissions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates.
2 104 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 8. Click the logical interface name in the Interface column of the Logical interfaces table to go to the Interface page. 9. Enter the IP address for the local end of the link in the Local address text box. 10. Enter the IP address of the remote end of the link in the Remote address te xt box. Click Apply . 11 . (Optional) Change the interface’ s logical name to a more meanin gfu l one by typing the preferred name in the Logical na me text box. Click Apply . 12. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 13. Click Save to make your changes perman en t. T o configure an HSSI interface for PPP 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. (Optional) Click On or Of f in th e P hysical conf iguration table Internal Clock field to set the internal clock on the HSSI device. Click Apply . Set the internal clock to On when you are connecting to a device or system that does not provide a clock source. Otherwise, set the internal clock to Off. 4. If you turned the internal clock on, enter a value in the Internal clock speed text box. If the device can generate only certain line rates, and the configured line rate is not one of these values, the device selec ts th e next highest available line rate. 5. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click the PPP in the Encapsulation field. Click Apply . A logical interface appears in the Logical interfaces table. 7. Enter a numb er in the Keepa live text box to configure the PPP keepalive interval. Click Apply . This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 105 Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 8. Enter a number in the Keepaliv e maximum failures text box to configure the PPP keepalive maximum failures. This value sets the number of times a remote system may fail to send a keepalive protocol message within a keepalive interval befo re the systems c onside r s the link down. Click Apply . 9. Click the Advanced PPP Options link. The PPP Advanced Options page appears. 10. Click Y es or No in the Negotiate Magic Number field. Clicking Y es enables the interface to send a request to negotiate a magic number with a peer . 11 . Click Y es or No in the Negotia te Maximum Receive Unit field. Clicking Y e s enables the interface to send a request to negotiate an MRU with a peer . Click Apply . 12. Click Up to return to the Physical Interface page. 13. Click the logical interface name in the Interface column of th e Logical Interfa ces table to go to the Interface page. 14. Ente r the IP address for the local end of the link in the Local address text box. 15. Enter the IP address of the remote end of the link in the Remote address text box. Click Apply . 16. (Optional) Change the interface’ s logical name to a more meaningful one by typi ng the preferred name in the Logical na me text box. Click Apply . 17. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 18. T o make your change s pe rmanent, click Save. T o configure an HSSI interface for frame relay 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical c olumn. Example: ser-s2p1. 3. (Optional) Click On or Of f in the Physical conf iguration table Internal Clock field to set the internal clock on the HSSI device. Click Apply .
2 106 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Set the internal clock to On when you are connecting to a device or system that does not provide a clock source. Otherwise, set the internal clock to Off. 4. If you turned the internal clock on, enter a value in the Internal clock speed text box. If the device can generate only certain line rates, and the configured line rate is not one of these values, the device selec ts th e next highest available line rate. 5. Click Full Duplex or Loopback in the Channel Mode field. Full duplex is the normal mode of operation. 6. Click Frame relay in the Encapsulation field. Click Apply . 7. Enter a number in the Keepaliv e text box to configure the fra me relay keepalive interval. Click Apply . This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep aliv e value configured on the system at the other end of a point-to-point link, or the link sta te fluctuates. 8. Click DTE or DCE in the Interface T ype field. DTE is the usual operating mode when the device is connecte d to a Frame Rela y switc h. 9. Click On or Of f in the Active Status Monitor field. Sets the monitoring of the connection-a ctive status in the LMI status message. 10. (Optional) Click the Advanced Fram e Relay Options lin k to go to the Frame Relay Advanced Options page. The Frame Relay Ad vanced Options page allows you to co nfigure frame relay protocol and LMI parameters for this device. Note The values you enter depend on the settin gs of the frame relay switch to which you are connected or to the s ubscription tha t your servic e provider provides. 11 . From the Frame Relay Advanced Options page, click Up to return to the Physical Interface page. 12. Enter the DLCI number in the Creat e a new interface DLCI text box. Click Apply . A new logical interface appears in the Interface column. The DLCI number appe ars as the channel number in the logical interface na me. The new int erface is on by default. 13. (Optional) Enter another DLCI number in th e DLCI text box to config ure another frame relay PVC.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 107 Click Apply . Each time you click Appl y after entering a DLCI, a new logical interface appears in the Interface column. The DLCI entry field remains blank to allow you to add more frame relay logical interfaces. 14. Click the logical interface name in the Interface column of th e Logical Interfa ces table to go to the Interface page. 15. Ente r the IP address for the local end of the PVC in the Loca l address te xt box. 16. Enter the IP address of the remote end of the PVC in the Remote address text box. Click Apply . 17. (Optional) Change the interface’ s logical name to a more meaningful one by typi ng the preferred name in the Logical na me text box. Click Apply . 18. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 19. Click Save to make your changes permanent. Unnumbered Interfaces T raditionally , each network interface on an IP host or router has its own IP address. This situation can cause inefficient use of the scarce IP address space because every point-to-point link must be allocated an IP network prefix . T o solve this problem, a n umber of people have proposed and implemented the concept of unnumb ered point-to-point li nes. An unnumbered point-to-point line does not have any network pref ix associated with it. As a consequence, the network interfaces connected to an unnumbered point-to-point line do not have IP addresses. Whenever the unnumbered interface generates a packet, it uses the address of the interface that the user has specified as the source address of the IP packet. Thus, fo r a rou te r to have an unnumbered interface, it must have at least one IP address assigned to it. The Nokia implementation of Unnumbered Interfac es supports OSPF (Open Short est Path First) and Static Routes only . V irtual links are not supported. Configuring Unnumbered Interfaces T o configure an unnumbered interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link to conf igure in the Logical c olumn. Example: atm s3p1c1.
2 108 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Only point-to-point interfaces can be co n figured as unnumbered interfaces. T unnels cannot be configured as unnum bered interfaces. 3. Click Y e s in the Unnumb ered Interface field. 4. Click Apply . Note If that interface was ass oc i at ed with eit he r a lo ca l or rem ote ad dr es s or bo th , they ar e automatically deleted. Note Y ou do not see local and remote address configur ation fields for unnumbered interfaces. The proxy interface field replaces th ose fields. Note The interface must not be used by a tunnel, an d OSPF is the only protocol that the interface can be running. 5. Select an interface from the Pr oxy Interface drop-down window . The Proxy Interface drop-down window shows only those interfaces that have been assigned addresses. 6. Click Apply . Note Y ou must choose a proxy inte rface for the unnumbered interface to function. Note Y ou cannot delete the only IP address of th e proxy interface. First, select another proxy interface and then delete the IP address of the original proxy inter face. If the proxy interface has multiple IP addr esses associated with it, you can delete or add addresses. A proxy interface must have at least one IP ad dress associated with it. 7. Click Save to make your changes pe rmanent. T o change an unnumbered interface to a numbered interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link to conf igure in the Logical column . Example: atm s3p1c1.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 109 Note Only point-to-point interfaces can be conf ig ured as unnumbered interfaces. T unnels cannot be configured as unnum bered interfaces. Note This interface must not be th e next hop of a st atic r oute. 3. Click No in the Unnumbered Interface field. Click Apply . 4. Click Save to make your change permanent. Note Y ou m ust now con figure a num bered logical in terface. T o configure a static route over an unn umbered interface 1. Complete “T o configure an unnumber ed interface” for the interface. 1. Click Static Routes under Configur ation > Routing in the tree view . 2. Enter the IP address of the destination ne twork in the New S tatic Route text box. 3. Enter the mask length (in bits) in the Mask Length text box. 4. Select the type of next hop the static rout e will take from the Next Hop T ype drop-down window . Y our options are Normal, Reject, and Black Hole. The default i s Normal. 5. Select Gateway Logical to specify the next-hop gateway type from the Gateway T ype drop- down window . Note Y ou select an unnumbered logical interface as the next-hop gateway when you do not know the IP address of the next-hop gateway . 6. Click Apply . 7. Click on the Gateway Logical drop-down window to view the list of unnumbered interfaces that are configured. Select the unnumbered logical interface to use as a next-hop gatewa y to the destination network. 8. Click Apply , and then click Save to make your chan ge permanent.
2 110 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring OSPF over Unnumbered Interface The following graphic represents an exampl e configur ation for running OSPF over an unnumbered interface. 1. Configure the interfaces on Nokia Platfo rm A and Nokia Platform B as in “T o configur e an unnumber ed interface.” 2. For each Nokia Platform, configure an OSPF area as in “Configuring OSPF .” 3. In the Interfaces section, clic k on the Area drop-down window next to the co nfigured unnumbered interface and select Backbone. 4. Click Apply . 5. Click Save to make your change perman en t. Note Because the unnumbered interface uses the IP a ddress of the selected proxy interfa ces whenever you change this proxy inte rface, OSPF adjacencies are re-est ablished. Note Whenever you change the unde rlying enc apsulation of th e unnumbered serial interfaces, for example from Cisco HDLC to PP P or from PPP to Frame Relay , OSPF adjacencie s ar e re -e stablishe d . OSPF over Unnumbered Interfaces Using V irtual Links The following graphic below shows a network conf iguration that uses both virtual links an d an unnumbered serial link. Nokia Platform A has two OSPF areas configured (Area 1 and Area 3), but it is not physically connec ted to the Backbone area. Thus , a virtual link is configured between Nokia Platform A and Nokia Platform C. A virtual link is also config ured between Nokia Platform B and Nokia Pl atform C because Nokia Platform B also is not physically 00043 Nokia Platform A Nokia Platform B Unnumbered Serial Link Backbone Area 2 Area 1
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 111 connected to the backbone area. Both Nokia Plat form B and Nokia Platform C are configured with IP addresses (10.10.10.2 and 101.10.10.1 respectively). The interfaces that comprise th e virtual link between Nokia Platfo rm A and Nokia Platform C are both configured as unnumber ed. This link will fail because O SPF does not support a virtual link that uses an unnumbered inte rface on either end of the link. underlying enca p sulation. For more information see RFC 2328. An y virtual link that uses OSPF must have an IP address configured on b oth ends. The virtual link between Nokia P latform B and Nokia Platfo rm C functions because each Nokia Platform is configured with an IP address. Cisco HDLC Protocol T o change the keepalive inte rval for Cisco HDLC 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical c olumn. Example: ser-s2p1. 3. Enter a number in the Keepaliv e text box of the Physical Co nfiguration table t o configure the Cisco HDLC ke epalive interval. Nokia Platform A Nokia Platform B Nokia Platform C Backbone Area 1 Area 2 Area 3 00044 Virtual Link Virtual Link 10.10.10.1 10.10.10.2 Unnumbered Serial Link Host PC Host PC Host PC Host PC
2 112 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Click Apply . This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep aliv e value configured on the system at the other end of a point-to-point link, or the link sta te fluctuates. 4. T o make your changes permanent, click Save. T o change the IP address in Cisco HDLC Note Do not change the IP address you u se in your browser to access Network V oyager . If you do, you can no longer a ccess the IP security platform with your brow ser . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link for which to ch ange the IP address in the Logical column. Example: ser-s2p1c0. 3. Delete the address from the Local address text box and from the Remote address text box. Click Apply . This removes the old IP address pair . 4. Enter the IP address of the local end of the co nnection in the Local address text box and the IP address of the remote end of the co nnection in the Remote address text box. Click Apply . This adds the new IP address pair . 5. Click Save to make your changes pe rmanent. Point-to-Point Protocol T o change the keepalive inte rval in PPP 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. Enter a numb er in the Keepa live text box to configure the PPP keepalive interval. Click Apply . This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 113 Note This value must be identical to the keep alive value configured on th e system at the other end of a point-to-point link, or the link state fluctuates. 4. Click Save to make your changes permanent. T o change the keepalive ma ximum failures in PPP 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical c olumn. Example: ser-s2p1. 3. Enter a number in the Keepaliv e maximum failures text box of the Physical Configuration table to configure the PPP keepalive maximum failures. Click Apply . This value sets the number of times the remote system may fail to se nd a keepalive protocol message within the keepalive interval before th is IP security platform considers the link down. 4. Click Save to make your changes permanent. T o change the IP address in PPP Note Do not change the IP address you u se in your browser to access Network V oyager . If you do, you can no longer access the IP security platform with your bro w ser . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link for which to change the IP address in the Logical column. Example: ser-s2p1c0. 3. Delete the address from the Local address text box and from the Remote address text box. Click Apply . This deletes the old IP ad dress pair . 4. Enter the IP address of the local end of the co nnection in the Local address text box and the IP address of the remote end of the co nnection in the Remote address text box. Click Apply . This adds the new IP address pair . 5. Click Save to make your changes permanent.
2 114 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Frame Relay Protocol T o change the keepalive inte rval in frame relay 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. Enter a number in the Keepaliv e text box to configure the Fr ame Relay keepalive interval. Click Apply . This value sets the interval, in seconds, between keepalive protocol message trans missions. These messages are used periodically to test for an active remote system. Note This value must be identical to the keep aliv e value configured on the system at the other end of a point-to-point link, or the link sta te fluctuates. 4. Click Save to make your changes pe rmanent. T o change the DLCI in frame relay Note T o move an IP address from one PVC to ano ther , you must first delete the logical interface for the old PVC, then create a new logical interface for the new PVC. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to conf igure in the Physical colu mn. Example: ser-s2p1. 3. Locate the logical interface to delete in the Logical inte rfaces table for this device. 4. Click the corresponding Delete button. Click Apply . The logical interface disappears from the list. Any IP addresses configured on this interface are also removed. 5. Enter the DLCI number in the Creat e a new inte rface DLCI text box. Click Apply . A new logical interface appears in the Interface column. The DLCI number appe ars as the channel number in the logical interface na me. The new int erface is on as default. 6. Click the logical interf ace name to go the Interface page. 7. Enter the IP address for the local end of the PVC in the Local address text box. 8. Enter the IP address of the remote end of the PVC in the Remote address text box. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 115 9. (Optional) Change the interface’ s logical name to a more meaningful on e by typing the preferred name in the Logical na me text box. Click Apply . 10. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 11 . T o make your changes permanent, click Save. T o change the LMI para meters in frame relay 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to configure in the Physical c olumn. Example: ser-s2p1 3. Click the Advanced Frame Re lay Options link to go the Frame Relay Advanced Options page. The Frame Relay Adva nced Options page allows you to config ure frame relay protocol and LMI parameters for this device. Note The values you enter are dependent on the settings of th e frame relay switch to which you are co nnected or to the sub scription pro vided by you r service provider . 4. From the Frame Relay Advanced Options page, click Up to return to the Physical Interface page. 5. Click Save to make your changes permanent. T o change the interface type in frame relay When connected to a Frame Relay switch or networ k, the interface type is usually set to DTE. Y ou may need to change the interfa ce type to DCE if it is connect ed point-to-point with another router . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to cha nge in the Physical column. Example: ser-s2p2. 3. Change DTE or DCE in the Interface type field. Click Apply . 4. Click Save to make your changes permanent.
2 116 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o change the active status m onitor setting in frame relay When connected to a Frame Relay switch or networ k, the interface type is usually set to DTE. Y ou may need to change the interfa ce type to DCE if it is connect ed point-to-point with another router . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link to cha nge in the Physical column. Example: ser-s2p2 3. Click on or of f in the Activ e S tatus Monitor field. Click Apply . 4. Click Save to make your changes pe rmanent. T o change the IP address in frame relay Note Do not change the IP address you u se in your browser to access Network V oyager . If you do, you can no longer a ccess the IP security platform with your brow ser . 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical interface link for which to ch ange the IP address in the Logical column. Example: ser-s2p1c17 3. Delete the address from the Local address text box and from the Remote address text box. Click Apply . This deletes the old IP ad dress pair . 4. Enter the IP address of the local end of the co nnection in the Local address text box and the IP address of the remote end of the co nnection in the Remote address text box. Click Apply . This adds the new IP address pair . 5. Click Save to make your changes pe rmanent. T o remove a frame relay interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the physical interface link in the Physical column on the Interface Configuration page. Example: ser-s2p1 3. Find the logical interface you wish to remove and click the corresponding Delete button in the Logical Interfaces table. Click Apply . This removes the logical interface from the list. 4. T o make your changes permanent, click Save.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 117 Loopback Interfaces By default, the loopback interface has 127.0.0.1 co nfigured as its IP address. Locally originated packets sent to this interface are sen t back to the originating process. Y ou might want to assign an address to the lo opback interface that is the same as the OSPF firewall ID, or is the termination point of a BGP session. This allows firewall adjacencies to stay up even if the out bound interface is down. Do no t specify an IP subnet mask length when you add addresses to the loopback interface. T o add an IP Address to a Loopback Interface Y ou might want to assign an address to the lo opback interface that is the same as the OSPF router ID, or is the termination point of a BGP se ssion. This allows firewall adjacencies to stay up even if the out bound interface is down. Note The loopback interface always has a logical inte rface created and enabled. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the loopback logical interface li nk in t he Logical column (loop0c0 ). 3. T o add an IP address, enter the IP address for the device in the New IP address text box. Click Apply . Each time you click Appl y , the configured IP address appears in the table. The entry fields remain blank to allow you to add more IP addresses. 4. Click Save to make your changes permanent. T o change the IP Address of a loopback interface 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the loopback logical interface li nk in t he Logical column (loop0c0 ). 3. T o remove the old IP address, click the Delete check box that corresp onds to the address to delete. Click Apply . 4. T o add the new IP address, enter the IP addre ss for the device in the New IP address text box. Click Apply . Each time you click Appl y , the configured IP address appears in the table. The entry fields remain blank to allow you to add more IP addresses. 5. Click Save to make your changes permanent.
2 118 Nokia Network Voyager for IPSO 4.0 Refe rence Guide GRE T unnels GRE tunnels encapsulate IP packets by using Generic Routing Encaps ulation (GRE) with no options. The encapsulated packets appear as uni cast IP pac kets. GRE tunnels provide redundant configuration between two sites for high availability . For each GRE tunnel you create, you must assign a local and remote IP address. Y ou also must provide the local and remote endpoint addresses of the interface to whic h this tunnel is bound. The remote router must also support GRE encaps ulation and must b e configured with a tunnel interface to the local router . Configuring GRE T unnels T o create a GRE tunnel 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click T unnels in the Physical column. 3. Click the drop-down window in the Creat e a new tunnel interface with encapsulation field and select GRE. 4. Click Apply . Each time you select a tunnel encapsulation an d click Apply , the new tunnel appears in the logical interfaces table. 5. Click the logical interface name in the Interface column of the Logical interfaces table to go to the Interface page for the specified tunnel. Example: tun0c1. 6. Enter the IP address of the local end of th e GRE tunnel in the Local address text box. The local address cannot be one of the system’ s interface addresses and must be the remote address configured for the GRE tunnel at the remote router . 7. Enter the IP address of the remote end of th e GRE tunnel in the Remote address text box. The remote address cannot be one of the syst ems interface addresses and must be the local address configured for the GRE tunnel at the remote router . 8. Enter the IP address of the local interface the GR E tunnel is bound to in the Local endpoint text box. The local endpoint must be one of the system s interface addresses and must be the remote endpoint configured for the GRE tunnel at the remote router . 9. Enter the IP address of the remote interface the GRE tunnel is bound to i n the Remote endpoint text b ox. The remote endpoint must not be one of th e systems interface addresses and must be the local endpoint configured for the GR E tunnel at the remote router . 10. Bind the tunnel to the outgoing interface:
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 119  On means that all packets th at egress through the tunnel will exit through the outgoing interface (local endpoint). If the local endp oint link fails, traf fic does not egress through the tunnel.Y ou might use this setti ng to prevent possible routing loops.  Off means that packets that egress throug h the tun nel can be routed through an y interface. Use this setting to a llow the system to use a different int erface in case the local endpoint link fails . Note If the local endpoint is a loopback addre ss, you mu st set this option to Off to allow traffic to egress through the tunn el. 11 . (Optional) Select a value from the T OS value drop-down window . Click Apply . On GRE tunnels, it is desi rable to copy or spec ify the T OS bits when the router enca psulates the packet. After you select the T OS feature, intermediate routers between the tunnel endpoints may take advantage of the QoS fe atures and possibl y improve the routing of important packets. By default, the TOS bits are copied from the inner IP header to the encapsulating IP header . If the desired T OS value is not displayed in the d rop-down window , select Custom V alue from the menu. Click Apply . An entry field appears. 12. (Optional) If you selected a custom value fr om the TOS value d rop-down window , enter a value in the range of 0-2 55. Click Apply . 13. (Optional) Change the interface’ s logical name to a more meaningful one by typi ng the preferred name in the Logical na me text box. Click Apply . 14. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 15. Click Save to make your changes permanent. T o change the local or remote address or endpoint of a GRE tunnel 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Logical column, click the Logical Interfa ce link for which to change the IP address. Example: tun0c1 3. (Optional) Enter the IP address of the local en d of the GRE tunnel in the Local address text box. The local address cannot be one of the system s interface addresses and must be the remote address configured for the GRE tunnel at the remote router .
2 120 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. (Optional) Enter the IP address of the remote end of the GRE tunnel in the Remote address text box. The remote address cannot be one of the syst ems interface addresses and must be the local address configured for the GRE tunnel at the remote router . 5. (Optional) Enter the IP address of t he local inte rface the GRE tunnel is bound to in the Local endpoint text b ox. The local endpoint must be one of the system s interface addresses and must be the remote endpoint configured for the GRE tunnel at the remote router . 6. (Optional) Enter the IP address of the local interface the GRE tunnel is bound to in the Remote endpoint text box. The remote endpoint must not be one of th e systems interface addresses and must be the local endpoint configured for the GR E tunnel at the remote router . Click Apply . 7. Click Save to make your changes pe rmanent. T o change IP TOS value of a GRE tunnel 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Logical column, click the Logical Interfa ce link of the item for which to change the TO S. E xa m p l e: tun0c1. 3. Select a value from the TOS value drop-down window . Click Apply . On GRE tunnels, it is desirable to copy or spec ify the TO S bits when the router encapsulates the packet. After you select the T OS value, intermediate routers betw een the tunnel endpoints may take advantage of the Qo S features and possibly improve the rout ing of important packets. By default, the T OS bits are copied from the inner IP header to the encapsulating IP header . If the desired T OS value is not displayed in the d rop-down window , select C USTOM V ALUE from the menu. Click Apply . An entry field appears. 4. (Optional) If you selected cu stom value fro m the T OS value drop-down window , enter a value in the range of 0 -255. Click Apply . 5. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 121 GRE T unnel Example The following steps pro vide directions on how to configure a sample GRE tunnel. Th e following figure below shows the network confi guration for this example. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click T unnels in the Physical column. 3. Click the drop-down window in the Creat e a new tunnel interface with encapsulation field and select GRE. 4. Click Apply . 5. From the Interface column on the Logi cal interfaces table, select tun01. 6. Enter 10.0.0.1 in the Local address text box. 7. Enter 10.0.0.2 in the Remote address text box. 8. Enter 192.68.26.65 in the Local endpoint text box. 9. Enter 192.68.26.74 in the Remote endpoint text bo x. 10. (Optional) Select a value from the TOS valu e drop-down window . Click Apply . On GRE tunnels, it is desi rable to copy or spec ify the T OS bits when the router enca psulates the packet. After you select the T OS feature, intermediate routers between the tunnel endpoints may take advantage of the QoS fe atures and possibl y improve the routing of important packets. By default, the TOS bits are copied from the inner IP header to the encapsulating IP header . If the desired T OS value is not displayed in the d rop-down window , select Custom V alue from the menu. Internet Remote PCs Site B Remote PCs Site A 192.68.23.0/24 10.0.0.2 10.0.0.1 VPN T unnel 192.68.22.0/24 192.68.26.74/30 192.68.26.65/30 00001 Nokia Platform Nokia Platform
2 122 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Click Apply . An entry field appears. 11 . (Optional) If you selected custom value fro m the TOS valu e drop-down window , enter a value in the range of 0 -255. 12. Click Apply . 13. (Optional) Change the interface’ s logical name to a more meaningful one by typ ing the preferred name in the Logical na me text box. Click Apply . 14. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 15. Click Save. High A vailability GRE T unnels High A vailability GRE Tunnels provide redund ant encrypted communic ation among multiple hosts. They are created by performing the procedures associated with the configuration of GRE tunnels, OSPF , VRRP , an d Check Point firewall. HA GRE T unnel Example In our example, we configure two-way tunnels be tween IP Units 1 and 2, and IP Units 3 and 4. Since the steps required to configure a HA GRe tunnel are addressed in the appropriate sections
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 123 of this reference guide, they ar e not individually repeated here . The following figure shows the network configuration for this example. Note Y ou must complete step 1 in th e following procedure before you continue to other step s. Y ou can complete steps 2 throu gh 4 in an y order . 1. Perform the steps as presented in the T o create a GRE tunnel and GRE T unnel Example sections. Sinc e this exam ple s how s you how to creat e an HA GRE tun nel, w e need to cr eate multiple tunnels and in two directions. This exam ple requires repeating steps 7 through 10 of the GRE T unnel example four times as follows: a. Configuring from IP Unit 1 to IP Unit 2: Enter 10.0.0.1 in the Local address text box. Enter 10.0.0.2 in the Remote address text box. Remote PCs Site A Remote PCs Site B VPN T unnel VPN T unnel 1 1.0.0.1 10.0.0.1 192.168.0.1 192.168.1.1 192.168.0.2 192.168.1.2 1 1.0.0.2 10.0.0.2 192.168.0.X/24 192.168.1.X/24 170.0.0.1 171.0.0.1 170.0.1.1 171.0.1.1 00002 Nokia Platform 1 Nokia Platform 2 Nokia Platform 3 Nokia Platform 4 Internet
2 124 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Enter 170.0.0.1 in the Local end point text box. Enter 171.0.0.1 in the Remote endpoin t text box. b. Configuring from IP Unit 2 to IP Unit 1: Enter 10.0.0.2 in the Local address text box. Enter 10.0.0.1 in the Remote address text box. Enter 171.0.0.1 in the Local endpoint text box. Enter 170.0.0.1 in the Remote endpoin t text box. c. Configuring from IP Unit 3 to IP Unit 4: Enter 11.0.0.1 in the Local address text box. Enter 11.0.0.2 in the Remote address text box. Enter 170.0.1.1 in the Local endpoint text box. Enter 171.0.1.1 in the Remote endpoin t text box d. Configuring from IP Unit 4 to IP Unit 3: Enter 11.0.0.2 in the Local address text box. Enter 11.0.0.1 in the Remote address text box. Enter 171.0.1.1 in the Local endpoint text box. Enter 170.0.1.1 in the Remote endpoin t text box. 2. OSPF provides redundancy in case a tunnel becomes available. OSPF detects when the firewall at the other end of an HA GRE tunnel is no longer reacha ble and then obtain s a new route by using the backup HA GRE tu nnel and forwards the pack ets to the backup firewall. Perform the steps as presented in the “Configuring OSPF” and “Configuring OSPF Example” sections. For this example, enable OSPF by using the following interface values: IP Unit 1: 10.0.0.1 and 192.168.0.1 IP Unit 2: 10.0.0.2 and 192.168.1.1 IP Unit 3: 11.0.0.1 and 192.168.0.2 IP Unit 4: 11.0.0.2 and 192.168.1.2 Use iclid to show all OSPF neighbors. Each firewall should show tw o neighbors and also show that the best route to the destinatio n network is through the correspondi ng HA GRE tunnel. 3. VRRP provides redundancy in case one of th e firewalls is lost. Perform the steps as presented in “Configuring VRRP” on page 186. Use the following values to configure VRRP: IP Unit 1: Enable VRRP on 192.168.0.1 with 192.168.0.2 as a backup IP Unit 2: Enable VRRP on 192.168.1.1 with 192.168.1.2 as a backup IP Unit 3: Enable VRRP on 192.168.0.2 with 192.168.0.1 as a backup IP Unit 4: Enable VRRP on 192.168.1.2 with 192.168.1.1 as a backup 4. HA GRE tunnels work by encap sulating the original packet and resending the packet through the firewall. The first time the firewall see s the packet, it has the original IP header; the second time, the packet has th e end points of the tunnels as the sr c and dst IP addresses. The firewall needs to be configured to accept all packets with the original IP heade r so the encapsulation can take place. An encryption rule is then defined to encrypt th ose packets that match the tunnel endpoints.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 125 DVMRP T unnels DVMRP (Distance V ector Multicast Routing Protocol) tunnels encapsulate multicast packets IP unicast packets. This technique allows two multi cast routers to exchange multicast packets even when they are separated by routers that cannot forward multicast packets. For each DVMRP tunnel you create, you must prov ide the IP address of the interfac e that forms the local endpoint of the tunnel and the IP address of the multicast router that is at the remote end of the tunnel forming the remote endpoint of the tunnel. Note The remote multicast router must support IP-i n-IP encapsulatio n and must be configured with a tunnel interface to the local router . When you have created the DVMRP tu nnel interface, set all other DVMRP multicast configuration parameters from the DVMRP configuration page. T o create a DVMRP tunnel 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click T unnels in the Physical column. 3. From the pulldown menu in the Create a new tunnel interface with encapsulation, select DVMRP . 4. Click Apply . Each time you select a tunnel encapsulation an d click Ap ply , a new tunnel appears in the table. 5. Click the logical interface name in the Interface column of the Logical interfaces table; this takes you to the interface page fo r the specified tunnel. Example: tun0c1. 6. Enter the IP address of the local end of the DVMRP tunnel in the Local address text box. The local address must be one of the systems interface IP addresses and must also be the remote address configured on the DVM RP tunnel on the remote router . 7. Enter the IP address of the remote end of th e DVMRP tunnel in the Remote Address text box. The remote address must be the IP address of the multicast router at the remote end of the DVMRP tunnel. It cannot be one of the system’ s interface addresses. 8. (Optional) Change the interface’ s logical name to a more meaningful nam e by typing the preferred name in the Logical na me text box. Click Apply . 9. (Optional) Add a comment to further define th e logical interfaces func tion in the Comments text box. Click Apply . 10. T o make your change s pe rmanent, click Save.
2 126 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note When the DVMRP tunnel inte rface is created, set all other DVMRP configuration parameter s from the DVMRP p age. T o change the local or remote addresses of a DVMRP tunnel 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. In the Logical column, click the Logical Interface link on the tunnel that is to have the IP address changed. Example: tun0c1 3. (Optional) Enter the IP address of the local end of the DVMRP tunnel in the Local Address text box. The local address must be one of the systems interface IP addresses and must also be the remote address configured on the DVM RP tunnel on the remote router . 4. (Optional) Enter the IP address of the remo te end of t he DVMRP tunnel in the Remote Address text box. The remote address must be the IP address of the multicast router at the remote end of the DVMRP tunnel. It cannot be one of the systems interface addresses. 5. Click Apply . 6. Click Save to make your changes pe rmanent. Note When the tu nnel interface has been crea ted, set all ot her DVMRP con figuration paramet ers from the DVMRP p age. DVMRP T unnel Example The following example contains one connection to the Internet through an Internet Service Provider (ISP). This ISP provides a multicast tr af fic tunnel. Multicast traf fic uses the address space above 224.0.0.0 and below 238.0.0.0. Multicast traffic is dif ferent from unicast (point-to- point) traffic in that is in one- to-many traf fic forwarded by routers.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 127 A router forwards Multicast traffic to an adjacent router only if that router has a client that accepts multicast traffic. Nokia IP security platforms require Distance V ector Multicast Routing Protocol (DVMRP) to be enabled on the inte rfaces to which you forward multicast traffic. In the preceding example, a DVMRP tunnel orig inates from the ISP at 22.254/24. This tunnel has a present endpoint of 22.1/24. A DVMRP tunn el set up on Nokia Platform A points to 22.254/24. 1. Initiate a Network V oyager session to Nokia Platform A. In this example, we use Nokia Platform A as the starting point. 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click T unnels in the Physical column. 3. From the pulldown menu in the Create a new tunnel interface with encapsulation, select DVMRP . 4. Click Apply . Each time you select a tunnel encapsulation an d click Ap ply , a new tunnel appears in the table. 5. Click the logical interface name in the Interface column of the Logical interfaces table; this takes you to the interface pa ge for the specified tunnel. Example: tun0c1 6. Enter the following in the Lo cal IP Address text box: 192.168.22.1 7. Enter 192.168.22.254 in the Remote IP Address text box 8. (Optional) Change the interfaces logical name to a more meaningful name by typing the preferred name in the Logi cal na me text box. 00039 Nokia Platform B Nokia Platform D Nokia Platform A 26.69/30 26.66/30 22.254/24 Network Prefix: 192.168.0.0 Remote PCs using Multicast Applications Nokia Platform C 26.73/30 26.70/30 26.65/30 26.74/30 24.0/24 22.1/24 DVMRP T unnel endpoint from ISP 192.168.22.254/24 to 22.1/24 Internet
2 128 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 9. Click Apply . 10. Click Sa ve to make changes permanent. Note St ep s 17 through 21 requi re that yo u us e the Rout in g Co nfiguration page by first com pleting steps 13 throug h 16. 11 . Click DVMRP under Configuration > Routing in the tree view . 12. For ea ch interface to configure fo r DVMRP , click On for the interface. 13. Click Apply . 14. (Optional) Define the time-to-live (TTL) threshold for the multicast datagram. Enter it as follows in the Threshold text box: 128 This example 128 is for the purpose of broa dcasting. A 128 TTL is defined as Internet broadcast. 15. (Optional) Define the cost of the tunnel. Enter this cost in the Metric text box. This shows the route preference. Leave this as the default unless there are many other mu lticast tunnels present in your network. 16. Click Apply . 17. Perform steps 1 through 13 with addresses rever sed on the exit point fo r the multicast tunnel. In this example, the ISP has already done this for us. 18. Ens ure that DVMRP is running on all inte rfaces (Ethernet, A TM, FDDI) on which the multicast is to be received (See “Configuring DVMRP” ). ARP T able Entries ARP allows a host to find the physical address of a tar get host on the same physical network using only the target’ s IP address. ARP is a low- level protocol that hides the underlying network physical addressing and permits assignment of an arbitrary IP address to every machine. ARP is considered part of the ph ysical network syst em and not as part of the Internet protocols. T o change ARP global parameters 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Enter the keep time (in seconds) in the Keep Time field in th e Global ARP Settings section. Keep time specifies the time, in seconds, to keep resolved dynamic AR P entries. If the entry is not referenced and not used by traffic afte r the given time elapses, the entry is removed. The range of the Keep T ime value is 60 to 86 400 seconds with a default of 14400 seconds (4 hours). 3. Enter the retry limit in the Retry Limit field in the Global ARP Settings section.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 129 The Retry Limit specifies the number of tim es to retry ARP requests until ho lding off requests for 20 seconds. Retry reques ts occur at a rate of up to once per second. The range of retry limit is 1 to 100 and the defaul t value is 3. 4. If your network configuration re quires it, click the button to enable the appliance to accept multicast ARP replies. Enable this feature if this syst em is connected to an IPSO cluster . Because all the nodes of an IPSO cluster share a single multicast MAC addre ss, routers that connect to a cluster (either directly or through a switch o r hub) must be able to accept ARP replies that contain a multicast MAC address. 5. Click Apply . 6. Click Save to make your changes permanent. T o add a static ARP entry 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Enter the new IP address in the IP Address fi eld in the Add a New Static ARP Entry section. 3. In the same table, enter the MAC address corresponding to the IP a ddress in the MAC Address text box 4. Click Apply . 5. Click Save to make your changes permanent. T o add a proxy ARP entry A proxy ARP entry makes this system respond to ARP requests for a given IP address received through any interface. This system does not us e proxy ARP entries when it forwards packets. 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Enter the new IP address in the IP Address fi eld in the Add a New Proxy ARP Entry section. 3. In the Interface field of the Add a new Proxy ARP Entry section, select the interface whose MAC address is returned in ARP replies. Selecting User-defined MAC Address allows yo u to specify an arbitrary MAC address for the entry . Click Apply . 4. (Optional) If User-Defined MAC Address was selected, enter the MAC address corresponding to the IP address in the MAC Address text box in the Proxy ARP Entries table. Click Apply . 5. Click Save to make your changes permanent.
2 130 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note In VRRP config urations, conf iguring proxy A RP using static NA T addresses an d interface MAC addresses is not supported. T o delete a static ARP entry 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Click the checkbox in the Delete column next to the table entry to delete. Click Apply . 3. Click Save to make your changes pe rmanent. T o view dynamic ARP entries 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Click the Display or Remove Dynamic ARP Entries link. T o delete dynamic ARP entries 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Click the Display or Remove Dynamic ARP Entries link. 3. Click the check box in the Delete column next to the ARP entry to delete. Click Apply . T o flush all dynamic ARP entries 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Click Flush. Configuring ARP for A TM Interfaces T o change InA TMARP global p arameters The InA TMA RP protocol is used for finding a mapping from IP addresses to A TM PVCs in a logical IP subnet (LIS) on top of an A TM network. 1. Click ARP under Configuration > Interfa ce Configuration in the tree view . 2. Enter a value for one or more of th e Keep T ime, T imeout, Retry Limit and Holdof f T ime parameters in the correspon ding fields in the Global InA TMARP Settings table.  Keep T ime specifies time, in seconds, to k eep resolved dynamic A TM ARP entries. The range of Keep T ime value is 1 to 900 seconds (15 minutes).  T imeout specifies an InA TMARP request retr ansmission interval in seconds. Network V oyager enforces that the timeout must be le ss than a third of Keep Time. The Range of T imeout value is 1 to 300 with a default valu e of five seconds.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 131  Retry Limit specifies the number of times to retry InA TMARP requests after which the Holdoff T imer is started. The range of Retry Limit value is 1 to 100 with a default value of 5.  Holdoff T ime specifies time, in seconds, to hold of f InA TMARP requests after the maximum number of retries. The range of H oldoff T ime value is 1 to 900 seconds (15 minutes), with a default value of 60 sec on ds (one minute). 3. Click Apply . 4. Click Save to make your changes permanent. T o add a static A TM ARP entry 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical A TM interface to configure in the Logical column. 3. Click the A TM ARP Entries link. 4. Enter the IP address of the new static A TM ARP en try in the IP Address field in the Create a new static A TM ARP entry section and ente r the VPI/VCI number of the corresponding PVC in the VPI/VCI field. The IP address mu st belong to the subnet of the logical A TM interface and the VCI must be one of those configured for the interface. Note Whenever sta tic A TM ARP entries are applied, dynamic entries are no longer update d; therefore, new neighbors cannot be seen through a dynamic InA TMARP mechanism. 5. Click Apply . The newly crea ted static A TM ARP entry appea r s in the S tatic A TM ARP Entries table. The IP datagrams destined to the IP address of th e entry are sent to the PVC specified in the entry . 6. Click Save to make your changes permanent. T o delete a static A TM ARP entry 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical A TM interface to change in the Logical column. 3. Click the A TM ARP Entries link. 4. Click the Delete checkbox of the A TM ARP entry to delete. Click Apply . 5. Click Save to make your changes permanent. T o view and delete dynamic A TM ARP entries 1. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 2. Click the logical A TM interface to configure in the Logical column.
2 132 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 3. Click the A TM ARP Entries link. Dynamic A TM AR P entries appear in a table at the bottom of the page. 4. Click the Delete check box next to the dynamic A TM ARP entry to delete. Click Apply . Note Deleting a dynamic entry tri ggers a transmission of an InA TMARP request on the PVC. If the remote end responds and it s IP address is not changed, a new dynamic A TM ARP entry identical to the deleted one ap pea rs in the table immediatel y . T ransp arent Mode Use transparent mode to allow your IPSO applia nce to behave like a layer 2 device such as a bridge. Benefits of this type of network conf iguration include being ab le to maintain your current local area network configuration or main tain your existing IP address with your ISP . Note T ransparent m ode inter-operates with Check Po in t FireW all-1. There is no special code or software required for the bridging functio nality to be supported in FireW all-1. Using transparent mode, you configure Ethernet in terfaces on the firewall router to behave like ports on a bridge. The inte rfaces then forward tr affic using layer 2 addressing. Y ou can co nfigure some interfaces to use transparent mode while other interfac es on the same platform are configured normally . T raffic between transparent mode interfaces is inspected at layer 2 while traffic between normal interfaces, or between transparent and normal interfa ces, is ins pected at layer 3. Limit ations T ransparent mode has the following limitations.  T ransparent mode sup po r ts on ly Ethernet interfaces (10/10 0/1 000 Mbps).  T ransparent mode does not provide full-fledged bridging functionality such as loop detection or spanning tree.  The IP2250 appl iance does no t support transparent mode.  T ransparent mode is not supported in a cluster en viro nmen t. Y ou cannot use transparent mode on interfaces that partic ipate in an IPSO cluster .  T ransparent mode is supported with VRRP .  Interfaces configured for transparent mode do no t pass non-IP traffic. In fact, all non-IP traffic is simply dropped at the Ethernet inpu t layer before it reaches the transparent mode layer which only registers to receive IP traf fic.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 133 T ransp arent Mode Processing Det ails When you configure transparent mode, it is added to the IPSO kernel as a module situated between the layer 2 and the upper protocol layers. When a logical interface is configured for the transparent mode, transparent mode Address Resolution Protocols (ARP) and IP receive handlers replace the common ARP and IP receive handlers. This enables the transparent mode operation to essentially intercep t all packets between the link layer (laye r 2) and IPv4 and IPv6 network layer (laye r 3). Besides transmitting packets that are bridged from one interface to another based on MAC addresses, the transparent mode module also trans mits pa ckets that originate locally or are forwarded based on routing. Locally originated ARP packets are broadcast on all interfaces of the transparent mode group. Locally originated IP packets ar e also broadcast on all interfaces of the transparent mode group if the egress interface is not found in the forwarding table. If there are any VLAN interfaces am ong the interfaces in the tran sparent mode group, the link header of a bridged packet is modified to have the proper format for the egress interface. Neighbor learning is the process of associati ng a MAC address with an interface whenever a packet is received w ith an unknown source MAC address. This association is called a neighbor control block. The neighbor co ntro l block is deleted from the address tab le after a period of inactivity (age time out). The age time-out is reset to this in itial value for the neighbor control block on receiving any packet from that neighbor . Packet processing for a firewall consists of ingress and egress processing. This applies only to IP packets; ARP packets are never delivered to th e firewall. Egress processing occurs when a packet returns from the firewall’ s ingress filtering, the packet is delivered to the firewall again for egress filtering. The packet is delivered with the in terface index of the egress interface. If it is a link multicast packet, a copy of the packet is made for each interface of the transparent mode group, except the received interface. It is th en delivered to the fire wall with the associated interface index. Note Network Addres s T ranslation (NA T) is n ot supported in transparent mode . T ransparent mode does support imp licit “NA T ing” of the pa cket’ s destination IP address to a local IP address to deliver p ackets to the security server on the local prot ocol st ack. It does this by performing a route look up for the packet’s dest ination IP address to deter mine whether the packet destination is local after the packet returns from the firewall’s ingress filtering. If the packet s destination is local, the packet is del iv er ed to th e IP laye r for local processing.
2 134 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring T ransparent Mode in VPN Environment s T o configure transparent mode in a virtual privat e network enviro nment, yo u must create a range or group of addresses that will be protected behi nd the IP address on the bridge. This must be done because addresses cannot be l earned dynamica lly behind a firewall. In this example, the network administrator of Network A wants to provide Network B with access to certain addresses behind the Nokia Platfo rm with Firewall, which is in transparent mode. T o do this, the network administrator would do the fol lowing in the firewall software: 1. Create a group of addresses on Firewall A. In this case, the network administrator groups to gether addre sses x, y , and z into group M. 2. Create an object for the remote Firewall B. 3. Create a rule, for example, Group M; Network B; Encrypt. The network administrator on Network B also creates a rule for encrypted traffic through Firewall B. Network A Network B Internet Switch Switch 00327 Nokia Platform with Firewall XYZ Firewall B Group M ISP
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 135 Note For information on how to create group s, objects, and rules on the firewall, see your Check Point document ation that was included with your Nokia IPSO software package. Example of T ransp arent Mode The following illustration shows a network connected to an Internet service provider (ISP) through a switch. In this configuration, all address ing to the local area network (LAN) is done at Layer 2. Below , the network administrator wants to pr otect the LAN wit h a firewall. Installing a conventional firewall requires the network admini strator to obtain anot her IP address from the ISP , IP 1.5.4.0 / 24 . Nokia’ s transparent mode solution provides firewall protection for the LAN without having to obtain new IP addresses or reconfigure addresses on the LAN. Packet traffic continues to run at Layer 2, rather than at Layer 3 w ith a conventional firewall solution. LAN Internet ISP Switch 1.5.2.1/24 00293 1.5.3.2/24 LAN Internet ISP Switch Switch 1.5.3.2/24 1.5.3.3/24 1.5.4.0/24 00294 LAN Internet ISP Switch Switch 1.5.3.2/24 1.5.3.3/24 1.5.3.4/24 00295 Nokia Platform with Firewall
2 136 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure transparent mode in the prec eding network configuration 1. Click T ransparent Mode under Configuration > Interface Configuration in the tree view . 2. Enter any positive integer (an integer greater than 0) in the edit box, for example 100 and click Apply . 3. Click the link of the transparent mode group yo u created. It will appe ar as XMG with the number you entered in step 3, for example XMG 100. 4. In the Add Interface drop-dow n box, select an interface to associate with the transparent mode group. In this case, select the logical interfaces associated with IP address 1.5.3.3/24 and click Apply . Note Because transp arent mode group s are disabled by default, do not associate interfaces to a transparent mode group that is in use. If you do, you will lose connectivity to those interfaces. Note An interface can be in at most one group. Once you have associated an interface to a group, you will not have the op tion to associate it with another group. 5. In the Add Interface drop-down box, select the logical interfaces associated with IP address 1.5.3.4/24 and click Apply . 6. Click Up. 7. Select Y es in the Enable column associated with XMG 100 and click Apply . 8. Click Save to make your changes pe rmanent Note When you m ake changes to a transparent m ode group, yo u must stop and restart the firewall. Once you have enabled transparent mode and rest arted your firewall, packets destined for your LAN are sent at Layer 2. Packets destined for an IP address are sent at Layer 3. Configuring T ransparent Mode Y ou configure transparent mode by first creati ng a tran sparen t mode group an d then adding interfaces to the group. When interfaces are in the same transparent mode group, then they are logically in the same subnet. A transparent mode group is disabled until you enable it.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 137 Note In the disabled m ode, the tran sp arent mode group drop s all p acket s received on or d estined to the interfaces in that gr oup. Because transp are nt mode groups are disabled by d efault, do not associate interfaces to a trans parent mo de group that is in use or you will lose connectivity to those interfaces . If you have more than on e transparent mode gro up on the same platform, th e g roups must be visible to each oth er on the routing layer (Layer 3). If yo u need routing, then at least on e interface in each gr oup should have an IP ad dress. Creating and Deleting T ransparent Mode Group s Y ou create a transparent mode group by first crea ting the group then adding the interfaces to the group. (See “Adding or Removing Interfaces to or from T ransparent Mode Grou ps.” ) By default, a transparent mode group stays disabled unless explicitly enab led. In the disabled mode, the transparent mode group drops all packets rec eived on or destined to the interfaces in that group. (See “Enabling or Disabling a T ransparent Mode Group.” ) T o create a transparent mode gro up 1. Click T ransparent Mode under Configuration > Interface Configuration in the tree view . 2. Enter any positive integer (an integer greater than 0) in the edit box. 3. Click Apply . 4. Click Save to make your changes permanent. If you make delete a transport mode group or add or remove interfaces, the firewall sometimes does not learn of the changes when you get th e topology . If you get the topology and your changes to interfaces are not shown, stop and restart the firewall. T o delete a transparent mode group 1. Click T ransparent Mode under Configuration > Interface Configuration in the tree view . 2. Click the Delete radio button associated with the group you would like to delete and click Apply . 3. Click Save to make your changes permanent. Adding or Removing Interfaces to or from T ransp arent Mode Group s If you delete a transport mode gro up or add or remove interfaces, th e firewall sometimes does not learn of the changes when you get the topolo gy . If you get the topology a nd your changes to interfaces are not shown, you can stop and restart the firewall to view your changes.
2 138 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o add or remove an interface to/from a transp arent mode group 1. Click T ransparent Mode under Configuration > Interface Configuration in the tree view . 2. Click the link of the appropriate transparent mode group. 3. T o add an interface to the transparent mode group, select it from the Add Interface drop- down box. Note Because transp arent mode group s are disabled by default, do not associate interfaces to a transparent mode group that is in use. If you do, you will lose connectivity to those interfaces. Note An interface can be in at most one group. Once you have associated an interface to a group, you will not have the op tion to associate it with another group. 4. T o delete an interface from the transparent mo de group, select the Remove radio button associated with the interface you want to delete and click Apply . 5. (Optional) Repeat to add or remove other interfaces to or from the transparent mode group. 6. Click Save to make your changes pe rmanent. Enabling or Disabling a T ransp arent Mode Group By default, a transpare nt mode group is disa bled unless explicitly enabled. In the disabled mode, the transparent mode group drops all packets receiv ed on or destined to the interfaces in that group. Y ou must enable the tr ansparent mode group to start the operation of the group. Note A transparent mode group must h ave at least one interface associated with it before you can enable the grou p. T o enable or disable a transparent m ode group 1. Click T ransparent Mode under Configuration > Interface Configuration in the tree view . 2. Select Y es or No in the Enable column associated with the tr ansparent mode group you want to enable or disable. 3. Click Apply . 4. Click Save to make your changes pe rmanent
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 139 Enabling or Disabling VRRP for a T ransparent Mode Group If you are enabling VRRP on a VRRP master , the node will perform transparent mode operations as describ ed in the s ection, “T ransparent Mode” on page 132. As a VRRP standby , it will drop all packets except t hose with local destinations. For more information on configuring VRRP , see “Configuring VRRP” on page 1 86 T o enable or disable VRRP for a transp arent mode group 1. Click T ransparent Mode under Configuration > Interface Configuration in the tree view . 2. Click the link of the transpar ent mod e group to which you would like to enable VRRP . 3. Select the Y es or No radio butto n in the VRRP Enabled table. 4. Click Apply . 5. Click Save to make your changes permanent. Monitoring T ransp arent Mode Group s T o monitor transparent m ode group s 1. Click T ransparent Mode under Monitor in the tree view . 2. Click a transparent mod e group under XMODE Group Id. T ransp arent Mode and Check Point NGX This section explains some details about configuring a firewall to work with transparent mode. Configuring Antispoofing The proper configuratio n for antispoofing depends on how the interfaces in the transparent mode group are configured. All Interfaces A re Internal If all the interfaces in the group are internal, yo u should configure antispoofing normally . Y ou treat the interfaces as being on the same subne t an d, any other nested networks must be p roperly defined so that antisp oofing to be aw are of them and traf fic is not dropped. One Interface Is External If one interface is external, do not use antispoofin g. If an tispoofing is ap p lied, the firewall drops reply packets because they are sourced from the same s ubnet. Configuring VRRP When you use the Check Point NGX SmartDas hboard to configure the Gateway Cluster properties of a VRRP pair that uses IPSO tr ansparent mode, you must follow this procedure.
2 140 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o add nodes configured for transparent mo de to a cluster using SmartDashboard 1. Create a gateway object for each of the VRRP nodes. 2. Define the topology for each gateway object. Make sure that transparent mode is prope rly configured with the address ranges to the exte rnal and internal networks correctly defined. 3. Create the cluster object. 4. Add each gateway to the cluster object using the Add Gateway to Cluster button. If you use the New Cluster Member button to add a VRRP member th at uses transparent mode to a cluster , you cannot correctly configure the T opology . V irtual T unnel Interfaces (FWVPN) for Route-Based VPN V irtual T unnel Interfaces (VTI) support Check Po int route-based VPN. A VTI is a virtual interface that can be used as a ga teway to the en cryption domain of the peer Gateway . Each VTI is associated with a single tunnel to a VPN-1 Pro peer gateway . As with domain-based VPNs, the tunnel and its properties is d efined by a VP N community linking the two gateways. The peer gateway is also configured with a corresponding VTI. The native IP routing mechan ism on each gateway can then direct traffic in to the tunnel just as it would for any other type of interface and the traf fic will be encrypted. For more information about route- based VPN, see the Check Point V irtual Private Networks guide. Unnumbered VTIs Nokia IPSO supports only unnumb ered VTIs. Local and remote IP addresses are not configured; instead, the interface is associate d with a proxy interface from whi c h it inherits an IP address. T raffic that is i nitiated by the gateway and rout ed through the VTI will ha ve the proxy interface IP address as the source IP address. If you want the source IP address to be an IP ad dress not used on the system, you can create a loopback interface with the desired IP address and use it as the proxy interface. Routing T raffic through the VTI In route-based VPN, a packe t is encrypted only if it is routed through the virtual tunnel interface. T o make sure that the traf fic is routed through the VTI, you have several options:  Y ou can make the VTI the default route. Make su re you also have a static or dynamic route that enables the gateway to reach the external interface of the peer gateway , and vice versa.  Y ou can add a specific static route to the in tended network behind the peer gateway for which the next hop is the VTI.  Y ou can configure a dynami c routing protocol on the VTI. For ex ample, you can enable OSPF on the VTI and redistri bute the internal networks route to OSPF external. Or you can enable OSPF on both the VTI and its proxy interface.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 141 VTIs appear in Nokia Network V oya ger as unnumbered interfa ces and are given logical names in the form tun0c n . Y ou configure static or dynamic routes on VTIs the same way you con figure them on other unnumbere d interfaces. The dynamic routing pr oto cols supported on VTIs are BGP4 and OSPFv2.
2 142 Nokia Network Voyager for IPSO 4.0 Refe rence Guide VRRP Support VRRP HA mode is supported fo r OSPFv2 over virtual tunnels. Only active-passive mode is supported: that is, only one gateway can have the master state. Because a VTI is an unnumbered interface, you ca nnot configure a virtual IP address on it. T o run in VRRP mode across the tunnel, OSPF instea d detects the presence of one or more VRRP virtual IP addresses on the system. When configuring OSPF to run in VRRP mode, make sur e that you:  Configure OSPF identically on the VTI in both the master and backup.  T urn on the V irtual Address option in the OSPF configuration for the VTI. The OSPF proto col runs only on the VTI of the m aster gateway . If the mast er gateway fails, the OSPF protocol starts running on the VTI of the backup gateway . Because adjacency needs to be reestablished, there will be a temporary loss of routes. Creating V irtual T unnel Interfaces T o create a virtual tunnel interface 1. Create a VPN community the contains the tw o gateways, using the SmartDashboard. T he VPN community defines the vi rtual tunnel prop erties, such as the type of encryption used. Because encryption is dete rmined by routing packets through th e tunnel, no VPN domain is required. Y ou must configure an em pty VPN domain as described in the “T o create the VPN community” procedure. 2. Create the virtual tunnel interface on each gate way , using either Nokia Network V oyager or the Check Point vpn shell. The procedure “T o create the virtual tunnel interface” describes how to do so using Noki a Network V oyager . T o create the VPN community 1. Using the Check Point SmartDashboard , create the peer gateway objects. 2. In the T opology tab of o ne gateway object, select the Manually defined option under VPN Domain and create a new group domain that has no members. Assign the second gateway also to this empty domain.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 143 Note If both domain-based VPN and route- ba sed VPN are configured, then domai n-b ased VPN takes p riority . Configuring a VTI does not o verride the domain-based VPN. The only way to configure no VPN domain is to create an empty VPN domain group. 3. Create a VPN community and add both gateways to that community . 4. Create a security policy rule and in stall the policy on both gateways.
2 144 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o create the virtual tunnel interface 1. In Network V oyager n a v igation tree, select Configuration > Interface Configuration > FWVPN tunnel. 2. Enter the name of the peer gateway in the Peer GW Object Name field. Use the same name you assigned the gateway when you created it in the SmartDashboard. 3. From the drop-down list, select the proxy interface. Because the proxy interface is used as the source IP address for the outbound traffi c, you would normally choose an external interface for the proxy interface. Y ou can also use a loopback interface. 4. Click Apply and then Save. The new tunnel is added to the list of tunnels. If the status field shows a status other than OK, you can click on the tunnel interface name to display details about the VTI. The Description field contains information provid ed by the Check Point software about the status of the VP N tunnel. Note Both the Description and S tatus fie lds are read-only fields. Do n ot edit them. Once created, a VTI is always up unless you administratively set it down.
Nokia Network Voyager for IPSO 4.0 Reference Guide 145 3 Configuring System Functions This chapter describes how to config ure many basic sys te m functions. Configuring DHCP Dynamic Host Configu ration Protocol (DHCP) fo r Nokia IPSO provides complete DHCP client and DHCP server capabilities for you r Nokia appliance. DHCP gives you the ability to provide network configuration param eters , through a server , to clients which need the parameters to operate o n a network. DHCP el iminates the need for you to configure each client manu ally and thus reduces configuration errors. The Nokia IPSO implementation of DHCP includes the following:  Enabling the DHCP client  Configuring the DHCP client interface  Dynamic and fixed IP address allocation from the DHCP server .  Automatic Domain Name System (DNS) server updates from the DHCP server .  The ability to specify various c lient parameters including wh ich servers are available for services such as DNS, NTP , TFTP , and SMTP . Y o u can also configure NetBIOS over TCP/ IP which includes identifying WINS and Datagram Distribution servers available to clients.  Support for VLAN clients. Note If you enable the IPSO DHCP server , the appliance receives and accepts DHCP request s even if ther e is a firewall ru le blocking D HCP requests. Althou gh requests are s hown as blocked in the firewall logs, the IPSO DHCP serv er s till provides addresses to clients that request them. If you don’t ne ed the DHCP server , le ave it disab led (the default option) . If you enable the DHCP server but do n ot want DHCP requests from the out side to be accepted, enable it only on internal interfaces.
3 146 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring DHCP Client Interfaces T o configure the DHCP client interface 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the logical interface in the DHCP Inte rface Configuration table to be configured. Note The logical inte rface must be enabled. It is enabled if the link-st ate indicator is green. For more informa ti on on how to configure Etherne t inter faces see “Ethernet Interfaces” on page 34. 3. (Optional) Enter a unique name in the Client ID text box. The name will be used in request packets instead of the MAC address of the interface. 4. Enter a value, in seconds, in the T imeout text box. If you do not enter a value, the configuration defaults to 60 sec on ds. 5. Enter a value, in seconds , in the Retry text box. If you do not enter a value, the configuration defaults to 300 secon d s. 6. Enter a value, in seconds, in the Lease text bo x f or the length of time the IP address will be leased to the interface. 7. Enter a value, in seconds, in the Reboot text bo x for the client to reacquire an expired lease address before it attempts to discover a new address 8. Click Apply . 9. Click Save to make your changes pe rmanent. DHCP Client Configuration T o enable the DHCP client process 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click Client next to the logical interface link to be configured as a DHCP client in the DHCP Interface Configuration table. 3. In the DHCP Client Configura tion table, select Enable. Note The Ethernet interface must be enable d before you enable the client. For more information on how to confi gure Ethernet interfaces see “Ethernet Interfa ces” on pag e 34. 4. Enter a host name in th e Host Name text box. 5. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 147 6. Click Save to make your changes permanent. Configuring the DHCP Server T o configure the DHCP server process 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click Server in the DHCP Service Selection box. 3. Click Apply . Note Y ou must configure an Ethernet interface an d enter the subnet ad dr ess and the subnet mask length on which the interface is listening in the Subnet text box (see step s 6 and 7) before you enable the DHCP Server Process. For more infor mation on ho w to configure Ethernet interfaces see “Ethernet Interfaces” on page 34. 4. Click the Add a new Subnet Entry link. 5. Enter the subnet address of the Ethernet inte rface you have configured for the DHCP server process in the Subnet text box. 6. Enter the mask length for the subnet in the Mask Leng th text box. 7. (Optional) Enter the lease length, in seconds, fo r client IP addresse s in the Default Lease text box. This wo uld be applied only if clients do not request a specific lease time. If you do not enter a value, the configuration will default to 43,200 seconds. 8. (Optional) Enter the maximum lease length, in seconds, for client IP addresses in the Maximum Lease text box. This would be the l ongest lease the server would allow . If you do not enter a value, the configuratio n will default to 86,400 seconds. 9. Enter the range of IP addresses the server will assign to clients in the Start and End text boxes respectively in the New Pool field. Note Make sure that Enabled is selected in the State fie ld. This is the default selection. Note If you are con figuring a large num ber of VLAN s, you might experience a delay in having IP addresses a ssigned to VLAN interfaces. 10. (Optional) Enter the T rivial File T ransfer Protocol (TFTP) server clients will use in the TFTP text box. 11 . (Optional) Enter the file name where diskless clients will find the boot file in the File Name text box.
3 148 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 12. (Optional) Enter a path for clients to get add itional configuration options in the Extensions Path text box. Note Y ou must configure the TFTP option to us e the Extension Path option sinc e clients will use TFTP to tr ansfer the configuration options fro m the server . 13. (Optional) Enter the root path where diskless clients mount a network file system (NFS) in the Root Filename text box. 14. Enter the IP address of the default router clients will use in the Router text box. 15. (Optional) Enter the domain name you want clients to use in the Domain text box. 16. (Optional) Enter the time offset for clients in the Time Of fset text box. 17. (Optional) Enter the IP address or the name of the swap server diskless clients will use in the Swap Server text box. 18. Enter the Domain Name System (DNS) server clients will use to resolve domain names in the DNS Servers text box. 19. Enter the Network T ime Protocol (NTP) servers c lients will use in the NTP Servers text box. Enter the servers you want clients to use in the order of preference separated by commas. 20. Enter the Simple Mail T ransfer Protocol (SMTP) servers avai la ble to clients, separated by commas, in the SMTP Servers text box. 21. If you configure NetBIOS, enter the W indows In ternet Naming Servers (WINS) available to clients in the WINS text box. 22. If you configure NetBIOS, enter the Datagram Di stribution (DD ) servers available to clients, separated by commas, in the DD Servers text box. 23. If you configure NetBIOS, enter the node type th at the client will configure itself as in the Node T ype text box. 24. If yo u configure NetBIOS, enter the scope for the client in the Scope text box. 25. Click Apply . 26. Click Save to make your changes perman en t. DHCP Server Configuration T o enable the DHCP server process 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click Server in the DHCP Service Selection box. 3. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 149 Note Y ou must configure an Ethernet interface an d enter the subnet ad dr ess and the subnet mask length on which the interface is listening befor e you enable the DHCP Server Process. See “Configuring the DHCP Se rver” on page 147, step s 5, 6, and 7. For more information on how to config ur e Ethernet interfaces, see “Ethernet In terfaces” on page 34. 4. Click Enable in the DHCP Server Process box. 5. Click Apply . 6. Click Save to make your changes permanent. T o disable the DHCP server process 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click Disable in the DHCP Server Process box. 3. Click Apply . 4. Click Save to make your changes permanent. Changing DHCP Service T o change the DHCP service 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the Change DHCP Service link. 3. Click the service for which you would like to co nfigure your appliance in the DHCP Service Selection box. 4. Click Apply . 5. Click Save to make your changes permanent. Adding DHCP Address Pools T o add additional IP address ranges to an existing DHCP server configuration 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the IP address link for which you would like to add additional ad dress ranges in the DHCP Server Subnet Configuration box. 3. Enter the range of IP addresses the server will assign to clients in the Start and End text boxes respectively in the New Pool field.
3 150 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Make sure that Enabled is se lected in the S tate field. Th is is the default selection. Note If you are configuring a lar ge numbe r of VLANs, you migh t experience a delay in having IP addresses a ssigned to VLAN interfaces. 4. Click Apply . 5. Click Save to maker you changes pe rmanent. Enabling or Disabling DHCP Address Pools T o enable and existing IP address pool 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click enable or disable next to the subnet IP address link in the DHCP Server Subnet Configuration box. 3. Click Apply . 4. Click Save to make your changes pe rmanent. Assigning a Fixed-IP Address to a Client T o assign a fixed-IP address to a client 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the Add a new Fixed-IP Entry link in the Fixed-IP Address Client Configuration. 3. (Optional) Enter a host name that will be assigne d to the client in the Host Name text box. If you do not enter a host name, the server will a ssign the IP address of the client as the host name. Note Check the S tate field to make sure that E nabled is selected. Enabled is the defa ult. 4. Enter a client identification in t he Client ID te xt box or enter the MAC address of the client in the Client MAC Address text box. 5. Enter the IP address you want to assign the client in the IP Address text box. 6. (Optional) Enter the T rivial File Tr ansfer Pr otocol (TFTP) server clients will use in the TFTP text box.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 151 7. (Optional) Enter the file name where diskless clie nts will find the boot file in the F ile Name text box. 8. (Optional) Enter a path for clients to get add itional configuration optio ns in the Extensions Path text box. Note Y ou must configure the TFTP option to us e the Extension Path option since client s will use TFTP to tr ansfer the configuration options fro m the server . 9. (Optional) Enter the root path where diskless clients mount a network file system (NFS) in the Root Filename text box. 10. Enter the IP address of the default router clients will use in the Router text box. 11 . (Optional) Enter the domain name yo u want clients to use in the Domain text box. 12. (Optional) Enter the time offset for clients in the T ime Offset text box. 13. (Optional) Enter the IP address or the name of the swap server diskless clients will use in the Swap Server text box. 14. Enter the Domain Name System (DNS) server c lients will use to resolve domain names in the DNS Servers text box. 15. Enter the Network Time Protocol (NTP) servers c lients will use in the NTP Servers text box. Enter the servers you want cli ents to use in the order of preference separated by commas. 16. Enter the Simple Mail Transfer Protocol (SMTP) servers, separated by commas, available to clients in the SMTP Servers text box. 17. If yo u configure NetBIOS, enter the W indows Internet Naming Servers (WINS), separated by commas, available to clients in the WINS text box. 18. If yo u configure NetBIOS, enter the Datagram Distribution (DD) servers, separated by commas, available to clients in the DD Servers te xt box. 19. If you configure NetBIOS, enter the node type th at the client will identify itself as in the Node T ype text b ox. 20. If yo u configure NetBIOS, enter the scope for the client in the Scope text box. 21. Click Apply . 22. Click Save to make your changes permanent. Creating DHCP Client T emplates This procedure describes how to cr eate a template for subnet and fixed-ip entries. After creating a template, you will have the ability to configure server and clients quickly and with fewer errors
3 152 Nokia Network Voyager for IPSO 4.0 Refe rence Guide because you will only have to ente r IP address information when you configure subnets or fixed- ip entries. 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the T emplate for adding new client entries link. 3. (Optional) Enter the T rivial File Tr ansfer Pr otocol (TFTP) server clients will use in the TFTP text box. 4. (Optional) Enter a path for clients to get add itional configuration options in the Extensions Path text box. Note Y ou must configure the TFTP option to us e the Extension Path option sinc e clients will use TFTP to tr ansfer the configuration options fro m the server . 5. (Optional) Enter the root path where diskless clients mount a network file system (NFS) in the Root Filename text box. 6. (Optional) Enter the file name where diskless clie nts will find the boot file in the File Name text box. 7. (Optional) Enter the domain n ame you want clients to use in the Domain text box. 8. (Optional) Enter the time of fset for clients in the T ime Of fset text box. 9. (Optional) Enter the IP address or t he name of the swap server diskless clients will use in the Swap Server text box. 10. Enter the Domain Name Servers (DNS) clients will use to resolve domain names in the DNS Servers text box. 11 . Enter the Network T ime Protocol (NTP) servers c lients will use in the NTP Servers text box. Enter the servers you want clients to use in the order of preference separated by commas. 12. Enter the Simple Mail T ransfer Protocol (SMTP) servers avai la ble to clients, separated by commas, in the SMTP Servers text box. If you configure NetBIOS, enter the W indows Internet Naming Servers (WINS) , separated by commas, availa ble to clients in the WINS text box. 13. If yo u configure NetBIOS, enter the Datagram Distribution (DD) serv ers, separated by commas, available to clients in the DD Servers text box. 14. If you configure NetBIOS, enter the node type th at the client will identify itself as in the Node T ype text box. 15. If yo u configure NetBIOS, enter the scope for the client in the Scope text box. 16. Click Apply . 17. Click Save to make your changes perman en t.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 153 Configuring Dynamic Domain Name System Service DDNS gives you the ability to co nfigure your DHCP server to automatically update DNS servers on your network. T o configure Dynamic Domain Name System (DDNS) 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the DDNS Configuration link. 3. Check that enable is selected. 4. Select a style in the Update Style box. 5. Enter a key name in the Key Name text box an d click the enable butto n next to the name. 6. Enter the secret key to be ma tched by the DNS server in the Ke y Secret text box. 7. Click Apply . 8. Click Save to make your changes permanent. T o add more keys, complete steps 6 through 9 for each new key . Configuring Dynamic Domain Name System Zones This procedure describes how to configure Dy namic Domain Name System (DDN S) zones. Note Before you can configure DDNS zones, you must have created DDNS keys. See “ Configuring Dynamic Domain Name System Servic e .” 1. Click DHCP under Configuration > Syst em Configuration in the tree view . 2. Click the DDNS Configuration link. 3. Enter the zone identifier in the Zone text box. 4. Check that enable is selected next to the Zone text box. 5. Select a key to associate with the zone in the Key drop-down box. 6. Enter the IP address of the primary DNS server in the Primary text box. 7. (Optional) Enter the IP address of the secon dary DNS server in the Secondary text box. 8. Click Apply . 9. Click Save to make your changes permanent. T o add more zones, complete steps 4 through 9 for each new zone.
3 154 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring the Domain Name Service IPSO uses the Domain Name Service (DNS) to tran slate host names into IP addresses. T o enable DNS lookups, you must specify the primary DNS se rver for your system; you can also specify secondary and tertiary DNS servers. When resolvin g hostnames, the system consults the primary name server first, followed by th e secondary and tert iary name se rvers if a failure or time-out occurs. T o configure DNS 1. Click DNS under Configuration > System Configuration in the tree v iew . 2. Click the DNS link in the Sy stem Configuration section. 3. Enter the new domain na me in the Domain name text box. 4. Enter the IP address of the primary DNS in th e Primary name server box; then click Apply . 5. (Optional) Enter the IP address of the secon dary DNS in the Secondary name server box; then click Apply . 6. (Optional) Enter the IP address of the tertiary DNS in the T e rtiary name server box; then click Apply . 7. Click Save to make your changes pe rmanent. Configuring Disk Mirroring The Nokia disk mirroring feature (RAID Level 1) protects against downtime in the event of a hard-disk drive fail ure in your appliance (for platforms that support t he feature). Y ou must have a second hard disk drive installed on your appliance. Disk mirroring gives you the ability to configure a mirror set composed of a source hard disk drive and a mirror hard di sk drive that uses Network V oyager . The hard disk drive in which you installed IPSO is your source hard disk drive. When you configure a mirror set, and the hard disk drives are synchronized (source hard disk drive is fully copied to the mirror hard disk drive), all new data written to yo ur source hard disk drive is also written to your mirror hard disk drive. If your source ha rd disk drive fails , your mirror ha rd disk drive automatically replaces your sourc e hard disk drive without interru pting service on your appliance. The source and mirror h ard disk drives can be warm swapped on appliances other tha n IP50 0 Series appliances, which means, you can replace a failed hard disk drive without shutting down your applia nce. In addition to being able to configure a mirror set, you can monitor the status of a mirror set, synchronization time, and system log entries. T o create a mirror set 1. Click Disk Mirroring under Co nfiguration > System Configuration in the tree view . 2. Select the Create check box in the Create Mirror Set table.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 155 Note The source hard disk drive and the mirror ha rd disk drive should have identical geometries. Y ou can view hard-disk drive geometry in the Drivers Information t ab le. 3. Click Apply . T ext at the top of the Network V oyager win dow with a message indicates a mirror set was created, numbers indicates which hard disk drive is the source and which hard disk drive is the mirror , and that mirror sync hronization is in progress. Note The synchr onization perc ent value in the Mirro r Set table indicates the percen tage of synchronization zones that are cop ied from the sour ce disk to the mirror disk. A sync zone is equivalent to contiguous disk secto rs. When all synchronization zones are copied to the mirror disk, the synchronization percent value reads 100 percent and your platform is protected from a disk failure. Synchronization time is approximately 20-30 min utes for a 20 GB disk. No mirror set is created if the synchronization operatio n is not successful. T o delete a mirror set 1. Click Disk Mirroring under Con figuration > System Configuration in the tree view . 2. Select the Delete check box in the Mirror Sets table. 3. Click Apply . Note Y ou can only delete a mirror set that is 100-percent synchronized. Using an Optional Disk (F lash-Based Systems Only) Y ou can add flash memory PC card in flash-base d (diskless) systems so that you can store log files locally . When you install a PC card (optional disk) for loggin g, you must reboot the syst em to make it available for use. When you insert a PC card into a flash-based plat form and select the card as an optional disk, any existing data on the card is erased. If you remo ve a PC card that contains log files and want to permanently store the data, insert the card into a PC or other computer and save the data to that system before reinserting the car d into a Nokia flash-based platform. Note Use only PC ca rd flash memo ry that is su pported for y our platform. If you attem pt to use P C card flash memory that has insufficient ca pacity , it is not recognized by the system.
3 156 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o install and configure PC card flash memory 1. Insert the card into one of the PC ca rd slots in the front of the system. Make sure that the card is fully inserted. 2. Click Optional Disk under Config uration >System Configuration. Network V oyager displays in formation about the card you in serted. If you do not see this information, verify that the card has at lea st one gigabyte of storage and is fully inserted into the slot. 3. Select the card in the Choose column. 4. W ait until you see a messag e indicating that you should reboot the system. There is a short delay before the message appears. 5. When the message appears, click the link Reboot, Shutdo wn System. 6. Reboot the system. T o configure the system to store log files on the PC card 1. Click Optional Disk under Config uration >System Configuration. 2. Next to Logging to Optional Disk, click On. 3. Click Apply . If you want to stop using PC card flash memory , follow the se steps: T o remove an optional disk 1. Click Optional Disk under Config uration >System Configuration. 2. Click Optional Disk. 3. Deactivate the card by clicki ng in the Unselect column. 4. W ait until you see a messag e indicating that you should reboot the system. There is a short delay before the message appears. 5. When the message appears, click the link Reboot, Shutdo wn System. 6. Reboot the system. Mail Relay Email relay allows you to send email from the firewall. Y ou can send email interactively or from a script. The email is relayed to a mail hub that then sends th e email to the final recipient. Mail relay is used as an alerting mechanism when a Check Point FireW all-1 ru le is triggered. It is also used to email the system administrator the results of cron jobs. IPSO supports the followi ng mail relay features:  Presence of a mail client or Mail User A gent (MUA ) that can be used interactively or from a script
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 157  Presence of a sendmail-like replacement that relays mail to a mail hub by using SMTP  Ability to specify the defaul t recipient on the mail hub IPSO does not support the fo llowing mail relay features:  Support for incoming email  Support for mail transfer protocols o ther than outbound SMTP .  Ability to telnet to port 25  Support for email accounts ot her than admin or monitor System Failure Notification This procedure describes how to set your system to send email to one or more people when a system failure occurs. Separate multiple email addres ses by spaces. T o configure failure notification 1. Click System Failure Notification under Conf iguration > System Configuration in the tree view . 2. Click On next to Enable Failure Notification. 3. Click Apply . 4. Enter the email address of the people you want to notify in the event of a system failure, and then click Apply . Examples of a system failure include crashing daemons (snmpd, ipsrd, ifm, xpand) and a system reboot that re sults from a fatal error . In a system failure notification, the following information appears:  System information  Image information  Crash information  Crash trace 5. T o make your changes permanent, click Save. Configuring Mail Relay T o configure mail relay for your firewall 1. Click Mail Relay under Configuration > System Configuration in the tree view . 2. Enter either the IP address or hostname of the email server that relays outgoing email in the Mail Server text box. 3. Enter the username on the mail server to which mail addressed to admin or moni tor is sent in the Remote User text box; then click Apply . 4. Click Save to make your changes permanent.
3 158 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Sending Mail T o send mail from the firewall 1. Log in to the firewall as either the admin or monitor user . 2. At the prompt, type the mail command, follo wed by a space, and the username of the recipient: mail username@hostname 3. T ype the subject of your message at the subject prompt; then press Enter . 4. T ype your message; then press Enter . 5. When you finish typ ing your message, type a period on an empty line; then press Enter . Y our message is sent. Setting the System T ime Synchronized clock times are critical for a variety of purposes, including distributed applications that require time synchronizatio n, analyzing event logs from diff erent devices, ensuring cron jobs execute at the correct time, and ensuring that applications that use system time t o validate certificates find the correct time. For example, in the case of audit logs, the time stamps on different network devices should be accurate to within about a second of each other to correlate events across multiple devices. Y ou can view the current system time at the top of any Network V oyager page. Y ou can set the system time using any of the following methods:  Set the date and time manually .  Access a time server once.  Configure Network Time Protocol to ac cess time servers for continuing clock synchronization. For more information, see “N etwork Time Protocol (NTP)” on page 475. Set the system time either manually or by usin g a time server when you initially configure the system. Y ou might need to set it again when you bring the system up after it has been down for a period of time. Use this procedure al so to specify the local time zone. Note When you reset the system time, the routing t abl e is reset and existing co nnections might be terminated . If you have not enabled NTP , you can se t the system time once fro m a time server . For information on confi guring NTP to upda te the time on a regular basis, see “Network Time Protocol (NTP)” on page 475.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 159 T o set system time once 1. Click T ime under Configuration > System Configuration in the tree view . 2. Select the appropriate time zone in the T ime Zone list box. By default, the time zone is set to GMT . 3. Either set the time manually or specify a time server: a. T o set the date and time manually , enter th e time and date units to change. Y ou do not need to fill in all fields; blank fields defau lt to their existing values . Specify hours in 24- hour format. b. T o set the time using a time server , enter the name or IP address of the time server in the NTP T ime Server text box. Note If NTP is enabled, this option does not appear . 4. Click Apply . 5. Click Save. Configuring Host Addresses Click Host Address under Config uration > Syst em Configura tion to perform any of the following tasks:  V iew the entries in the hosts table .  Add an entry to the list of hosts.  Modify the IP add ress of a host.  Delete a host entry . Y ou should add host addresses fo r systems that will communicat e frequently with the system you are config uring. T o add a static host entry 1. Click Host Address under Config uration > Sy st em Configuration in the tree view . 2. Enter the new hostna me in the Add new hostname text b ox. 3. Click Apply . The new hostname appears in the list of Current Host Address Assignments. 4. Enter the IP address of the new host in the IP address text box. 5. Click Apply . 6. Click Save to make your changes permanent.
3 160 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o delete a static hos t 1. Click Host Address under Config uration > System Configuration in the tree view . 2. Select Off next to the host to delete. 3. Click Apply . 4. Click Save to make your changes pe rmanent. Configuring System Logging System logging is configured differently on flash-bas ed (d iskless) and disk-based systems. Configuring Logging on Disk-Based Systems This section describes how to configure system logging on disk-based appliances. Y ou can configure system logging to send logg ing messages to a remote device or to accept unfiltered system log me ssages from remote devices. Caution Do not configure two devices to send system logging messages to each other either directly or indirectly . Doing so creates a fo rwarding loop, which causes an y system log message to be repeated inde finitely on both devic es. Accepting Log Message s Y ou can also enable your system to accept unf ilte red system log messag es from remote devices. If you enable logging from remote systems, network system log packets are tagged with the hostname of the sendin g devi ce an d logged as if the messages were gene rated locally . If logging from remote systems is disabled, netw ork system log packets are ignored. T o set the system to accept un filtered syslog messag es from a remote system, use the following procedure. T o set the system to accept syslog messages from a remote system 1. Click System Logging under Configuration > System Configuration in the tree view . 2. Select Y es to accept syslog messages. 3. Click Apply . 4. Click Save to make your changes pe rmanent. Logging to a Remote System Any log messages sent to re mote devices are also stored in the local log directories. Y ou can use this feature, for example, to send log messages to a device that is configured for more secure
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 161 storage or to reduce the ri sk of losing lo g in formation if y ou run out of disk space on your IPSO appliance. Y ou might also choose to send all of the logs from multipl e computers to one centralized log server , possibly on e that is configured for high availability . Y ou can select the severity levels of messages to send to remote devices. T o configure your system to send syslog m essages to a remote syst em, use the following procedure. T o send syslog messages to a remote system 1. Click System Logging under Configuration > System Configuration in the tree view . 2. Enter the IP address of the host machine to which you want to send syslog messages. 3. Click Apply . 4. Click the Added Security Level drop down wind ow and select at least one severity level. Specifying a particular severity level means that all messages at least that severe are sent to the associated remote host. Y ou can choose Em er gency , Alert, Critical, Error , W arning, Notice, Info, Debug, or All. If you specify more than one severity level, all messa ges that are least as severe as the lowest severity leve l you select are sent to the remote host. Note Y ou must select at least one severity level for this option to func tion. The system will not send syslog messages to the remote host if you d o not configure at least o ne severity level. 5. Click Apply . The name of each severity level appears in Log at or above severity field. 6. T o disable any of the severity levels, click No ne xt to the name of the severity level you want to delete. 7. Click Apply . 8. Click Save to make your changes permanent. Configuring Logging on Flash-Based Systems On flash-based (diskless) system s, log files do not persist acro ss system reboots unless the y are stored on an appropriate device. Y ou can store log files on either or both of the following:  Remote log servers (primary and secondary) If you decide to use remote systems, you mu st configure them to store the log files.  PC card flash memory in the flash-based system If you decide to use PC card flash memory , you must install and configure it before you set up the system logging. (For infor mation about installing a flash memory card, see “T o install and configure PC card flas h memory” on page 156 .)
3 162 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Caution When you inse rt a PC card into a flash- based applianc e and select th e card as a n optional disk, any existing dat a on the card is erased. If you remove a PC card that contains log files and wa nt to permanently store the data, insert the card into a PC or other computer and save the dat a to that system before reinserting the ca rd into a Nokia flash-based (diskless) applia nce. Log messages are temporarily s tored in system me mory and are stored to remote log servers and/ or PC card flash memory according to a schedule that yo u can configure. Log messages are stored in the following files:  /tmp/tmessages (in memory)—St ores most log messages.  /var/log/messages—Stores most log messa ges wh en PC card flash memory is installed. Note Messages stored in http_error _log or httpd_ access_ log on oth er p latfo rms ar e stor ed in the messages files on flash-based systems.  /var/log/wtmp—Stores messages about shell lo gins and logouts. When PC card flash memory is installed, /var/log/wtmp is automatically stored on the drive. Configuring Logging to Remote Log Servers If you decide to use remote systems, you must conf igure them to store the log files. T o configure your flash-based system to send syslog messages to remote log servers, us e the following procedure. T o configure a flash-based system to use a remote log server 1. Click System Logging under Configuration > System Configuration in the tree view . 2. Next to Network Logging, click On. 3. Enter the IP address of the primary remote log server . Make sure that the flash-based system has connectivity to the remote server . 4. If you want to use a seconda ry remote log server , enter its IP address. If the primary log server is unreachable for any reason, the system sends its log files to the secondary log server . Make sure that the syst em has connectivity to the secondary server . If the primary log server is unreachable, there is a several minute dela y be fore log messages are sent to the secondary server . The messages ar e stored in a buffer during this time and are sent when connectivity is established with the secondary server . 5. Set the threshold level for saving log messages to the remote server . Flash-based systems can hold 512 log messag es in a specific memory buffer . Use this configuration option to contro l when the messages are saved to the remote server and the buffer is cleared. For example, assume that th e threshold percentage is 50 percent. When
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 163 there are 256 messages in the buffer , the messag es are transferred to the remote serve r and the buf fer is cleared. 6. Use the Flush Frequency option as an ad ditional control for saving messages. When the Flush Frequency interval expires, log messages are transferred to the remote server and the log buffer is cl eared regard less of how many messages a re in the buf fer . 7. Click Apply . 8. Click Save to make your changes permanent. Configuring Logging to an Optional Disk If PC card flash memory is inst alled and enabled, you ca n config ure the system to save log files on it by selecting On for Network Logging. If yo u enable local logging, log messages are saved in /var/log/message and /var/log/wtmp on the memo ry card. The message s are sa ved to the card according to the setting of the Flush Frequency option. Y ou can save log files to a remote log server and PC card flash memory simultaneously . If the flash memory is full, the sy stem displays a console message to that effect and stops saving log messages to the card. Messages that have been previously saved on the card are not affected. If you have configured the system to send messages to remote log server , it continues to do so. Note If you use SNMP , the system sends SNMP trap s wh en the flash memor y file system is full 90 percent and 95 percent full to al ert you o f the impending issue. T o delete log files stored in PC card flash me mory so that new messages can be stored, you can use the rm command to delete files in /var/log/. Configuring Audit Logs Y ou configure the audit logs in the same way for both disk-b ased and flash-b ased systems. Use this feature to set the system to log all Apply and Save actions to the Ne twork V oyager pages. If you enable this feature, each time the Apply or Save button is pressed, the log records the name of the user , the name o f the Network V o yager page, and the name of the button that was pressed. The log records th ese actions whether or not the operation succeede d. T o view the log, click the Mon itor button on th e Network V oyager home page, and then click the System Message Log link to vi ew system message s. For more information on viewing the system message log, see “Monitoring System Logs” on page 484. Note For Network V oyager configuration p ages that do not inclu de Ap ply and Sa ve button s, such as image.tcl, the log reco rds the relevant action, su ch as clicking Reboot.
3 164 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o set logging of all Network V oyager Apply and Save actions 1. Click System Logging under Configuration > System Configuration in the tree view . 2. In the V oyager Audit Log field, select Enabled or Disabled. 3. Click Apply . 4. Click Save to make your change perman en t. The V oyager Audit Log feature does not record any operations perform ed using the command- line interface (CLI). T o log co nfiguration changes made using either Network V oyager and the CLI, enable the system configuration audit log. Configure the system configura tion audit log to record transi ent and permanent configuration changes. Y ou can view the syslog messa ges to determine whether authorized users only are making configuration changes to the system. T o set the system configuration audit log 1. Click System Logging under Configuration > System Configuration in the tree view . 2. In the System Configuration Audit Log field, select from the following:  Logging disabled—The system writes minima l messages to the syste m log that a configuration change was made , including th e name of the host fro m which the change was made, a nd the name of th e user who made the change.  Logging of transient changes—The system wr ite s messages to the system log each time a user applies a configuration change to the running system. T ransient changes are those that apply on ly to the currently running sy stem. T ransient changes are equiva lent to clicking the Apply button only in Network V oyager .  Logging of transient and permanent changes— The system writes me ssages to the system log each time a user applies a configuration change to the running system or changes the configuration files. Permanent changes are those that remain active after the system is rebooted. These changes are equivalent to c licking the Save button in Network V oyager after you apply a configuration chan ge. 3. Click Apply . 4. If you are using a disk-based system, a Destina tion Log Filename text box appears af ter you enable the system configuratio n auditlog. The box contains th e name of the file to which syslog messages for this feature are sent. The default is /var/log/messa ges. T o change the file, enter the new file name in th e Destination Log Filename text box. On flash-based systems, you cannot save the me ssages to another file. Note The system configuration audit log setting is not saved in the config uration file. Y ou must reset it after re booting to enable logging again. Y ou must enter a destination file name to view log messages in the Management Activity Log. The default destination file logs messages in the standard system log file. T o acc ess the Management Activity Log page, click Monit or on th e Home pag e in Network V oyager and then
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 165 click the Management Activity Log link in the System Logs section. For more information, see “Monitoring System Logs.” Remote Core Dump Server on Flash-Based Systems Application co re files are sto red in memory in the directory /var/t mp/. When the f ile system is 95% filled, flash-based (d iskless) systems delete older core files to make room for newer ones. Y ou can configure flash-based systems to transfer th e core files to a remote server so that older files are retained. After application core files are transferred to a remote server , they are deleted from memory . The core files are transferred on a predetermined sc hedule that is not configurable by users. Note This feature does not apply to Nokia IPSO kern el core files. T o transfer these files to a remote system, you must use the command savecore -r ftp:// user:passwd@host-ip-address / directory / Flash-based systems store kernel core files on the internal co mpact flash memory card and can store a maximum of two at a time. If nece ssary , older core files are deleted to make room for newer files. If a kernel core file is cr eated, this is indic ated in the log file the next time the system boots. T o configure your flash-based system to transfer application core files to a remote server , use the following procedure. Y o u must also config ure the remote system (FTP or TFTP server) appropriat ely . T o configure a flash-based system to transfer application core files to a remote server 1. Click Remote Core Dump Server under Conf iguration > System Configuration in the tree view . 2. Enter the IP address of the remote server to which the application core files will be transferred. 3. Select whether to use FTP or TFTP for the transfer protocol. Caution The TFTP option does not wo rk with TFTP servers running on many Unix-based operating systems. Nokia recomme nds th at you use FTP unless you are sure that your TFTP serve r accepts writes to files that do not alre ady exist on the server . If you choose FTP , make sure that your server accepts an onymous FTP logins. Y ou cannot use non-anonymous FTP logins to tr ansfer application core files. 4. Indicate where the core files should be stored on the remote server by entering the appropriate path and directory .
3 166 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. Click Apply . 6. Click Save to make your changes pe rmanent. Changing the Hostname Y ou set the hostname during in itial configuration. T o identify the hostname (system name) of your security platform, click Hos tname under Co nfiguration > System Configuration in the tree view . The hostname is also displayed in each page header . Note Host address assignments mu st match an IP address. Y ou can change the hostname at any time using the following procedure. T o change the hostname 1. Click Hostname under Configuration > Sy stem Configuration in the tree view . 2. Enter the new hostname . 3. Click Apply . 4. Click Save to make your changes pe rmanent. Managing Configuration Set s Y ou can save the system state that is currently running to a new configuration database fi le. Y ou can also create a new configuration database file using factory de faults that is known to work correctly . T o save the active configuration as a new conf iguration set, use the following procedure. The active configuration might be dif ferent from that of the current config uration file if you have applied changes but not saved them. T o save the current configuration into a new configuration dat abase file 1. Click Configuration Sets unde r Configuration > System Conf iguration in the tree view . 2. Enter the name of the new configuration file in the Save current state to new configuration database field. 3. Click Apply . The current configuration is saved in the new file, and the file appear s in the list of database files on this page. Subsequent co nfiguratio n changes are saved in the new file. T o create a new configuration database file that contains only the factory default configuration settings, use the following procedure.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 167 T o create a factory default configuration file 1. Click Configuration Sets unde r Configuration > System Conf iguration in the tree view . 2. Enter a name for the new file in t he Create a New Factory Default Configuratio n field. 3. Click Apply . The new file appears in the list of database fil es on this page, but it is not selected as the current configuration da tabase. The factory default configuration has not been loaded. Wa r n i n g If you load this configuration set, all system co nfigurations are delete d from the system. Y ou cannot configure the system through Networ k V oyager until you conf igure an IP address through the system console. T o load a different configuration file, use the following procedur e. T o switch a currently active dat abase 1. Click Configuration Sets unde r Configuration > System Conf iguration in the tree view . 2. Select from the available configur ation database files in the list. 3. Click Apply . 4. T o make your changes permanent, click Save. T o delete unwanted configuration databa se files 1. Click Configuration Sets unde r Configuration > System Conf iguration in the tree view . 2. Click the Delete Configuration Databases link. 3. Select Delete for each database file you want to delete. 4. Click Apply . 5. Click Up to return to the Configuration Database Management page. Scheduling Jobs Y ou can use Network V oyager to access the cronta b file and schedule regular jobs. The cron daemon executes jobs at dates and times you specify throug h the following proc edure. T o schedule jobs 1. Click Job Scheduler under Configuration > System Configuration in the tree view . 2. Enter a name for the job you want the cron daem on to execute in the Job Name text box. Use alphanumeric characters only , and do not include spaces. 3. Enter the name of the command you want th e cron daemon to execute in the Command name text box . The command can be any UNIX co mmand.
3 168 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. Select the T imezone under which you want t o schedule the job, either Local or Universal, from the drop-down list. 5. Select the frequency (Daily , W eekly , or Monthl y) with which you want the jo b to execute from the Repeat drop -down list. 6. Click Apply . 7. Under Execution Detail, specify the time the job will execute. 8. T o receive mail regarding your scheduled jobs , enter your email address in the Email Address text box. Note Click Mail Relay to verify that a mail serv er is configured. 9. Click Apply . If your configuration is successful, the job appe ars in the Scheduled Jobs table . T o make your changes permanent, click Save. 10. Click Save to make your changes perman en t. T o delete scheduled jobs 1. Click Job Scheduler under Configuration > System Configuration in the tree view . 2. In the Scheduled Jobs table, sel ect Delete next to the name of each job you want to delete. 3. Click Apply . 4. Click Save to make your changes pe rmanent. Backing Up and Restoring Files Y ou can perform manual backups of files or yo u can configure your system to run regularly scheduled backups, as described in “Creating Backup Files,” below . Y ou can also use Nokia Network V oyager to manage your backup files, in cluding the following tasks:  Restore from locally stored files. See “T o restore files” on page 172.  T ransfer backup files to, and restore them from, a remote server . See “Transferring Backup Files” on page 170.  Delete backup files that are stored on the local system. See “T o delete local backup files” on page 169 . Y ou can also view a list of backup files that ar e stored locally by clicking IPSO Configuration > Configuration Summary .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 169 Creating Backup Files Y ou can create a backup file manually at any time (see “T o create a backup file manually ,” below), or configure the system to ru n scheduled backups automatically (see “T o configure scheduled backups” on page 170). By default, the backup fi le contains everything in the following directories:  configuration (/config )  cron (/var/cron)  etc (/var/etc)  IPSec files (/var/etc/IPSec) Note Export versions of Nokia IPSO do not includ e IPSec files. Y ou can also choose to include th e following in your backup file:  User home directories (s tored in /var/emhome)  Log files (stored in /var/logs) T o create a backup file manually 1. Click Backup and Restore under Configuration > System Configurat ion in the tree view . 2. Enter a file name for y our backup file in the Backup File Name text box. If you do not enter a nam e, the backup file is not created. 3. Select any additional directories to include in the backup file: a. T o include the home directories of all active users in the backup file, check the Backup Home Directories check box. b. T o include log files in th e backup file, check the Backup Log Files chec k box. c. T o include application pa cka g e files in the backup file, check the check box for each package to include in the backup file. Only installed packages that support backup are listed. 4. Click Apply . 5. Click Save to make your changes permanent. T o delete local backup files 1. Click Backup and Restore under Configuration > System Configurat ion in the tree view . 2. In the Delete Backup Files section, check the Delete check box next to the name of each backup file to delete. 3. Click Submit. The entry for the bac kup file disappears.
3 170 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure scheduled backups 1. Click Backup and Restore under Configuratio n > System Configuration in the tree view . 2. In the Scheduled Backup field, click the Freq uency drop-down list and select Daily , W eekly , or Monthly to configure ho w often to perform a regular backup . Additional text boxes appear in the Configure Scheduled Backup section. 3. Select times and dates for the schedul ed backup from th e dro p-down lists.  For a daily backup, select the hour and minute.  For a weekly backup, select the da y of the week, hour , and minute.  For a monthly backup, select the date of the month, hour , and minute. If you select a date for monthly backups th at does not oc cur every month of the year , such as 31, those months are omitted from the backup schedule. 4. Enter a name for your backup file in the Backup File Name text box. If you do not enter a name, the backup file is not created. 5. Select any additional directories to include in the backup file: a. T o include the home directories of all active users in the backup file, check the Backup Home Directories check box. b. T o include your log files in the backup file, check the Backup Log File s check box. c. T o include package files in your backup file , select the check box next to the name of each package to include in the backup file. Only installed packages that support backup are listed. 6. Click Apply . 7. Click Save to make your changes pe rmanent. T o cancel a regularly scheduled backup 1. Click Backup and Restore under Configuratio n > System Configuration in the tree view . 2. In the Frequency dro p-down list und er Scheduled Backup, select None. 3. Click Submit. T ransferring Backup Files Y ou can transfer backup files to a remote serve r or download them to the workstation from which you are running Network V oyager . When you transfer backup files to a remote server , they are removed from the system. Configuring Automatic T ransfers T o configure the system to automatically transfer backup files to a remote server on an hourly basis, use the following proce dure.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 171 T o configure automatic transfers of archive files to a remote server 1. Click Backup and Restore under Configuration > System Configurat ion in the tree view . 2. Under Automatic T ransfer of Archive File, select a file transfer protocol, either TFTP or FTP . If you choose FTP , make sure that your server accepts an onymous FTP logins. Y ou cannot use non-anonymous FTP logi ns to automatically transfer backup files. Caution The TFTP option does not wo rk with TFTP servers running on many Unix-based operating systems if there is not a file in th e target dire ctory on the remote serv er that has the same name as the backup file that is bein g transferred. Nokia recom mends that you use FTP unles s y ou are sure tha t yo ur TFTP serve r ac cepts writes to files that do not already exist on the server . 3. Enter the IP address of the remote server . 4. If you chose FTP as the transfer protocol, indicat e where the core files should be stored on the remote server by entering th e appropriate path and directory . 5. Click Apply . 6. Click Save to make your changes permanent. T ransferring Backup Files Manually T o transfer a archive file containing backup fil es manually to an FTP server using the following procedure. T o manually transfer archive files to a remote server 1. Click Backup and Restore under Configuration > System Configurat ion in the tree view . 2. Under the Manual T ransfer of Archiv e Files section, enter the following  IP address of the FTP server .  Directory in which to save the backup file.  Enter the name of the user accoun t for connecting to the FTP server .  Enter the name of the p assword to use when connecting to the FTP server . Y ou must change the password if you change the FTP server , FTP directory , or FTP user . Note The password is not stor ed in the database. Enter the p assword each time you want to transfer files to remote server even if you are using the same FTP server . 3. Select the file you want to transfer from eith er the Manual Backup File or Sche duled Backup File drop-down lists. 4. Click Save.
3 172 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Restoring Files from Locally S tored Backup Files T o restore files to the system, you must first create backup files as described in “Creating Backup Files” on page 169. Y ou can restore either from files stored locall y or from files stored on a remote machine. Caution Restoring from a backup file ov erwrites your existing files. T o restore files 1. V erify that the following prerequisites are me t:  Enough disk sp ace is available on your platform. Caution If you try to restore files an d you do not have enough disk space, you risk damaging t he operating system.  Y our system is running the same version of the operating system and the same packages as those of the backup files from which you restore files. Caution Using incompatible versions ca n result in problems with co nfigu ra tio n an d da ta files, which might, or might not, be immediately detect able. 2. Click Backup and Restore under Configuratio n > System Configuration in the tree view . 3. If the file you are restoring from is stored on the local appliance, go to the Restore from Local section. a. Select the name of the backup file from eith er the Manual Backup File or the Scheduled Backup File drop-down lists, depend ing on the type of file to restore. Manually backed-up files are in the /var/backup directory an d scheduled backup files are in the /var/backup/sched directory . The drop-do wn lists contain lists of all the files in these directories, but some of th e files might not be backup files. b. Proceed to step 5 . 4. If the file you want to restore is stored on a remote device, go to the Restore From Remote section of the page. a. Enter the following information:  IP address of the FTP server .  Directory in which to save the backup file.  Enter the name of the user accoun t for connecting to the FTP server .  Enter the name of the p assword to use when connecting to the FTP server .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 173 b. Click Apply . c. A list of available files in the directory you specify appears. Select the backup file s you want to restore. 5. Click Apply . Repeat the previous two steps for each file you want to restore. 6. Do not click Save. Ignore any Unsaved changes will be lost messages. 7. Click Reboot and wait for the system to reboot. Note Y ou must reboot your syst em a fter restoring from backup files. Managing Nokia IPSO Images An IPSO image is the operating sy s tem kernel and binary files that run the system. Y ou can store multiple versions of the IPSO image on your appliance. For information about in stalling images in a cluster environment, see “Upg rading Nokia IPSO Images for a Cluster” on page 176. For information about do wngrading to a previous version of IPSO, see “Downgrading Nokia IPSO Images” on page 176. Changing Current Image When the system boots, it reads the kernel file in the directory indicated by the curr ent pointer . T o identify the current imag e, you can either look on the Hom e pa ge or choose Configuration > System Configur ation > Images, click Mana ge Im ages and look in the State column. T o change the current im age, use the following procedure. T o select a new current image 1. Click Manage Images und er Configuration > Sy stem Configuration > Im ages in the tree view . 2. Select the radio button for the image you want to select as the new current image. 3. Click Reboot to activ ate the new image. The system will take a few minutes to reboot. Deleting Images When there are too many images on your system , the directory gets full and precludes you from logging in. T o prevent this problem, delete old im ages before you install a new image so that you do not have more than three or so images on your system.
3 174 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Flash-based systems can store a maximum of two Nokia IPSO images. T o delete an Nokia IPSO image 1. Click Manage Images under Configuration > Sy stem Configuration > Im ages in the tree view . 2. Click Delete IPSO Images. 3. Click the delete button next to the image you want to delete. 4. Click Apply . 5. T o make your changes permanent, click Save. Inst alling New Images When you upgrade the image, the system config uration and installed packages are retained. T o upgrade the image, you must first complete an in itial installation. For information about how to perform an initial inst allation and configuration of an image, see t he latest version of the IPSO Getting S tarted Guide and Release Notes , delivered with your appliance and available on the Nokia customer support site at https://support.nokia.com . Upgrade the IPSO image on your platform using Network V oyager using the following procedure. 1. Click Upgrade Images under Configuration > System Configuration > Images in the tree view . 2. Enter following information in the appro priate text boxes. a. URL or IP address of the FTP , HTTP , or file server on which the Nokia IPSO image i s installed. Note If you enter a URL, the system must be configured to use a valid DNS server . Y ou can use the DNS Configuration page to configure which DNS servers the system will use. Note If you enter the absolute path to an image on an FTP site, you must type a double slash ( // ) after the domain n ame . For example: ftp://test.acme.com//tmp/ipso.tgz If you enter a path that is relative to the ho m e dir ec to ry of the us er who se na m e an d password you en ter , use the standard URL forma t. For exam ple: ftp:// test.acme.com/tmp/ipso.tgz
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 175 b. (Optional) If the HTTP site on which the Nokia IPSO image is stored requires authentication, enter the HTTP realm to which authentication is needed. c. (Optional) If the server on which the Nokia IP SO image is stored requires authentication, enter the user name and password. 3. Specify whether to de-activate installed packages (such as VPN-1/FireW all-1 packages) after the system is rebo oted with the new image. 4. Click Apply . A message appears that tells you that the u pgrade process could take a long time if the network is slow . 5. Click Apply again. The system downloads the specified image file. 6. T o view the status of the download and insta llation process, click Che ck S tatus of Last New Image Installation Operation. 7. The following message at the bottom of the list of messages indicates that the download and installation process is complete : To install/upgrade your pack ages run /etc/newpkg after REBOOT 8. If you made configuration changes, click Save. 9. Y ou can either set your new image to be the current image fo r your platform (see “T o select a new current image” on page 173) or test the new imag e before you set it as the current image (see “T o test an image before activating it” on page 175 ) . T esting a New Image Y ou can test an IPSO image befo re you permanently activate it fo r your platform by performing a test boot. If you perform a test boo t of an im age, you can choose whethe r to commit the image used for the test boot or revert to the previous image. If you do not select either option, the system automatically reboots in five minutes using the previous image. T o test an image before activating it 1. Click Upgrade Images under Configuration > System Configuration > Images in the tree view . 2. Click Manage IPSO images (including RE BOOT and Next Boot Image Selection). 3. Select the radio button associated with the image you want to test. 4. Select one of the following op tions for rebooting the system:  T o reboot with the image, click Reboot.  T o test boot the new im ag e, click T est Boot.
3 176 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note When you click T est Boot, the syst em tests th e new image for five mi nutes. If you let the five-minute test period ex pire without co mmitting to th e new image, t he system automatically reboot s and reverts to the previous image . A new page appears, and you see a message telling you that the system will be rebooted. Do not click anything on this page. 5. If you did not choose the test boot option, th e upgrade is complete after the appliance reboots. Y ou do not need to do anything el se. If performed a test boot a nd want the system to continue usin g the new image, you have five minutes after the system restarts to select Commit T estboot. If you do not, the system automatically reboots the prev ious image in five m inutes. Upgrading Nokia IPSO Images for a Cluster Y ou can use Cl uster V oyager to upgrade the Noki a I PSO image on all the cluster nodes. After you see that the ne w image is successfully installed on all of the nodes, you need to reboot them so that they will run the ne w image. For more informatio n about Cluster V oyager , see “Managing a Cluster” on page 231 in the section on configurin g traffic management. Rebooting a Cluster When you cli ck Reboot, Shut Down System on the main configuration page in Cluster V oya ger , you see the Cluster T raffic Safe Reboot link. If you cl ick this link, the cluste r nodes are rebooted in a staggered manner . The process is managed so that at least one node is always operational. For example, if you reboot a two-node cluster , one node restarts first. The second node w aits for the first node to restart successfully and rejoin the cluster before it reboots . If the first node does not successfully rejoin the cluster , the firs t node does not reboot. Downgrading Nokia IPSO Images When you do wng rad e a n IPSO imag e, the sys tem b ehave s di f ferently de pen ding o n wh ethe r the version you are do w ng rading to was pr eviously installed on the appliance:  When you revert to a previously installed IPSO version, the system accesses and uses the network connectivity information config ured for that version.  When you downgrade to an earlier IPSO versio n that has never been installed on your appliance, the system carries over the co nfiguration information related to basic connectivity . This functionality allows you to perform this type of downgrade over a network connection. Y ou can use this met hod to downgrade to IPSO 3.6 and later .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 177 Only when you are downgrad ing to a version that was never on you r appliance is the connectivity information from the already installed IPSO version carried over to the less recent version that you are installin g. The configuration informa tion carried over includes:  Interface configurations  admin password (accounts for any users that have been added are not carried over)  SNMP user information  Hostname  Default gateway  DHCP  SSH  Modem and TTY Other configuration information is not carried over and all other parameters are set to factory defaults. When you downgrade to a previously-insta lled IPSO version, no information is carried over—all configurations, including connectivity information from the previous version is retained and used. When you install a new image for a previous ve rsion that was never on yo ur appliance, the following message is displayed: WARNING: Configuration set for <target release> does not exist . Will attempt to create a new configuratio n set with connectivity only information. All other configuration changes will be lost. Y ou are also instructed to perform a test boot, just as you would with any other fresh install. Note If you downgrade to IPSO 3.6 and it was not prev iously inst alled on the appliance, users with RSA authorization might lose connectivity . This is because the SSH configuration for IPSO 3.6 might not be fully compatible with later IPSO ver sion, and the RSA keys might not be carried over . Configuring Monitor Report s For monitoring purposes, yo u can configure the system to generate re ports on the following types of ev ents:  Rate Shaping Bandwidth  Interface Throughput  Interface Link State  CPU Utilization  Memory Utilization For more information about these reports, see “Generating Monitor Reports” on page 482
3 178 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Y ou can configure the opti ons for monitor reports according to your networking and reporting requirements. Ta b l e 7 shows the parameters that you can configure for monitor reports. T o configure these parameters, click Configure Monitor Reports under Configu ration > System Configuration in the tree view . Managing Packages Packages are software bundles that are ready to install on an IPSO system. Each package is installed as a subdirectory of the /opt directory . Y ou can use Network V oyager to easily install, upgrade, and remove packages. Inst alling and Enabling Packages Y ou can use Network V oyager to enable packages (make them active), to disable and delete packages, and to delete files th at you no lo nger need to ma intain on your local system. Restrictions for Fl ash-Based Platforms Y ou can install a maximum of two v ersions of Check Poi nt’ s VPN-1 Pro/Express on flash-based systems. If your platform runs Check Point NGX, the on ly supported Check Poin t packag es are: T able 7 Monitor Report Parameters Parameter Description Collection Interval Specifies, in seconds, how often the d ata is collected. Range: 60 - 2100000. Default: 60 On/Off Y ou can enable or disab le each data collection event. By d efault, all events are enabled. For the rate-shaping band width report, you can enable packets delayed and bytes delayed separately . Likewise, for the interface throughpu t report, you can enable one or more of packet throughput, byte throughput, broadcast packet s, and multicast packets. Data A vailable for Hours Specifies how many hours worth of collected dat a are stored on the system. Data that is older than the spec ified number of hours is deleted. This option controls how much data is available when you use the Detailed Search option on any of the report pages. It does not affect how much d ata is available when you use the Hourly , We ekly , Daily , or Monthly options on these pages. Range: 24 - 167 hours Default: 24 hours Note : On flash-based systems, Nokia reco mmends that you se t this option to 24 hours (the d efault value) to avoid exhausting the availa ble storage space.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 179  CheckPoint VPN-1 Pro/Express NGX R60  CheckPoint CPinfo If your platform runs NG with Application Inte lligence (R55) for IPSO 3.8, the only packages you can install are:  Check Point VPN-1 NG with Application Intelligence (R55) for IPSO 3.8 (or later)  Check Point SVN Foundation NG with Appli cation Intelligence (R 55) for IPSO 3.8  Check Point Policy Server NG with Applic ation Intelligence (R55) for IPSO 3.8  CheckPoint CPinfo NG with Applicatio n Intelligence (R55) for IPSO 3.8 T o install a p ackage 1. Click Manage Packa ges under Configuration > System Configurat ion > Packages in the tree view . 2. Click FTP and Install Packages. 3. Enter the following information in the appropriate text boxes:  Hostname or IP address of the FTP site where the packages are located.  FTP directory where the packages reside at the FTP site.  (Optional) User account and password to use when conn ecting to the FTP site. If you leave these fields empty , th e anonymous accou nt is used. Note If you specify a user account and pa ssword, you must re-enter the password whenever you change the FTP site, FTP directory , or FTP user on future requests. 4. Click Apply . A list of files ending with extensions .tgz, .Z , and .gz in the specif ied FTP directory appears in the Site Listing field. 5. Select a package to download from the Site Listing field. 6. Click Apply . The selected package is downlo aded to the local No kia IPSO system. After the download is complete, the package appears in the Unpack Ne w Packages field . 7. Select the package in the Unpack Ne w Packages field, then c lick Apply . The package is unpacked in to the local file system. 8. Click the Click Here to Install/Upgrade [File Name] link. 9. (Optional) Click Y es next to Display all packages , then c lick Apply to display all of your installed packages. 10. (Optional) Click Y es next to Install , then click Apply to pe rfo rm a first-time inst allation. 11 . (Optional) Click Y es next to Upgrade.
3 180 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 12. (Optional) Click the button of the package from which you want to upgrade under Choose one of the following packages to upgrade fr om . 13. Click Apply . 14. Click Save to make your changes perman en t. T o enable or disable a packag e 1. Click Manage Packa ges under Configuration > System Configurat ion > Packages in the tree view . 2. Click On or Off next to the package you want to enable or disable . 3. Click Apply . 4. Click Save. T o delete a package 1. Click Manage Packa ges under Configuration > System Configurat ion > Packages in the tree view . 2. Click the Delete Packages link. 3. Click Delete next to the package you want to delete. 4. Click Apply . 5. T o make your changes permanent, click Save. Advanced System T uning The configurations in this section are intend ed for specific purposes, and, under most circumstances, you should not change any of the default settings. T uning the TCP/IP St ack When a TCP connection is estab lished, both ends of the co nnection announce their TCP maximum segment size (MSS). The MSS setting is the value that your system advertises, and you can cha nge the value to tune TCP performance by allow ing your system to receive the largest possible segments without their being fragmented . This MSS configuration is subject to the following:  It is only applicable to TCP .  It sets the TCP MSS for packets that this syst em generates (as well as pac kets it receives). If a remote terminating node advertises an MS S higher than the MSS configured on this system, this system will send packets that ha ve the segment size configured with this feature. For example, if you set this value to 512 and a remote system advertises 1024, this system sends packets with a TCP segment size of 512.  It is only relevant to Ch eck Point security serv ers or similar products that require the Nokia appliance to termin ate the co nnection.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 181  Only the remote terminating node responds to the MSS value yo u set; that is, intermediate nodes do not respond. Generally , however , in termediate notes can handle 1500-byte MTUs. Y our system advertises the MSS value you set, an d remote terminated node s respond by sending segments in packets that do not exceed your advertised value. This segment size your system advertises should be 40 bytes less than the smallest MTU between your system and the outgoing interface. The 40-byte difference allows for a 20-byte TCP header and a 20-byte IP header , which are included in the MTU. T o set the TCP MSS 1. Click Advanced System T uning under Config uration > System Configuration in the tree view . 2. Click the Advanced System Tuning link in the System Configuration section. 3. Enter the value you will use for your MSS. The range for this value is 512 throu gh 1500, and the default value is 1024. If yo u enter a value outside of this range, an out-of-range error is generated. 4. Click Apply . 5. Click Save to make your changes permanent. Router Alert IP Option Y ou can use this feature to specify whether IPSO should strip the router alert IP option before passing packets to the firewall. (The router alert IP option is commonly enabled in IGMP packets.)
3 182 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 183 4 V irtual Router Redundancy Protocol (VRRP) This chapter describes the Nokia IPSO implemen tation of VRRP and how to configure it on your system. VRRP Overview V irtual Router Redundancy Protocol (VRRP) provides dynamic failover of IP addresse s from one router to another in the event of failure. VRRP is defined in RF C 3768. The Nokia implementation of VRRP includes all of the features described in RFC 3768, plus the additional feature of monitored circuit, descri bed below . Nokia supports VRRP for IPv6. For more info rmation about the Nokia implement ation and how to configure VRRP for IPv6 interfaces, see “Configuring VRRP for IPv6.” VRRP allows you to provide alternate router path s for end hosts that are configured with static default routes. Using static default routes mini mizes configuration and processing overhead on end hosts. When end hosts are configured with st atic routes, normally the failure of the master router results in a catastrophic event, isolatin g all hosts that are unable to detect available alternate paths to their gateway . Y ou can impl ement VRRP to provide a higher availability default path to the gateway without needing to configure dynamic routing or router d i sco very protocols on every end host. How VRRP W orks VRRP uses a virtual router to allow end hosts to use an IP address that is part of the virt ual router as the default first-hop router . A virtual router is defined as a unique virtua l router ID (VRID) and the router IP addresses of the default route on a LAN, and is comprised of a master router and at least one backup router . If the master platform fails, VRRP specifies an election protocol that dynamically assigns re sponsibility to a backup platform fo r forwarding IP traffic sent to the IP address of the virtual router . A virtual router , or VRID, consists of a master platform and one or more backups. The master sends periodic VRRP a dvertisements (also known as hello messages). T o minimize network traffic, backup s do not send VRRP advertisements.
4 184 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Nokia provides support for OSPF , BGP , RIP , and PIM (both spa rse and dense mode) to advertise the virtual IP address of the VRRP virtu al ro uter . Y ou must use monitored-circuit VRRP , not VRRPv2, to configure virtual IP support for a dynamic ro uting protocol. Y ou must also enable the Accept Connections to V RRP IPs option. Note IPSO also supports OSPF over VPN tunnels that terminates at a VRRP group. Only active- passive VRRP configurations ar e su pported, active-active configuratio ns are not. The master is defined as the rout er with the highest setting for the priority parameter . Y ou define a priority for each platform when you establis h the VRID or add a platform to it. If two platforms have equivalent priorities, the plat form that comes online and starts broadc asting VRRP advertisements first becomes the master . Figure 1 shows a simple VRRP configuration with a master (Platform A) and one backup (Platform B). Figure 1 Simple VRRP Configuration A VRRP router (a router that is running VRRP) might participate in more than one VRID. The VRID mappings and priorities are separate for each VRID. Y ou can use this type of configuration to create two VRIDs on the master and backup platfo rms, using one VRID for connections with the extern al ne twork and one for connection w ith the internal network, as shown in Figure 2 . Host H1 Host H2 Host H3 Host H4 00496 VRID 192 192.168.2.1 192.168.2.2 Platform A Platform B Internal Network 192.168.2.0
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 185 Figure 2 VRRP Configuration with Internal and External VRIDs In this example, Platform A acts as the master for both VRID 1 and VRID 2 while Platform B acts as the backup for both VRID 1 and VRID 2. Y ou can configure several platforms to be part of multiple VRIDs while they simultaneously back up each other, as shown in Figure 3 . This is known as an active-active configuration. Figure 3 VRRP Configuration with Simult aneous Backup In this active-active configuration, two VRIDs ar e implemented on the internal network for the purpose of load sharing. Platform A is the mast er for VRID 5 and serves as the default gateway for Host H1 and Host H2, while Platform B is the master for VRID 7 and serves as the default gateway for Host H3 and Host H4. Simultaneously , both Platform A and B are configur ed to back up each other . If one platform fails, the other takes over its VRID and IP addresses and provides uninterrupted service to both default IP addresses. This configuration provides both load balancing and full redu ndancy . Internet 00497 VRID 2 Master Backup 200.10.10.1 200.10.10.2 192.168.2.1 192.168.2.2 VRID 1 Master Backup Platform A Platform B Internal Network Public Network VRID 5 (master) backup address: 192.168.2.5 priority: 254 VRID 7 (master) backup address: 192.168.2.7 priority: 254 VRID 7 (backup) backup address: 192.168.2.7 priority: 253 VRID 5 (backup) backup address: 192.168.2.5 priority: 253 192.168.2.1 192.168.2.2 00498 Host H1 192.168.2.5 Host H2 192.168.2.5 Host H3 192.168.2.7 Host H4 192.168.2.7 Default Gateway: Platform A Platform B Internal Network 192.168.2.0
4 186 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Underst anding Monitored-Circuit VRRP The Nokia implementation of VRRP includes additional functiona lity called monitored circuit. Monitor ed-cir cuit VRRP eliminates the black holes caused by asymmetr ic routes that can be created if only one interface on the master fails (as opposed t o the en tire box faili ng). IPSO does this by releasing priority over a ll of the VRRP -configured interfa ces to allow the backup to take over entirely . Note Y ou can choose to implement the industry st andard VRRPv2 on your Nokia appliance instead of monitored-cir cuit VRRP . For information on implementing VRRPv2, see “Configuring VRRPv2” on page 196. T o understand the advan tage of monitored-circuit VRRP , consider t he configuration pictured in Figure 2 . In this example, if you are using standard VRRPv2 and the external interface fails or becomes unreachable, the external virtual router fails over to the back up while the internal virtual router stays on the master . This can resu lt in reachability failures, as the platform might accept packets from an inte rnal end host but be unable to forw ard them to destinations that are reached through the failed interfa ce to the external network. Monitored-circuit VRRP monitors all of the VRRP-configured interfaces on the platform. If an interface fails, the master releases its priority ov er all of the VRRP-confi gured interfaces. This allows the backup platform to take over all of the interfaces and become master for both the internal and external VRID. T o release the priority , IPSO subtracts the prio rity de lta, a Nokia-specific parameter that you configure when you set up the VRID, from the priority to calculate an effective priority . If you configured your system correctly , the effective prio rity is lower than that of the backup routers and, therefore, the VRRP election protocol is triggered to select a new master . Configuring VRRP Y ou can configure VRRP on your appliance using three methods:  Monitored-Circuit VRRP simplified method For most purposes, you should use this method. This is a si mplified version of the VRRP with monitored circuit full co nfiguration meth od. Y ou canno t use both full and simplified methods to configure monit ored-circuit VRRP on the same appliance. For more information, see “Configuring Monitored-Circuit V RRP using the Simplified Method” .  Monitored-Circuit VRRP full method Use this method if you are working wit h a system on which VRRP has already been configured using this method or if you need con trol over the configuration of each individual interface. For more information see “Configuring Monitored-Circuit VRRP using the Full Method” .  VRRPv2
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 187 Use this method only if y ou do not have an extra IP address to use for monitored-circuit VRRP . For more information see “Configuring VRRPv2” . Selecting Configuration Parameters Before you begin, plan your implementation by deciding how you want to set the following configuration parameters .  Priority  Hello Interval  Authentication  Priority Delta  Backup Add ress  VMAC Mode Priority The priority value determines which router t akes ov er in the event of a failure; the router with the higher priority becomes the new master . The ra nge of values for priority is 1 to 254. The default setting is 100. Note In Nokia’s moni to red-circuit VRRP , the master is defined as the router with the highest priority setting, although RFC 3768 specifies that th e master must have a priority setting of 255. If two platforms have eq uivalent priorities, the platform that comes online and starts broadcasting VRRP advertisements first becomes th e master . If there is a tie, the platform wi th the higher IP address is selected. T o prevent the unlikely event that the tie-breakin g algorithm selects one platform as the master for the external network and another as the master router for the internal network, you should make all interfaces on one platform numericall y greater than the inte rfaces on the peer . For example, Platform A should be the .1 host and Plat form B should be the .2 host on a ll connected interfaces. Y ou should set the priority to 254 for least the ma ster platform in e ach VR ID to provide a faster transition in the event of a failure. Using high er values can decrease th e time it takes for a backup router to take over for a fa iled router by close to one second. Note Setting a higher priority shorte ns the transiti on time because the time interval for a backup to declare the master down is calculated as Master_Dow n_Interval = (3 * Hello_inter val) Skew_time ; and the sk ew time (s econds by
4 188 Nokia Network Voyager for IPSO 4.0 Refe rence Guide which to skew the Master_D own_Interv al) is calculate d as Skew_time = ( (256 - Priority) / 256) ) . Y ou can configure your VRID to specify one platform as the established master by assigning it a higher priority , or you c an as sign equivalent priority to all platforms. If you specify an established master by assigning it a higher priority , the original master recovers control after a failover event and it takes back control of the VRID. If you assigned the original master equivalent priority with the backup, it does not resume control of the VRID. Y ou might choose to specify one platform as the established master if it has more capacity than the other; for example if the master is an IP53 0 and the backup is an IP330. If both security platforms have the same capacity , you might choose to use eq uiv alent priority in order to have fewer VRR P transitions. Y o u can also use the preempt mode to accomplish the same thing. Hello Interval The hello interval is the time interval in seconds at which the master sends VRRP advertisements. The default (and minimum) v alue is 1 second. Set the hello interval to the sa me value for all nodes of a give n VRID. If the hello interval is different, VRRP discards packets, which result s in both platforms going to the master state. The hello interval also determines the failover inte rval; that is, how long it takes a backup router to take over from a failed master . If the master mi sses three hello advertisements, it is considered to be down. Because the minimum hello interval is 1 second, therefore the minimum failover time is 3 seconds (3 * Hello_interva l). Authentication Y ou must select the same authentication me thod selected for all nodes in a VRID. Choose None to require no auth entication for VRRP advertisemen ts; choose Simple to require a password before a VRRP advertisement is accepte d by the interface, then enter the password in the Password text field.  None —Select only in environments where there is minimal security risk and little chance for configuration errors (for example, only two VRRP routers on a LAN).  Simple —VRRP protocol exchanges are authenticated by a simple clear - text password . Y ou can use this authentication method to protect against a router inadvertently backing up another router in cases where you have mo re than one VRRP group in a network. Simple authentication do es not protect against hostile a ttacks where the password can be learned by a node sno oping VRRP packets on the LAN. However , when combined with the TTL check used by VRRP (TTL is set to 255 and is checked on receipt), simple authentication make it unlikely that a VRRP packet from another LAN will disrupt VRRP operation.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 189 Priority Delt a Choose a value for the priority delta that ensure s that the priority delta subtracted from the priority results in an effective priority that is lower than that of the backup ro uters (in case an interface fails). Y ou might find it useful to use a standard priority delta th roughout your VRRP configurations to keep your configuratio ns simple and eas y to u nderstand. This parameter applies only to monitored-circ uit VRRP , not to VRRPv2. Backup Address Also called the virtual IP address, the backup address is the IP address your end hosts and neighbor routers use for routing. The backup ad dress is the address that is failed over between the master an d th e b ac ku p p l atfo rms . Th e b ackup address parameter is added to standard VRRP for use with Nokia’ s monitored-circuit VR RP . It does not appl y to VRRPv2. The backup addr ess must be in th e same n e two rk as the interface you want to use for the VRID. When you enter a backup address, the system uses the interface that is in that subnet for the VRID. Note If there is no interface configu red on the sub n et of the backu p address, the system does no t always display an err or message. V erify that the backup addre ss subnet is configured on your system. Y ou must also select backup addresses that do not match the real IP address of any device on the interface network nor the IP address of any of the interfaces on either VRRP node. Before you modify backup addresses or delete an IP address from an interface, consider the following points. (These points apply only to monitored-circuit VRRP co nfigured using the simplified method.)  Y ou must manually modify the list of backup addresses on each node of a VRRP group whenever the IP addresses of the other routers change.  Y ou cannot change the backup address from on e interface to another interface while a platform is in the master state. T o modify a virtual IP addre ss, firs t cause a failover to the backup (you can do this by disabling one of the VRRP-confi gured interfaces), then delete the VRID and re-create it using the new IP a ddress, then configure it as it was configured before.  Before you delete an IP ad dress from a logica l interface, you must delete the corresponding backup addresses configured for monitored-circ uit VRRP . The configur ation for the virtual router might become corrupted if you delete the IP address before you delete the backup addresses. This is sue does no t apply either to the full method configuration of monitored-circuit VRRP or to VRRPv2.
4 190 Nokia Network Voyager for IPSO 4.0 Refe rence Guide VMAC Mode For each VRID, a virtual MAC (V MAC) address is assigned to the backup address. The VMAC address is included in all VRRP packet transmissions as the so urce MAC address; the physic al MAC address is not used. When you configure a VRID, you specify which mode IPSO uses to select the VMAC address. Y ou can use any of the mo des for V irtual LA N deployments, which forward traffic based on the VLAN address and destination MAC address.  VRRP —The default mode. IPSO sets the VMAC to the format outlined in the VRRP protocol specification RFC 3768. It is automatica lly set to the same value on all nodes of a VRID.  Interface mode —IPSO sets the VMAC to the MAC ad dress of the local interface. If you select interface mode for both master and backup, the VMAC is dif ferent for each. The VRRP IP addresses are associated with diff erent VMACs because they depend on the MAC address of the physical interfaces of the platform that is ma ster at the time. Note If you configure dif ferent VMACs on the master and backup, you m ust take care to choose the correct proxy ARP setting for Network Address T ranslation. Interface mode can be useful with certain swit c hes that have problems with packets on multiple ports with the same MAC address. In these cases, you can use Interface mode to ensure that the VMAC from the mast er and backup are not the same.  St a t i c m o d e —Select this mode if you want to set the VMAC address manually , then enter the 48-bit VMAC address in the S tatic VMAC text field. Note If you configure dif ferent VMACs on the master and backup, you m ust take care to choose the correct Proxy ARP settin gs when configurin g proxy ARP setting for Network Address Translation.  Extended mode —Similar to VRRP mode, except the system dynamically calculates three additional bytes of the interface hardware MAC address to generate a more random address. If you select this mode, IPSO constructs th e same MAC address for master and backup platforms within the VRID. Note If you set the VMAC mode to interface or stat ic, syslog error messages are displayed when you reboot or at failover , indicating duplicat e IP addresses for th e master and backup. This is expected behavior since both the master and backup routers are temporar ily using the same virtual IP a ddress until they resolve into m aster and backup.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 191 Before you Begin Before you begin, consider y our hardware and configuration. Are all backup routers able to handle the traf fic they will receive if the master fails? W ill you implement load-sharing? There are two global settings for VRRP as described in the following table. Plan values for the configuration parameters of e ach node, as describe d in the following table: T able 8 Global VRRP Settings Parameter Description Accept Connections to VRRP IPs The VRRP protocol specifi es NOT to accept or respond to IP packets destined to an adopted VRRP IP address. This option overrides this behavior and allow s accept and response to IP packets destined to an adopted VRRP IP address. This feature enhances interaction with network mana gement tools and enables failure de tection. Y ou must use this option when deployi ng high ly available a pplications whose service is tied to a VRRP IP address. Options: Disabled / Enabled. • Disabled specifies complia nce with the VRRP pr otocol specification not to accept or respond to IP packets destined to an adopted VRRP IP ad dress. • Enabled over ri des the VRRP protocol spec ification all owin g accept and respond to IP packets destined to an adopted VRRP IP address. Default: Disabled. Monitor Firewall S tate This option allows VRRP to monito r Firewall S tate. This repl aces cold-st art delay of previous releases. Nokia recommends that you do not disab le th e Monitor Firewall S tate option when running a firewall on a security platform. If you change the setting for Monitor Firewall S tate from enabled (the default) to disabled, VRRP negotiation for master state might start before the firewall is completely starte d. This can result in both VRRP nodes assuming the master state while the firewall processes are starting. Options: Disabled / Enabled. Default: Enabled. T able 9 VRRP Configuration Parame ters Parameter Descrip tion VRID Range is 1 to 255; there is no default. Choose a numbering scheme fo r your virtual routers th at will make sense to other people. For exampl e, you might choose VRIDs that are the last octet of the backup address, such as 5 if the backup ad dress is 192.168.2 .5. Priority Range is 1 to 254; default is 100. Set the priority to 254 for least one platform in each VRID and choose values on the high er end of the scale for the backups. This provides a fast er transition in the event of a failure. Decide whether you want an established master or equivalent priority for all or several rou ters. For more information, see “Priority” .
4 192 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Y ou set values for priority delt a and backup add ress only whe n configuring mon itored- circuit VRRP . These parameters are not applicable to VRRPv2. Complete these additional step s before you configure VRRP .  Synchronize all platforms that are part of th e VRRP group to have the same system times. The simplest way to ensure that system times are coordinated is to enable NTP on all nodes of the VRRP group. Y ou can a lso manually ch a nge the time and time zone on each node so that it matches the other node s to within a few seconds.  Add hostnames and IP add ress pairs to the host table of each node in your VRRP group. This is not required but will enable you to use ho stnames instead of IP addresses or DNS servers. Configuring Monitored-Circuit VRRP Y ou can configure monitored-circuit VRRP using either of two methods. Y ou cannot use both the simplified and full configuration methods on the same platform; in fact, after you have created a VRID using one method, the selections for the other method are no longer visible.  Simplified method—Nokia recommends you use this method. Th e simplified method automatically includes all V RRP-configured interfaces on the platform in the VRRP Priority Delta Choose a value that will ensure that when an interfa ce fails, the prio ri ty delta subtracted from the priority results in an effective priority that is lo wer than that of a ll of the backup routers. Nokia recommends you u se a standard priority del ta, such as 10, to simplify your configuration. For more information, see “Priority Delta” . Hello Interval R ange is 1 to 255; default setting is 1 second. Set the same value for all nodes in the VRID. For more information, see “Hello Interva l” Authentication Choose whether you want to implement no authentication or simp le password. Y ou must select the same authentication meth od fo r all nodes in the VRID. For more information, see “Authentication” . Backup address The backup address must be in the same net work as the interfa ce you want to use for the VRID. Select a backup addresses that does not match the real IP address of an y host or router on the inte rface network nor the IP address of any of the interfaces on either node. For more information, see “Backup Address” VMAC mode Choose the method b y which the VMAC address is set. For more information, see “VMAC Mode” . T able 9 VRRP Configuration Pa rameters Parameter Descrip tion
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 193 configuration. Y ou do not have to separately specify settings for eac h interface. For more information, see “Configuring Monitored-Circuit V RRP using the Simplified Method” .  Full method—Use this method if you are wor king with a system on which VRRP has already been configured using th is method, or if you want cont rol over the configuration of each individual interface. If you use this method , you must specify settings for each VRRP- configured interface, including which other inte rfaces are monitored by this one. For more information, see “Configuring Monitored-Circu it VRRP using the Full Method” . Configuring Monitored-Circuit VRRP using the Simplified Method T o implement monitored-circu it VRRP using the simplified me thod, you must first create a virtual router by specifying a VRID (the master router IP addresses are added to the virtual router automatically), and then specify values fo r priority , priority delta, hello interval, and backup address. Y ou do this for each appliance in each VRRP group in turn. For firewall and VPN applications, you generally want to back up at least two interfaces on the appliance—the external network and th e internal network. Note Before you delete an IP address from a logica l interfac e, you must d elete the co rrespondin g backup add resses conf igured in the monitored- circuit VRRP for the specified virtual router . The configuration for the virtual router mi ght become corrupted if you delete the IP addres s before you delete the ba ckup addresse s. This issue d oes not apply either to th e full method configuration of monitored-circuit VRRP or to VRRPv2. T o add a virtual router 1. Log on to the platform you will use as the master . 2. If you have not done so already , assign IP addresses to the interfaces you will use for the virtual router . 3. Click VRRP under Configuration > High A vailability in the tree view . 4. (Optional) If you want to allow the system to accept and respond to IP packets sent to an adopted VRRP IP address, select the Enabled radio button for Accept Connections to VRRP IPs. The VRRP protocol specifies not to accept or respond to such IP packets. Overriding this specification is recommended if you are deploy ing applications whose service is tied to a VRRP IP address. Y ou can also use it to allo w logins to the master by using an ad opted VRRP IP address. Y ou must also enable this opt ion if you configure a virtual IP for VRRP to run on OSFP , PIM, or OSPF . 5. In the Create a New Monitored-Circuit V irtual Ro uter text box, enter a value for the VRID . 6. Click Apply . 7. Additional fields are displaye d showing the configuration pa rameters. Enter values into these fields. For more information see “Selecting Configuration Parameters” .
4 194 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 8. Click Apply . 9. Click Save to make your changes pe rmanent. 10. Log on to eac h backup appliance in turn and repeat step 2 through step 5. Make sure you use the same values for VRID , hello interval, auth entication method, and backup address for all no des in the VRID. 11 . If you are using Check Point N GX, completely configure VRRP on each platform and make sure the firewall has begun synchro nization before you put the VRRP grou p in service. Following this process ensures that all connections are properly synchronized. T o delete a virtual router 1. Click VRRP under Configuration > High A vailability in the tree view . 2. In the row for the appropriate VR ID, select the Delete checkbox. 3. Click Apply . 4. Click Save to make your changes pe rmanent. T o change the configuration of an existing virtual router 1. Click VRRP under Configuration > High A vailability in the tree view . 2. In the appropriate tex t box, you can change the priority , priority delta, hello interval, authentication method, password for simple au thentication, and back up address for an existing virtual router . For information on th ese parameters, see “Selecting Configur ation Parameters” . Note If you chan ge the hello inte rval, authe ntica tion method, password , or backup addres s, you must change it on all other plat forms which p articipate in the VRID. 3. Click Apply . 4. Click Save to make your changes pe rmanent. Configuring Monitored-Circui t VRRP using the Full Method If you use the full method to configure monitore d-circuit VRRP , you must manually select the list of interfaces that each interface will monitor . Y ou ca n configure monitored-circuit VRRP using only one of the methods (simplified or full) on a given platform. If your platform has monitored-circuit VRRP co nfigurations configured using the full method and you wish to use the simplified method, you must delete the VRIDs and re-c reat e them using the simplified meth od . In addition to the configuration parameters used with the simplified configuration method (see Ta b l e 9 on page 191), Ta b l e 1 0 shows the additional parameters you can set when using the full configuration method.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 195 Note Y ou cannot change the backup address fr om one interface to another interface while a platform is in t he master state. T o m odify a virtual IP addres s, first cause a failover to the backup by reducing the priority or by pulling an interface, then dele te the VRID on the interface and re-create usin g the new IP addre ss, then configure it as it was configur ed before. T o add a virtual router 1. Click VRRP under Configuration > High A vailability in the tree view . 2. Click VRRP Legacy Configuration. 3. In the row for the interface you want to config ure, select the Monitored Circuit radio button. 4. Click Apply . The Create V irtual Router text box appears. T able 10 Additional VRRP Parameters Used in Full Method Parameter Description Preempt mode Preempt mode is enable d by defa ult. Check disabled to specify that this router will not fail over to a router with higher priority . Use this setting if you want to reduce the number of transitions. For example, if you disable preempt mode on a backup and the master fails over to it, then when the master becomes active again, the virtual route r will not fa il back to it. Rather the new master will remain the master even though it has a lower priority . Monitored-circuit VRRP operates by trigger i ng the failover of all mcVRRP interfaces on a platform when one interface goes down . It triggers failover by subtracting the priority delta from the priority for each mcVRRP i nterface, causing the interface to fail over to a node with a higher priority . If you disa ble preempt mode, interfaces wil l no longer failover in this way; they will only failove r if their effective priority is 0. Therefore, if you disable pr eempt mode , you must also apply the follo wing settings to each interface in the VR RP group. These conditi ons do not app ly to VRRPv2. • Enable auto-d eactivation. This allows the effective priority to be set to 0. If you do not enable au to-deactivation, the lowest effective priority al lowed is 1 even if the priority minus the delta mathematically equals 0. • Set the priority delt a to the same value as the priority for each in t erf ac e on the virtual router . This means that the prio rity minus the priority delta equals 0. Monitor interface Select an interface that this interf ace will monito r and specify a priority delta. As you select each interface and click Apply , it appears in the list above the Monitor interface drop-down box. Auto-deactivation Enable auto-deactivation if you want to allow the minimum value for effective priority to be 0. A VRRP router with an effective priority of 0 will not become the master even if there are no other VRRP rout ers with higher priority for this virtual router . If auto- deactivation is disabled (the default), the lo west all owable value for effective priority is 1.
4 196 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. Enter the value you want to use to iden tify the virtual router and click Apply . Additional fields appear . 6. Enter values for the configuration pa rameters for the virtual router . Most of these parameters are the same as those used in the simplified configuration method described in Ta b l e 9 . The additional parameters displayed on this page are specific to the full configuration method—Preempt mode, Monitor interface, and Auto-deactivation—and are described Ta b l e 1 0 . 7. Click Apply . 8. Click Save to make your changes pe rmanent. Note This procedure descr ibes how to implemen t monitored-circuit VRRP using Network V oyager . Y ou can also use the CLI commands set mcvr to accomplish the same tasks. For more information, see the CLI Re ference Guide for the version of IPSO you are using . T o delete a virtual router 1. Click VRRP under Configuration > High A vailability in the tree view . 2. Click VRRP Legacy Configuration. 3. Under the section showing the interface for wh ich the VRID is configured, select the Off radio button for the virtual Router . Alternatively , you can select the Of f radio button in the Mode section for the interface. 4. Click Apply . 5. Click Save to make your changes pe rmanent. Configuring VRRPv2 Use VRRPv2 rather than Nokia’ s monitored-circuit VRRP only if you do not have an extra IP address to use for monitored-circuit VRRP . Note Y ou must use monitored-circuit VRRP when c onfiguring virtual IP support for any dynamic routing protocol. Do not use VRRPv2 when configuring virtual IP supp ort for any dynamic routing protocol. T o add or back up a virtual router using VRRPv2 1. Click VRRP under Configuration > High A vailability in the tree view . 2. Click VRRP Legacy Configuration.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 197 3. In the row for the interface yo u want to configure, select the VRRPv2 r adio button in the Mode column. 4. Click Submit. T ext boxes for Own VRID and Back up Router with VRID appear . 5. Configure the router as a master or a backup by doing one of the following.  If you want to configure th is router as the ma ster for a VRRP group, enter the VRID for the virtual router in the Own VRID tex t box.  If you want to configure th is router as a bac kup, enter the VRID you want t he router to back up in the Backup Router wi th VRID text box. 6. Click Apply . Additional fields appear . 7. Do one of the follow ing, depend ing on whether this platform se rves as a master or a bac kup.  If this platform serves as the master router , enter values in the Own VRID section for hello interval and VMAC mode for the VRID for which this platform serves as the master router . (For VRRPv2, the priority for the master is automatically set to 255 and the backup address is the phy si cal address of the interface.)  If this platform serves as a b ackup router , enter values in the Router with VRID section for each VRID you are usin g the interface to backup. 8. Click Apply . 9. Click Save to make your changes permanent. Note T o disable a virtual r outer , first remove the VRRP co nfiguration for that virt ual router fro m all backup routers. If you delete the virtual rout er on the master first, it stop s sending VRRP advertisements an d the backup router assumes it has failed and adopt s the address of the master automatically . This results in two routers having th e address of the default router configured. Configuring Check Point NGX for VRRP The guidelines in this section lis t some considerations for co nfiguring Check Point NGX for VRRP . For additional details, refer to the Check Point documentation.  Each VRRP node must run the same feature pack and hot fix.  Y ou must install the same Check Point packages on each node; each VRRP node must have exactly the same set of packages as all the other nodes.  Create the complete VRRP configuration before you put any of the systems into service. That is, make sure each system is comple tely configured and the firewall has begun synchronization before putting the VRRP group in service. Following this process ensures that all conn ections are properly synchronized.
4 198 Nokia Network Voyager for IPSO 4.0 Refe rence Guide When you use the Check Point cpconfig prog ram (at the command line or usi ng Network V oyager), follow these guidelines:  Install Check Point NGX as an en forcement module only on each node. Do not install Check Point NGX as a management server and enforcement module.  After you choose to install Check Point NGX as an enforcement module, you are asked if you want to install a Check Point clustering product. The screen displays the following question: "Would you like to install a C heck Point clustering product (CPHA, CPLS or State Synchronizatio n)? (y/n) [n] ? The default is no; be sure to enter yes.  If you plan to use SecureXL, enable it when you ar e pro mpted to do so. Y ou then create and configure a gateway cluster object with the external VRRP IP address.  Use the Check Point SmartDashboard application to create a gateway cluster object.  Set the gateway cluster object address to the ex ternal VRRP IP address, that is, the VRRP IP address of the interface that faces the external network.  Add a gateway object for each Nokia app liance to the gateway cluster object.  In the General Properties dialog box fo r the gateway cluste r object, do not c heck ClusterXL.  Configure interfaces for each member of the V RRP cluster . Click the T opology tab for each VRRP cluster member and click Get.  Configure interfaces for the VRRP cluster . C lick the T opology tab for the gateway cluster object, and click Get.  Enable state synchronization and configure interfaces for it. Note The firewall synchronization network should have bandwid th of 100 mbps or greater . The interfaces that you configure for state sync hronization should not be part of VLAN or have more than one IP address assigned to them. When you finish configuring the gateway cluster object, you must also specify settings under the 3rd party configuration tab as described in the following procedure. Configure settings under the 3rd p arty configuration t ab 1. In the Specify Clustering Mode field, check High A vailability . 2. From the Third-Party Solution drop-down list, select Noki a VRRP . 3. Check all the available check boxes. 4. Click OK to save your co nfiguration changes. Note If you use d ifferent encryption a ccelerator cards in two ap pliances that a re part of a VRRP group or an IP cluster (s uch as the Nokia Encrypt Card in one appliance a nd the olde r Nokia Encryption Accelerator Card in anothe r appliance), you should select encryption/ authentication algorithms tha t are supported on both cards. If the encryption/authentica tio n algorithm is supported in the master and not supported by the backup and you also use NA T ,
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 199 tunnels do not fail over cor re ctly . If the encryption/au the n tica tio n alg o rith m is supp or te d in the master and not suppor te d by the backup and you do not use NA T , tunnels fail over correctly , but they are no t accelerated after failover . If you use sequence validation in VPN-1 NGX, you should be aware that in the event of a failover , sequence validation is disabled for conn ections that are transferred to a nother node. Sequence validation is enabled for connec tions that are created after the failover . Y ou might want to enable sequ ence validation in the Check Point mana gement application and IPSO, as described in th e following procedure. T o enable sequence validation in the Check Point management application a nd IPSO 1. Click Advanced System T uning under Config uration > System Configuration in the tree view . Note This option is available only when SecureXL is enabled. 2. On the Advanced System Tuning page, clic k the button to enable sequence validation. 3. Enable sequence validation in the Ch eck Point management application. 4. Push the new policy to the IPSO appl iance. Configuring VRRP Rules for Check Point NGX When you are using Check Point NGX FP1 and FP2 or later , you must define an explicit VRRP rule in the rulebase to allow VRRP Multicast pack ets to be accepted by the gateway . Y ou can also block the VRRP traffic w ith an explicitly defined rule. Caution VRRP rule constructions used in Check Point FireW a ll-1 4.1 and earlier does not work with Check Point NGX. Using these constructi ons could result in VRRP packets being dropped by the cleanup ru le. For information about how to configure VRRP ru les for Check Point FireW all-1 4.1, c ontact the Nokia T echnical Assistance Center (T AC). Configuration Rule fo r Check Point NGX FP1 Locate the following rule above the S tealth Rule:
4 200 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note The object for VRRP is not the same as the ga teway cluster object fo r HA. Accordingly , in this example, the gateway cl uster object is designated fwcluster-object . Where:  cluster-all-ips is the W orkstation object you created with all IPs.  fwcluster-object is the Gateway Cluster object.  mcast-224.0.0.18 is a W orkstation object with the IP address 224.0 .0.18 and of the type host. Configuration Rules for Chec k Point NGX FP2 and Later Locate the following rule above the S tealth Rule: Where:  Firewalls is a Simple Group object containing the firewall objects.  fwcluster-object is the gateway cluster object.  mcast-224.0.0.18 is a Node Host object with the IP address 224.0.0.18. Configuring Rules if Y ou Are Using OSPF or DVMRP All of the solutions in “Configuration Rule for Check Point NGX FP1” and “Configu ration Rules for Check Point NGX FP2 and Later” are applicable for a ny multicast destination. If your appliances are running ro uting protocols such as OSPF and DVMRP , create new rules for each multicast destination IP address. Alternatively , you can create a Network object to represent all multicast ne twork IP destinations by using the following va lues: Name: MCAST.NET IP: 224.0.0.0 Netmask: 240.0.0.0 Y ou can use one rule for all multicast protoc ols you are willing to accept, as shown below: Source Destination Service Action cluster-all-ips fwcluster-object mcast-224.0.0.18 vrrp igmp Accept Source Destination Service Action Firewalls fwcluster-object mcast-224.0.0.18 vrrp igmp Accept
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 201 Link Aggregation (IP2250 Systems Only) IP2250 appliances allow you to aggregate the built-in 10/100 mbps Ether net ports so that they function as one logical port with higher bandwi dth. These appliances offer link aggregation to accommodate fire wall sync hronization traffic in VRRP configurations. If you configure two IP2250 ap pliances in a VRRP pair and run VPN-1/FireW all-1 on th em , Nokia recommends that you create a 200 mbps logical li nk between them and configure VPN-1 NGX to use this network for firewall synchronization traffic. If you use a single 100 mbps connection for synchronizatio n, connection inform ation might not be properly synchronized if the appliance is handling a la r ge number of connections. See “Link Aggregation” for detailed information about link aggregation. Monitoring VRRP Y ou can use the following CLI commands to view and monitor VRRP information: T o view VRRP information using Network V oyage r , click Monitor (on the Home Page) > VRRP Service Statistics (under System Health). The VRRP service status table appears. The VRRP service status table contains per-in terface and per-virtual router VRRP send an d receive packet statistics. It is updated every 20 seconds. Stat e A virtual router can be in one of three states: Source Destination Service Action cluster-all-ips fwcluster-object MCAST.NET vrrp igmp ospf dvmrp Accept T able 1 1 CLI commands for VRRP Command Description show vrrp Displays a summary of the VRRP state on the node. show vrrp interfaces Displays VRRP informatio n about all interfa ces. Use with the name of an interface, for example show vrrp interface <name> , it displays VRRP information for that interface only . show vrrp stat Displays statistics for all VRRP interfaces. show mcvr Displays information about all mo nitored-circuit VRRP interface s.
4 202 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Master —Forwarding IP packets addressed to the virtual router .  Backup —Eligible to become master and monito ring the state of the current master .  Initialize —Inactive; waiting for startup event. Note If a virtual router is in initialize state for lo nger than 20 seconds, this typically indicates that you have a configuration proble m, such as a virtual IP address that is not valid. Check your VRRP configuration. Location The location section of the VRRP service status ta ble displays the virtual router flags or the primary address of the current virtual router master . The location options are:  Local —The virtual router applies to ad dresses owned by the local route r .  IP address —Primary address of the current virtual router master . Address 0.0.0.0 indicates unknown. Stats The stats section of the VRRP service status table displays VRRP send and receive packet statistics. The Stats options are:  Advertisement T ransmitted —Number of VRRP Advertisement packets sent.  Advertisement Received —Number of VRRP Advertisement pa ckets rece ived.  Bad Address List Received —Number of VRRP packets received and discarded due to misconfigured address list. Note If the advertisement is from the address owne r (pr iority=255) that packet is accepted , even with the co nfig u ratio n mis match.  Bad Advertise Interval Received —Number of VRRP pa ckets received and discarded due to misconfigured adv e rtisement interval.  Authentication Mismatch —Number of VRRP packets received and discarded due to misconfigured authentication type.  Authentication Failur e —Number of VRRP packets received and discarded due to authentication failure.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 203 Monitoring the Firewall St ate By default, IPSO monitors the state of the fire wall and responds appropriately . If a VRRP master detects that the firewall is not re ady to handle traffic or is not functioning properly , the master fails over to a backup system. If all the firewalls on all the sy stems in the VRRP group are not ready to forward traffic, no traffic will be forwarded. T o enable or disable Monitor Firewall state 1. Click VRRP under Configuration > High A vailability in the tree view . 2. Click Enabled in the Monitor Firewall S tate field. T o disable this option, if you have enable d it, click Disabled. Th e default is Enabled. 3. Click Apply 4. Click Save to make your changes permanent. T roubleshooting VRRP This section lists common proble ms with VRRP configurations . Please consult this section before contacting Custom er Su pport. For information abou t contacting Nokia Customer Support, go to https://su pport.nokia.com/ Y ou can log informatio n about e rrors and ev ents to troubleshoo t VRRP by enabling traces for VRRP . T o enable traces for VRRP 1. Click Config on the home page. 2. Click the Routing Options link in t he Routing Configuration section. 3. Scroll down the T race Options section to VRRP and choose an option from the Add Option drop-down list. 4. Click Reset Routing. The system restarts the routing subsystem and signals it to reread its configuration. The option you selected, its name and On/Off radio bu ttons are displayed on the page. General Configuration Considerations If VRRP failover does not occur as expected, ve rify that the following items are correctly configured.  All routers of a VRRP group must have the same system times. The simplest way to synchronize times is to enable NTP on all nodes of the VRRP group. Y o u can also manually change the time and time zone on each node so that it matches the other nodes. It should match to within a few seconds.  All routers of a VRRP group must have the same hello interval.
4 204 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  If you are testing monitored-ci rcuit VRRP by pulling an inte rface, and the other interfaces do not release their IP addresses, check that the priority delta is large enough that the effective priority is lower than the master router .  If you use different encryption accelerator cards in two appliances that are part of a VRRP group or an IP cluster , such as the Nokia Encrypt Card in one appliance and the older Nokia Encryption Accelerator Card in another appliance, you must select encryption algorithms for each card that are supported on both cards. If you select different encryption algorithms on the backup appliance than on the mast er , failover might no t occur correctly .  VRIDs must be the same on all routers in a VRRP group. If you are using monitored-circuit VRRP , verify that all platforms in the group that back up a single virtual IP address use the same VRID. If you are using VRRP v2, verify that the VRID used on each backup router uses the same VRID and IP address as the primary router .  If the VRRP monitor in Network V oyager shows one of the interfaces in initialize state, it might indicate that the IP address used as the backup address on that interface is invalid or reserved.  SNMP Get on Interfaces might list the wrong IP addresses, resulting in incorrect Policy . An SNMP Get (for the Firewall object Interfaces in the GUI Security Policy editor) fetches the lowest IP address for each inte rface . If the interfaces are created when the node is the VRRP master , the wrong IP address migh t be included in the object. T o solve this problem, edit the interfaces by hand if necessary . Firewall Policies If your platforms are running firewall software, you must enable the firewall policies to accept VRRP packets. The multicast destination assigne d by the IANA for VRRP is 224.0.0.18. If the firewall policy does not explicitly accept packets to 224.0.0.18 , each firewall platform in the VRRP group assumes the VRRP master state. Access Control List s If your platforms use access control lists, you must , at minimum, include the following in the access list criteria:  The source IP addresses of all participants in the VRRP group.  The VRRP multicast destination IP address, which is 224.0.0.18.  The VRRP IP protoco l value, which is 1 12. If these most restrictive conditions are in place, the n each VRRP participant on each a ccess control interface must have a sepa rate rule. Alternatively , you can define a more open rule. For example, a single rule allowing all packets with DST IP 2 24.0.0.18 and IP protocol va lue 1 12 would work for all interfaces controlled by a n access control list.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 205 Switched Environment s Monitored-Circuit VRRP in Switched Environment s  When you use monito red-circuit VRRP , some Ethernet switches might no t recognize the VRRP MAC address after a transition from the master to a backup. This is because many switches cache the MAC address associated with th e Ethernet device atta ched to a port and when the transition occurs to a backup router , the MAC address for the virtual router appears to shift to another port. Switches that cac he the MAC address may not change to the appropriate port during a VRRP transition. T o solve this problem, you can take either of the following actions:  Replace the switch with a hub.  Disable MAC address caching on the switch or on the switch ports that the security platforms are connected to. If it is not possible to disable the MAC a ddress caching, you may be able to set the address aging value to a number low enough that the addresses age out every second or two. This causes add itional overhead on the switch, so yo u should determine whether this is a viable option for the mode l of switch you are running.  Another issue is sometimes seen with switche s using the spanning tree protocol. This protocol was created to prevent Layer 2 loop s across multiple bridges. If spanning-tree is enabled on the ports connected to both sides of a VRRP pair a nd it sees multicast hello packets coming for the same MA C address from two different ports, then, in most cases, this would indicate a loop and the switch b locks traffic from one port or the other . If either port is blocked then neither of the security platforms in the VRRP pair can receive the hello packets from the other half of the VRRP pai r and bo th would assume the master router state. If possible, turn off spanning-tree on the switch to resolve this issue. However , this can have deleterious effects if the switch is involved in a bridging loop. If you can not disable spanning-tree, enable PortFast on the ports co nnected to the VRRP pa ir . PortFast causes a port to enter the spanning-tree forwarding st ate immediately , bypa ssing the listening and learning states. The command to enable PortFast is set spantree portfast 3/1-2 enable ; where 3/1-2 refers to slot 3 ports 1 and 2. VRRPv2 in Switched Environments In the event that you have two interfaces on a sw itch that are on different VLANs and each has a VRID that is the same as the other , the syst em can fail. Duplicate VRIDs create duplicate MAC addresses, which will prob ably confuse the switch.
4 206 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 207 5 Configuring Clustering This chapter describes IPSO’ s clustering featur e and provides instruc tions for configuring clusters. It includes information about upgrading from IP SO 3.6 to IPS O 3.7 or later if y ou have a cluster configured with IPSO 3.6, and it also presents information about how to confi gure Check Point’ s NGX to work with an IPSO cluster . IP Clustering Description IPSO lets you create firewall/VPN clusters that provi de fault tolerance and dynamic load balancing. A cluster consists of multiple appliances (nodes) th at share common IP addresses, and it appears as a single system to the networks connected to it. A cluster continues to function if a node fail s or is taken out of service for maintenance purposes. The connections being handled by th e failed node are transferred to one of the remaining nodes. IPSO clusters are also scalable with regard to VPN performance —as y ou ad d node s to a cluster , the VPN throughput improves. IPSO clusters support a variety of Check Point NGX features , including:  Synchronizing state information between firewalls  Firewall flows  Network address translation  VPN encryption Note All cluster nodes must run the sa me versions of IPSO and NGX. Using Flash-Based Platforms Do not combine an IP2250 with any other model in an IP cluster . That is, the other platform must also be an IP2250. See “Clustering IP2250 Platforms” for more information about this and other details that are specific to the IP2250.
5 208 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Y ou can create IP clusters by combining flash-b ased platforms other than the IP2250 with disk- based or different flash-based models. For ex ample, the following combinations are valid:  flash-based IP1260, disk-based IP1260, IP380  two flash-based IP1260 pla tforms  IP385, IP380, IP265 This list provides examples only . There are many other combinatio ns that you can use to create clusters. Example Cluster The following diagram shows a cluster with tw o nodes, firewall A and firewall B. The cluster balances inboun d an d outbound network traffic be tween the nodes. If an internal or external interface on one of the nodes fails, or if a no de itself fails, the existing connections h andled by the failed node are not dropped—the other no de processes the m. The other node continues to function and handle all of the traffic for the cluster . Routers connected to an IPSO cluster must have appropriate static routes to pass traffic to the cluster . In this example: Internet Firewall A Firewall B 192.168.1.0 192.168.2.0 Secondary Cluster Protocol Network: 192.168.4.0 Cluster IP: 192.168.4.10 Cluster (ID 10) External Router Primary Cluster Protocol Network:192.168.3.0 Cluster IP: 192.168.3.10 192.168.1.10 192.168.1.10 192.168.2.10 192.168.2.10 VPN-1/FireWall-1 Synchronization Network (Secured Network) Internal Router Internal Network
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 209  The external router needs a static route to the internal networ k (192.168.1.0) with 192.168.2.10 as the gateway address.  The internal ro uter needs a static route to the external network (192.168.2.0) with 192.168.1.10 as the gateway address. The IP addresses shown in boldface are cluster IP addresses , addresses shared by multiple interfaces in the cluster . IPSO uses the cluster protocol networks shown in the diagram for cluster synchronization and cluster management traffic. If a primary cluster protocol interface fails on a node, the node use s its secondary cluster protoc ol interf ace, and service is not interrupted. Note Nokia recommends that the the primary cluste r protocol network be dedicated to this purpose (as shown here). The ide al configuration is to physically sepa rate the cluster protocol netw ork from the prod uc tio n ne two r ks. This co nf igu ra tio n is pre fe ra b le to us ing separate VLANs on one s witch to separate them. Do not use a secondary cluster p rotocol network for production tra ffic. If a seco ndary cluster protocol ne twork fails bu t the prima ry remains fu nctional, the cluster rem ains active but traffic to non-cluster devices on the se condary network might fail. IPSO’ s cluster management features allow you to con figure firewall A and B as a single virtual device, and IPSO also lets yo u easily set up automatic co nfiguration of cl uster nodes. In this and similar diagrams, switches and hu bs are not shown for the sake of simplicity . Cluster Management Y ou can manage all the nodes of a cluster simultaneously by usin g Cluster V o yager . This is a feature that lets you configure a cluster as a single virtual d evic e. Y o u can make configuratio n changes once and have them take effect on all the cluster nodes. Y ou can also use the Cluster CLI (CCLI) to manage a cluster , and much of the in formation in this section applies to the CCLI as well. See the CLI Refer ence Guide for IPSO for more information about the CCLI. The following list explains the difference between V oyager/CLI and Clus ter V oyager/CCLI:  V oyager and th e CLI manage a single IPSO system.  Cluster V oyager and the cluster CLI manage multip le clustered IPSO systems as if they are a single system.
5 210 Nokia Network Voyager for IPSO 4.0 Refe rence Guide This diagram illustrates the dif ference. Any changes you make in V oyager or Cluster V o yager are immediately reflected in the CLI and CCLI. The reverse is also true—settings made in the CLI or CCLI are immediately reflected in V oyager or Cluster V oya ger . Cluster T erminology This section explains the terms used in IPSO clustering.When ap pli cable, it references the example cluster . CCLI: Cluster CLI—A feature that lets you centra lly manage all the node s in a cluster as a single virtual system usin g one command-line session. Cluster administrator: When you log into a Nokia appliance as a user that has been assigne d a cluster role, you log in as a cluster administrato r . The default cluster administrator user name is cadmin. When you create a cluster you must specify a password, and that passw ord is the password for the cadmin user . When you log in as a cluster administrator , one of the following occurs:  If you are using a browser , the system displays Cluster V oyager .  If you are us ing the command shell and enter clish , the system s tarts the CCLI. Cluster ID: A user-specified number that uniquely identifies the cluster within the broadcast domain. Every node sha res this ID number . The range is 0 to 65535. If there is more than one cluster in the same networ k, each cluster must have a unique ID. In the example cluster , the ID is 10. Cluster IP addr ess: A unic ast IP address that every node in the clu ster shares. Each interface participating in a cluster must have an associated cluster IP address. The example cluster has four cluster IP addresses:  192.168.1.10 is the cluster IP ad dress of the internal interfaces.  192.168.2.10 is the cluster IP ad dress of the external interfaces. Firewall A Firewall B Cluster is Managed as Single Virtual Device by cadmin User Individual Nodes are Managed by admin User
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 211  192.168.3.10 is the cluster IP addr ess of the primary cl uster interface.  192.168.4.10 is the cluster IP addr ess of the secondary cluster interface. Cluster MAC address: A MAC address that the cluster protoc ol installs on all nodes. Only the cluster master responds to ARP requests that ro uters send to cluster IP addresses. The cluster MAC address makes the cluster appear as a single device at the OSI layer two level. Cluster master: The master node plays a central role in balancing the traffic among the cluster nodes.The cluster determines wh ich node is the master accord ing to the following criteria.  In forwarding mode the master receives all the incoming packet s and may forward th em to the other nodes for proces sing. In this mode the master is the active no de with the highest performance rating. If performance ratings are equal on all nodes, th e master is the first node of the cluster .  In the multicast modes, all the nodes rece ive all the incoming packets. The m aster determines which nodes should process each pa cke t and provides that information to the other nodes. Nodes simply drop p ackets that they should not process. In these modes, the master is the node that joins the cluster first. Note See “Clustering Modes” for more information about thi s featur e. Cluster member: A cluster node that is not the master . Cluster node: Any system that is part of a cluster , regardless of whether it is a member or the master . Cluster protocol networks/interfaces: The cluster protocol networks are used for cluster synchronization an d cluster management traf fic. Y ou create these networks by connecting cluster protocol interfaces. Y ou must create a primary cluste r protocol network, and Nokia recommends that you a lso create a secondary cluster p rotocol network for redund ancy . Y ou specify which interfaces are cluster protoc ol interfaces by selecting from the configured Ethernet interfaces. (Only Ethernet interfaces can participate in a cluster .) The cluster protocol interfaces can also be u sed for NGX synchroniza tion traffic. For more information about how to conf igure NGX for clustering, see “Configuring NGX for Clustering.” The following list explains more abou t primary and secondary cluster interfaces:  Primary cluster proto col network/interface: Each node must be connected to the primary cluster protocol network . The interface a node u ses to connect to this network is its primary cluster protocol interface. In the example cl uster , the primary interface is eth-s3p1. If the primary interface fails on a node and yo u have not config ured a secondary network, the node is removed from the cluster . If it is the master , one of the remaining nodes becomes the new master . These interfaces should be internal, and Noki a also recommends that you use a dedica ted network for the primary cluster p rotocol networ k. The ideal configurat ion is to physically separate the primary cl uster protocol networks from the product ion network s (conn ect them
5 212 Nokia Network Voyager for IPSO 4.0 Refe rence Guide using different switches). This configuration is preferable to using separate VLANs on one switch to separate them an d is the configuratio n shown in the example clu ster . If you do not use a dedica ted network as the primary netwo r k— that is, if the primary network also carries data traffic, see “If Y ou Do Not Use a Dedicated Primary Cluste r Protocol Network” and “Configuring NGX for Clustering” for configuration information.  Secondary cluster protocol network/interface: Each node may also be connected to an (optional) secondary cluster protocol networ k. The interface a node uses to connect to this network is its secondary clu ster protocol in terface. In the example cluster , the secondary interface is eth-s4p1. If a primary interface fails on a member , the cl uster synchroniza tion and management traffic fails over to the secondary in terface. In this event, the ot her nodes are not af fected—they continue to use their primary interfaces to communicate with the master . If a primary interface fails on the master , a ll the other nodes must use the secondary protocol network to communicate with the master . If the primary and secondary cluster protocol interface fails on a node, the node is removed from the cluster . If it is the master , one of the remaini ng nodes becomes the new master . These interfaces should be internal, and you should not use a secondary cluster protoc ol network for production traffic. If a secondary cluster prot oc ol network fails but the primary remains functional, the cluste r remains active but traffic to non-cluster devices on the secondary network might fail. Cluster V oyager: A feature that lets you centrally manage all the nodes in a cluster as a single virtual system using one browser session. Joining: When becoming part of a clus ter , a system can copy a variety of configuration settings from another cluster node (so you do n’ t have to configure these settin gs manually). This is call ed joining . When a system joins a cluster , it copies the configuration settings of the joi n-time shared features. Joining saves you time by allowing you to configure one node and then have th e other nodes copy the ap propriate configuratio n settings when they join the cluster . Join-time shared featur es: Y ou may want to have many conf iguration settings be identical on each cluster node. V oyager makes this easy for you by letting you specify which features will be configured the same on all cluster nodes. The features that can be configured this way are called join-time shar ed featur es , meaning that their configurations can be sha red across cluster nodes during the joining process. Clustering Modes IPSO clusters have three mo de s of operation. N okia provides this choice so that IPSO clusters can work in any network environment. Al l cluster nodes must use the same mode. Note If you use PIM, you must use multicast mode or multicast mode with IGMP as the cluster mode. Do not use forwarding mo de.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 213  In multicast mode each cluster node receives every packet sent to the cluster and decides whether to process it based on information it receives from the master node. If the node decides not to process the pack et (beca use another node is pr ocessing it), it drops the packet. This mode usually of fers better throughput be cause it u ses the bandwidth of the productio n networks more efficiently . Multicast mode uses multicast MAC addresses for each of the no des. If you use this mode, routers and servers adjacent to the cluster (either connected directly or through a switch or hub) must be able to accept ARP replies that contain a multicast MAC address. Switches connected directly to the cluster must be ab le to forward packets destined for a singl e (multicast) MAC address out multiple switch ports. See “Considerations for Clustering ” for more information about the requirements for routers and switches when using multicast mode. When you use this mode, the cluster MA C addresses are in the form 01:50:5A: xx:xx:xx, in which the last three bytes are the last three bytes of the appropriate cluster IP address in hexadecimal.  Multicast mode with IGMP offers the benefits of multic ast mode with an additional improvement. When you use multicast mode (wit hout IGMP), the switches connected to the cluster broadcast the data fra mes sent to the multicast MAC ad dresses of the cluster (unless they are configured not to do so). This me ans that any other devi ces attached to the same switches as the cluster also receive the traffic that is sent to the cluster . If the switches perform IGMP snooping (elicit or listen for IGMP messages), you can prevent this from happening by using multicast mode with IGMP . When you use this mode, each cluster interface joins an IP multicast group, and IPSO bases the cluster multicast MAC addr esses on the IP multicast grou p addresses. The cluster MAC addresses are in the form 01:00:5E: xx:xx:xx, in which the fourth byte is the cluster ID and the last two bytes are the last two bytes of the multicast group address. Y ou can change the default IP multicast group addres ses assigned by IPSO. If you do so, the new addresses must be in the range 239.0.0. 0 to 239.255.255.255. (See RFC 2365 for information about this range of addresses.) If you use this mode, you should enable IGMP snooping and IGMP queries on the switch. If you enable IGMP snooping but do not enable queries, problems can occur when a system leaves and rejoins a cluster . Y ou should configure the switch’ s query intervals to be 30 or fewer seconds to ensure that the switch maintains the cluster multicast gro up properly . On a Cisco switch running CatOS, for example, the default value s for querier interval (QI) and other querier interval (OQI) might be too large, which can cause the switch to re move some of the cluster interfa ces from their multicast group and therefore prevent traf fic from being forwarded.  In forwar ding mode the master cluster no de initially receives all the packets sent to the cluster and decides which node should process the packet. If it decides that another node should handle the packet, it fo rwards the packe t to that node. Otherwise, the master processes the packet itself. Use forwarding mode if the routers and switches on either side of the cluster do not su pport multicast MAC addresses.
5 214 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Do not use this mode if you use PIM in the cluster . Caution Avoid changin g the cluster mode while a cluster is in service. If you change the cluster mode of a single node, the nod e leaves the cluster . If you change the mo de on all the nodes (using Cluster V oyage r or the CCLI), the cluster dissol ves and reforms and is out of service temporarily . Considerations for Clustering Note For information about the re quirements for using NGX in an IPSO cluster , see “Config uring NGX for Clustering.” When you config ure an IPSO clus ter , take into account the co nsiderations ex plained in the following sections. Network Environment  Y ou can use static routin g, OSPF , BGP , or PIM to forward traf fic through a cluster .  If you use static routing, devi ce s that need to send traffic through a cluster must have a static route that uses the appropriate cluste r IP address (internal or external) for the route’ s gateway addre ss. For example, a router on the internal side of a cluster should use an internal cluster IP address as the gateway address.  Nokia strongly recommends that yo u not configure a routing protocol o n the primary or secondary cluster protoc ol interfaces.  Y ou cannot use OSPFv3 in a cluste r .  If you use OSPF , only the master exchanges O SPF messa ges with the external routers.  A cluster cannot use OSPF or BGP to forward traffic over VPN tunnels.  If you use PIM, make sure to use multicast mo de or multicast with IGMP mode. Do not use forwarding mode. See “PIM Support for IP Clustering” in the PIM documentation for additional details about how to configure PIM with clustering.  The following items apply i f you use BGP with a cluster:  Y ou cannot use BGP-4 .  BGP runs only on the master node . If a failover occurs, BGP stops runni ng on the failed master and establishes its peerin g relationships on the new master .  Y ou must configure a cluster IP address as a local address.  Nokia recommends that you config ure BGP so that peer traffic does not run on the cluster protocol interfaces.  If you use a multicast mode, adjacent devi ces (e ither connected directly or through a switch or hub) must be able to accept ARP rep lies that contain a mu lticast MAC address. See “T o
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 215 change ARP global parameters” in the information about configuring interfaces for instructions about how to configure a Nokia appliance to accept these replies. Note If there is no router between the cluster and host syste ms (PCs or workstations), the hosts must b e able to accept ARP r eplies with multicast MAC addresses. Y ou can avoid this requirement by adding a st atic ARP entry to each host that includes the cluster IP address and multicast MAC address of the internal clu ster interface.  If you use a multicast mode, the switches connected to the cluster nodes must be able to forward packets destined for a single (mu lticast) MAC address out multiple switch ports simultaneously . Many switches do this by default.  If you use a two-node cluster , use switches (recommended) or hubs to connect the cluster protocol networks. This will ensure proper fail over in the event that one of the nodes drops out of the cluster . Do not directly connect th e cluster protocol interfaces using a crossov er cable.  For performance purposes, Nokia recommends that you do not use hubs to connect a cluster to user data networks. If possible, use sw itches for these connec tions. (If you need to troubleshoot a cluster that uses a multicast mode, you might want to temporarily replace switches with hubs to simplify your configuration.)  Y ou can create multiple clusters in the sam e LAN or VLAN (broad cast domain). The clusters are distinguished by their cluster IDs. Other Considerations  If a cluster will be in service as soon as it is activated, you should configure and enable NGX on each node before they become part of the cluster . Add nodes to the Check Point cluster (using Check Point software) after they have successfully joined the IPSO cluster .  T ransparent mode is not supported on cluster nodes.  Router services are not supported, with the exception of NTP client.  An IPSO system cannot participate in more than one cluster at one time.  IPSO clusters support:  Multiple internal and exte rnal network connections  10/100 mb or gig abit Ethernet LAN connections  The primary and secondary clus ter protocol ne tw orks should have bandwidth of at least 100 mbps.  IPSO clusters do not support networ k ty pes other than Ethernet. All of the interfaces on a cluster node do not have to participate in the cluster . Interfaces that do not participate in the cluster can be network types other than Ethernet.  All the nodes must have the same number of interfaces participating in the cluster , and the cluster interfaces must be connected to the same networks.  If you configure Gigabit Ethern et interfaces on different IP cluster nodes with di fferent MTU values and also run OSPF in the cluster , OSPF routes are lost if a failover occurs
5 216 Nokia Network Voyager for IPSO 4.0 Refe rence Guide between the nodes with different MTU values.T o prevent this problem, make sure that the MTU values are the same on all cluster n odes with Gigabit Ethernet interfaces. Clustering IP2250 Platforms If you use IP2250 platforms to mak e a cl uster, observe th e following guidelines:  Do not combine an IP2250 with any other mode l in a clust er . That is, the other platform must also be an IP2250. If you incl ude any other IP platform in a clu ster with an IP2250, the other system might not be able to ha ndle the tr affic if the IP2250 fails.  Y ou should not configure more than two IP2250 appliances in a cluster .  Nokia recommends that you ag gregate two of the built-in 10/ 100 Ethernet management ports to create a 200 mbps logical link and configure NGX to use this network for firewall synchronization traf fic. If you use a single 100 mbps connection for synchron ization, connection information mi ght not be properly sy nchronized when the ap pliance is handles a large number of connections. Note Use Ethernet crossover cables to connect th e built-in 10/100 managem ent ports that you aggregate. Using a switch or a hub c an result in incomple te sy nchronizatio n.  If you use aggregated ports for fi rewall synchronization traffi c a nd delete a port from the aggregation group b ut do no t delete the group itself, be sure to de lete the corresponding port on the other IP2250 system. If you delete a port on one system only and that port remains physically an d logically enabled, the other system will continue to send traffic to the deleted port. This traf fic will not be received, and firewall synchronization will therefore be incomplete.  Follow these guidelines when yo u configure the remaining built-in Ethernet management ports:  Use one of the management ports exclusivel y for the p rimary cluster protocol network.  Use a separate management port for the following purposes, if necessary:  management connection  log server connection  secondary cluster protoc ol network  Use a switch or hub to conn ec t the se ports . Do not use crossover cables to connect any interfaces other than those us ed for firewall synchronization. Caution The management port s are not suita ble for forwarding production data traffic—do not use them f or this purp ose.  Follow these guidelines when you configure the ADP I/O ports:  Do not use ports on IP2250 ADP I/O cards fo r cluster protocol or firewall synchronization traf fic. Doing so can cause inst ability in the cluster or connect ions to be
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 217 dropped in the event that th ere is a failover . The ADP I/ O ports should be used for production traffic.  Y ou can aggregate the ports on ADP I/O cards and use the aggregated links for production traffic. If you aggregate ports on ADP I/O cards, observe the following guidelines:  Y ou can connect the aggregated ports us ing a switch, h ub, or crossover cable.  Do not include ports on di fferent ADP I/ O cards in the same aggregation group.  Do not combine any of the built-in 10/100 Ethernet management ports with ports on an ADP I/O card to form an aggregation g roup. If Y ou Do Not Use a Dedicated Primary Cluster Protocol Network If your primary cluster prot ocol network also carries production traffic, IPSO’ s cluster protocol messages are propagated throughout the production networks. This happens whenever you use the same physical links for cluster protocol traffic and pr oduction traffic--tha t is, it occurs even if you use VLANs (trunking) to segregate the traffi c. This is an unproductive use of band width because cluster protocol messages are used only by IPSO cluster nodes. Y ou can prevent the cluster protocol messages from being spread across the production networks by using multicast mode with IGMP and connecting the networks with switches that use IGMP snooping. Y ou usually need to enable IGMP for specific switch ports or VLANS. (See “Clustering Modes” for more information about multicast mode with IGMP .) IPSO sends out IGMP membership reports for the cluster protocol multicast gr oup. A switch using IGMP snooping will then forward cluster pr otocol messages only to group nodes—that is, the other cluster nodes. It will not forward the cl uster protocol traffic to ports that are not connected to cluster nodes. The ideal configuration is to physi cally separa te the production and primary clu ster protocol networks (connect them usin g di fferent switches). If you configure a cluster this way , the cluster protocol messages will not appear on your produc tion networks even if the switches on the data networks do not support IGMP snooping . This configuration is preferable to using separate VLANs on one switch to separate the networks. Caution Do not use a secondary cluster protocol ne tw or k for production traf fic. If a secondary cluster protoc ol ne two rk fails bu t the prim ary remains functional, the cluster remains active but traffic to non-clu ster devices on the secondary network might fail. Upgrading IPSO in a Cluster This section explains how to crea te and configure an IPSO cluste r . It incl udes information about upgrading from IPS O 3.6 if you have created clusters with 3.6 and also explains how to add nodes to a cluster .
5 218 Nokia Network Voyager for IPSO 4.0 Refe rence Guide For All Upgrades When upgrading a cluster , make sure that all the nodes run the same vers ions of IPSO (and NGX, when appropriate). If you ar e upgrading bot h IPSO and NGX, you should first upgrade IPSO on all the nodes and then upgrade NGX. Th is approach provides the best continuity of service duri ng the upgrade pr ocess. Upgrading from IPSO 3.7 or Later If you want to upgrade a cluster from IPSO 3.7 or later to a later version of IPSO, Nokia recommends that you u se Clu ster V oyager to upgr ade the IPSO image on all the cluster nodes. See the instructions in “Installing IPSO Images.” The upgraded nodes retain any cluster co nfig ur ation information that was created with the earlier version of IPSO. The hash selection is not used by IPSO 3.8 and NG AI and no longer appears in the Clustering Setup Configuration page. Depending u pon how you upgrade to IPSO 3.8 and NG AI, you might temporarily see this option. If you do you can safely ignore it. On ce the upgr ade is comp lete and IPSO has verified that NG AI is running, the option disappears. Upgrading from IPSO 3.6 Upgrading a cluster from IPSO 3.6 to IPSO 3.7 or later requires a different process because IPSO 3.6 does not have cluster management functionality . If you want to upgrade clus ter nodes from IPSO 3.6 to IPSO 3.8, Nokia recommend s th at you first upgrade all the nodes to IPSO 3.7 and then u pgrade to 3.8. Following this process allows the cluster to remain in service throughout the u pgrade. The upgraded nodes retain any cluster configuration information that was created with the earlier version of IP SO. Note Make sure th at you use a version of NGX that is com patible with the IPSO ve rsion that you upgrade the cluster to. If you are using an incomp atible version of NGX, upgrade to a compatib le version after you upgrade to the later version of IPSO. See the IPSO Release Notes and Getting St arted Guide to find out which v ersions of NGX are comp atible with the version of IPSO you are inst alling. A cluster functions if its master runs IPSO 3.6 an d one or more n odes run IPSO 3.7 or later , but Nokia strongly recommends that y ou upgrade all the nodes of yo u r IPSO 3.6 clusters. IPSO supports a 3.6 master with 3.7 or la ter members to allow a cluster to remain in service during an upgrade. T o upgrade IPSO on cluster nodes and ensure that there are the minimum number of master transitions, follow the steps below . This procedure assumes that you are upgrading a three-node cluster in which node C is the master . Under this procedure, two cluster nodes are in service at all times.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 219 Note Y ou should upgrade the master last. 1. Upgrade node A and restart it. B and C continue to function as a 3.6 cluster . Node A (running the later version of IPSO) rejoins the cluster as a member . 2. Upgrade node B and restart it. Node C continues to function as a 3.6 cluster . Node B (running the later version of IPSO) rejoins the cluster as a member . 3. Make sure that nodes A and B have success fully restarted and rejoined the cluster . Note Performing this steps ensures that there will be no interruption in se rvice when node C restart s. 4. Upgrade node C and restart it. When node C begins to restart, node A or B is selected as the new master and both nodes continue forwarding traf fic. When node C completes the process of restarting, it joins the new cluster . Enabling Cluster Management After you complete the upgrade process, the clus ter is active but you cannot use Cluster V oyager or the CCLI until you create a pas sword for a cluster administrator user on each of the cluster nodes. After you upgrade IPSO on the cluster nodes, you can perform the following procedure to create a password for the cadmin user on each of the nodes. 1. Access the Clustering Setup Configuration page . 2. Click Change cadmin password . The Cluster Management Con figuration page appears. 3. Enter a password for the user cadmin . Note Y ou must use the same password on ea ch nod e tha t you add to th e cluster . This is also the password th at you use to log into Cluster V oyager or the CCLI. 4. Enter the password for cadmin again (for verification). 5. Click Apply . The page displays fields for chang ing the cadmin password. Use this page if you want to change this password in the future.
5 220 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 6. Repeat this procedure on each of the other nodes that you upgraded from IPSO 3.6. Y ou can now manage the cluster using Cluster V oyager or the CCLI. Creating and Configuring a Cluster Configuration Overview T o create and configure a cluster 1. Create a cluster on the first node. 2. Select the cluster mode. 3. Configure the cluster interfaces. 4. Enable or disable firewall monitoring, as app ropriate:  If NGX is running on the node, enable NGX mo nitoring before you make the cluster active.  If NGX is not running on the node, disable N GX monitoring befo re you make the cluster active (so that the cluster ca n be initialized). After the cl uster is active, enable the monitoring so that the cluster monitors the firewall and leaves the cluster if the firewall fails on the node. 5. Deselect any features that should not be cluster sharable . 6. Change the cluster state to up. 7. Save the cluster configuration to disk. 8. If you disabled fire wall monitoring in step 4 , re-enable it. 9. Create cluster con figurations on the other no des. 10. Join the other nodes to the cluster . The failure interval and performance rating are set by default on eac h node and generally shou ld not be changed. See “Configuring the Failure Interval” and “Configuring th e Pe rform an ce Rating” for more information about these features. Y ou must also configure the NGX to work with the IPSO cluster . Use the Check Point client application to add a gateway object for the Noki a appliance. Y ou also must create a gateway cluster object and add the gateway object to it. Refer to the Check Point document ation and “Configuring NGX for Clustering” for details. Creating a Cluster 1. Click High A vailability in the navigation tree. 2. Click Clustering. 3. Enter a cluster ID (0-65535).
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 221 4. Enter a pas sword for the user cadm in. The password must have at least six characters. Note Y ou must use the same password on ea ch nod e tha t you add to th e cluster . This is also the password th at you use to log into Cluster V oyager or the CCLI. 5. Enter the password for cadmin again (for verification). 6. Click Apply . 7. Click Manually Configure IPSO Cluster . Configure the cluster as explained in the following sections. Selecting the Cluster Mode Select the cluster mode that is appropriate for your scenario:  If the routers and switches on either side of the cl uster support multicast MAC addresses, you can use multicast mode or multicast mode with IGMP . These modes usually offer better throughput because they mak e better use of the bandwidth of the pro duction networks. Note Y ou must use one of the multicast mo des if you use PIM in the cluster .  If the routers or switches adjacent to the cl uster do not support multicast MAC addresses, you must use forwardin g mode. Caution Do not use for warding mode if you use PIM in the cluste r . Configuring the W ork Assignment Method A cluster initially balances its wo rk load by automatically distri buting incoming traffic between the nodes. Use the work assignment setting to gove rn whether the cluster can rebalance the load of active connections by moving them between nodes.  For optimum load balancing, use the dynamic setting. This setting allows the cluster to periodically rebala nce the load by mo ving active connections between nodes.  Setting the work assignment to static preven ts the cluster from m ovi ng active co nnections between nodes. It does not ensure stickiness or connection symmetry . Y ou must use static work assignment if you use any of the following NGX features:  Floodgate-1.
5 222 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Sequence V e rifier .  Wo r m C a t c h e r  Delayed notification of connections  Security servers  IP pools (with non-Check Poin t gateways or clients). See “Supporting Non-Check Point Gateways and Clients” for related information. If any of the requirements for static work assi gnment apply to your cluster , you shou ld use this setting. For ex ample, you should use static work assign me nt if your cluster supports both of the fo llowing:  VPNs with Check Point gateways (static work assignment not required by this alone)  VPNs with non-Check Point gateways with IP pools (static work assignment required) Configuring an Interface T o activate the cluster protocol, you must select at least two Ethernet interfaces. One of the two must be an internal or external interface (not a primary or secondary cluster interface). The other interface must be the primary interface. Note Nokia recommends that you select anoth er interface as a secondary cluster protocol interface. Remember th at the primary and secondary cluster protocol networks should not carry any production traf fic. The Interfaces Configuration table lists all the Etherne t interfaces on the system that are configured with IP addresses. Th e table displays the status and IP address of each interface. T o add Ethernet interfaces to this list or to ac tivate inactive interfaces, go to the Interface Configuration page. T o include an interface in the cluster 1. In the Select column, select Y es. 2. Enter the cluster IP address. The address must be in the same network as the IP address of the interface you are configuring. This is a common IP address that each node will share. 3. Repeat the above steps for the rest of the interfaces that will participate in the cluster . 4. For the interface that will serve as the primary cluster prot ocol i nterface for the node, click the Y e s button in the Primary Interface column. The primary interfaces of all the cluster nod es must belong to the same network. This network should not carry any other traf fic. 5. For the interface that will serve as the secondar y cluster protocol interface for the no de, click the Y es button in the Secondary Interface column.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 223 The secondary interfaces of all the cluster no des must belong to the same subnet. This subnet should not carry any other traffic unl ess you use it to carry firewall synchronization traffic. (See “Configuring NGX for Clustering” for information about selecting the firewall synchronization network.) S econdary interfaces are optional. 6. If you are using multicast with IGMP mode and do not want to use t he default IP multicast group address, enter a new address in th e range 239.0.0.0 to 239.255.255.255. 7. Click Apply . Configuring Firewall Monitoring Use the option Enable VPN-1 NG/FW -1 monitoring ? in the firewall table to specify whether IPSO should wait for NGX to start before the syst em becomes a node of a cluster—even if it is the only node of the cluster . (This is particularly relevant if a cluster node is rebooted while it is in service.) This option also specifies whethe r IPSO should monitor NGX and remove the node from the cluster if the fi rewall stops functioning. T o enable firewall monitoring, click enable next to Enable VPN-1 NG/F W -1 monitoring? in the firewall table. If NGX is not running at the time you change the cl uster state to up, click Disabl e next to Enable VPN-1 NG/FW -1 monitoring? If NGX is not runn ing and you do not disable firewall monitoring, you cannot initia lize the cluster protocol. Note Be sure to en able firewall mo nitoring befor e you put the cluster into service (assum ing that you are using NGX) . Supporting Non-Check Poin t Gateways and Client s If your IPSO cluster will create VPN tunnels with non-Check Point gatewa ys or clients, Click the option for enabling non-Ch ec k Poi nt gateway and client support on the Clustering Setup Configuration page and the n perform the following proce du r e: 1. If you want to support non-Check Point clients, click the option for enabling VPN clients. This is all you have to do. 2. If you want to support non-Che ck Point gateways, enter the approp riate tunnel and mask information, as ex plained in “Configuring VPN T unnels.” 3. If you want to support IP pools , fo llo w the instructions in “Configuring IP pools in Cluster V oyager .”
5 224 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring VPN T unnels If you want the cluster to support VPN tunnels in which non-Check Point gateways participate, you must configure the tunnels in V oyager (on the Clustering Setup Configuration page) as well as in NGX. Perform the following procedure: 1. In the Network Address field under Add Ne w VPN Tunnel, enter the remote encryption domain IP address in dotted-d ec imal format (for example, 192 . 16 8.50.0). 2. In the Mask field, enter the mask value as a number of bits. The range is 8 to 32. 3. In the T unnel End Point field, enter the ex ternal address of the non-Check Point gateway . 4. Click Apply . The VPN Tu nnel Information table appears and displays the information yo u configured. 5. If there is more than one network behind the non -Check Point gateway , repeat these steps for each network. In each case, enter the external address of the non-Check Point gatewa y as the tunnel end po int. If o ne o f th e networks behi nd a non-Check Po int ga teway is not encrypted (for example, a DMZ), set its end point to 0.0.0.0. Note See “Clustering Example With Non-Check Point VPN” for an exam p le of co nf iguring a cluster to support a VPN with a non-Check Point gateway . Using IP Pools IPSO clusters support the use of IP pools (addr ess ranges), which are useful for solving certain routing problems. For example, you might want to use an IPSO cluster (and NGX) to create a
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 225 VPN but not want to route unencrypted traf fic through the cluster . For this purpose, you can use a configuration similar to the one shown in the following diagram: The purpose of this configuratio n would be to route th e outgoing unencrypt ed traffic through the default gateway and route the outgoing encrypted traffic through the clu s ter . Traf fic that passes through the cluster is NA T ed so that the source ad dress of a packet is translated to one of the addresses in the IP pool of the clus ter node that hand les the connection. How you configure IP p oo ls depends on whether a non- Che ck Point gateway participate s in the VPN:  If the other end of the tunne l is also a Chec k Po int gateway , you do not need to configure the IP pools in IPSO. Simply follow the instructions in “Using IP Pools When Only Check Point Gateways Are Involved.”  If the other end of the tunnel is not a Check Po int gateway , you must follow the instructions in “Using IP Pools When Only Chec k Point Gateways Are Involved” and also configure the IP pools in IPSO, as explai ned in “Configuring IP pools in Cluster V oyager .” Using IP Pools When Only Check Point Gateways Are Invo lved T o set up the configuration shown in the previou s diagram, you would :  Configure the IP pools in NGX.  On the internal router:  create a default route to the Internet with 192.168.1.1 (the default gateway) as th e gateway address.  create static routes to the IP pool netw orks with the internal cluster IP address (192.168.1.10) as the gateway address. Do not use the real IP addresses of the internal VPN Traffic Firewall A IP Pool: 10.1.2.0/24 Firewall B IP Pool: 10.1.3.0/24 Internal Cluster IP Address 192.168.1.3 192.168.1.2 Primary Cluster Protocol Network 192.168.3.0 192.168.3.1 192.168.3.2 Internal Router 192.168.1.10 192.168.1.10 Internet Default Gateway 192.168.1.1 192.168.1.0 Unencrypted Traffic
5 226 Nokia Network Voyager for IPSO 4.0 Refe rence Guide cluster interfaces (192.168.1.2 and 192.168. 1.3) as gateway addre sses. In the example network, the internal router has the following static routes:  route: 10.1.2.0/24, g ateway: 192.168.1.10  route: 10.1.3.0/24, g ateway: 192.168.1.10 Configuring IP pools in Cluster V oyager If you want to use IP pools with a VPN in wh ich a non-Check Point gateway participates, you must configure the pools in IPSO as well as in NGX. Y ou must configure all the pools on a ll the nodes, so it is easiest and less error prone to us e Cluster V oyager (or the CCLI) for this task. T o configure IP pool s in Cluster V oyager , follow this procedure after you enable support for non- Check Point gateways: 1. In the Network Address field under Add New IP Pool, enter the network that the IP poo l addresses will be assigned from. If you were configuring firewall A in the cluste r shown in the previous diagram, you would enter 10.1.2.0. Note T o ensure routing symmetry , the IP pool netw orks must be dif ferent on different cluster nodes. 2. In the Mask field, enter th e appropriate subnet mask. If you were configuring firewall A in the cluste r shown in the previous diagram, you would enter 24. 3. In the Member Address field, enter the real IP address of the primary cluster protocol interface. If you were configuring firewall A in the cluste r shown in the previous diagram, you would enter 192.168.3.1. Configuring Join-T ime Shared Features Y ou may want to have many configuration setti ngs be identical on each cluster node. V oyager makes this easy for you by letting you specify wh ich features will be configured the same on all cluster nodes. The features that are configured this way are called join-time shared featur es . Their configurations are shared when:  A system joins (or rejoins) the cluster . In this case, the joining system receives the settings of the shared featu r e s.  A new master is selected. In this case, all the members receive the settings of the shared features from the master . This occurs in either mode when the original master leaves the cluster (for example, if it is rebooted). It can also occur in forwarding mode if you manually adjust the performance rating or if a system w ith a higher rating becomes joins the cluster . See “Configuring the Performance Rati ng” for more information.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 227 In addition to h elping you make sure that all cluster nodes are co nfigured consiste ntly , using this feature makes the configuration process easier and faster . The list of shared features should be specified only when you set up a cluster . Once the cluster is operational, yo u should avoid changing wh ich f eatures are cluster sharab le . The basic approach to follow is: 1. Configure the first node. 2. Join the other systems to the first node so th at t hey all copy the shared settings from the same source. What is Sharable? Join-time shared features are not directly related to clustering itself. They are feature s used on an IPSO system regardless of whet her it is part of a cluster . For example, if you want each cluster node to have the same static routes, you configure the static routes on the first cluster node and make su re that static routes are selected as a sharable feature. When other nodes become part of the clus ter , those routes are configured on them also. If the system that is joining the cluster already has static routes configured, they are retained. The routes copied as a result of the joining pr ocess are added to the list of static routes. Note Beginning with IPSO 4.0, Mo nitor Report Configuration and System Logging are no long er sharable fe atures. What if Settings Conflict? If there is a conflict between configuration settings on the existing node and the joining system, the settings on the joining system are changed to those of the ma ster node. For example, assume that you have a cluster with node s A (the maste r) and B in which DNS is a shared feature and the domain name on node A is company- name.com. If a third node (C) joins the cluster and its domain name is foobar .com be fore it joins, foobar .com is replaced by company-name.com during the joining process. If you change the doma in name on node C back to foo ba r .com , the domain name remains foobar .c om unless any of the following occurs:  Node C leaves a nd re joins the cluster .  Nnode B becomes the master .  A cluster administrator user changes the do main name (while lo gged into any node). In the first two situations, node C will once again copy t he settin gs for all the join-time shared features, and company-name.com will replace foobar .com as the domain name. In the third situation, the doma in name is changed on all the nodes. If you want to be able to eas il y reset the configuration of node C to what you had configu red manually , simply save the desired configuration on C. If the active configuration changes
5 228 Nokia Network Voyager for IPSO 4.0 Refe rence Guide because of join-time sharing, you can reload the desired configuration on C from the saved configuration file. See “Managing Co nfig uration Sets” for information abou t saving and loading configuration files. If node C becomes th e master in the previous example, then its settings for join-time shared features are copied to the other nodes. For example, foo bar .com would replace company- name.com on nodes A and B. Caution Be aware th at if node C becomes the master in this sce nario, its settings override conflicting settings on the ot her nodes, which cou ld result in configuration issues. The best practice is to avoid conflicts in the configurations of join-time shared features. If a feature on a joining system has a setting and th e feature is not configured on the master , the joining system retains its setting. For example, assume that you have a two node cluster in which DNS is a shared feature but no domain name is co nfigured on the master . If a third system joins the cluster and its domain name is foobar .com before it joins, it re tains that domain name after it joins. Configuring Features for Sharing Follow these steps to ensure that the appropriate configuration settings are identi cal on each cluster node: 1. After you create a cluster configur ation on the first node, make sure all the relevant settings are correct (on the Cluste ring Setup Configuration page). 2. Scroll to the bottom of the Clustering Setup Co n figuration page and click No next to any features that should not share settings across the cluster . Caution After you cli ck Apply (the next step) , you cannot conven iently ma ke features sharable again if you make them unshared in this st ep. Make sure that the settings are correct before you proceed. 3. Click Apply . If you want to make more features unshared after you click Apply , simply click No next to them and click Apply again. If you chan ge your mind and want to share features that you previously chose not to share, you mu st de lete the cluster and create a new one with the desired settings. Once the cluster is active, you see the following me ssage each time you log into a cluster node as a system user and navigate to a configuration page of a feature that is cluster sharable: This feature is associated with cluster id 10. Any changes made would be local to this cluster node only. The changes may be overwritten by cluster configuration. This message alerts you that se ttings for this feature can be ch anged by a cluster administrator .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 229 After Y ou Create a Cluster Whenever you use Cluster V oyager (or the CCLI), you can remove features from the list of ones that are cluster sharable . Y o u ca n do this on any node. However , Nokia recommen ds that you avoid doing this. Y ou should set up the appropri ate feature sharing when you create a cluster and then leave it unchanged. If a feature is shared and you want to reconfigur e it on all the cluster no des, u se Cluster V oyager or the CCLI. Any ch anges you make are im plemented on all the nodes automatically . Making the Cluster Active Nokia recommends that you configure a firewall an d o r VPN on the node before you activa te the cluster . For more information, see Check Point FW -1 do cumentation and “Configuring NGX for Clustering.” Note If you do not configure a firewall on the node befo re you activate the cluster , you must click disable next to Ena ble monitoring of VPN-1/FW - 1? before you activate the cluster . After the cluster is active, change this settin g to enable. When this is set to ENABLE , the clu ster monitors the firewall. If the firewall fails on a node, that node drop s out of the cluster and stops forwarding traffic. Before you activate the cluster , click Save to st ore all the clus ter configuration settings in the configuration database on the hard disk. T o make the cluster active, click Up in the Cl uster S tate field of the Cluster S tatus table. Y ou can make the cluster ac tive only if the node has:  No VRRP or router services.  At least two configured interfaces participa ting in the cluster , including one primary interface. Y ou receive error messages if the node does not meet these requirements. Adding a Node to a Cluster It is very easy to add Nokia appliances to an existing cluster . There are tw o methods you can use:  Joining (automatic configuration). This is the recommended method because:  The only tasks you must do on the joining systems are:  Configure interfaces with IP addresses in each of the networks the cluster will connect to  Supply an IP address (a real addresses or a cluster IP address) that is already part of the cluster when joining the cluster
5 230 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Manual configuration. If you use th is method, you must supply more in formation so that the system can join the cluster . Ma nually ad ding nodes is v ery si milar to the process of creating a cluster configuration on the first node, and you must make sure to enter the appropriate settings identically to how you en tered them on the first node. If you add a node manu ally , do not make an y cha nges under Join-Time Shared Feature Configuration. Y ou might want to add a node manually if both of the fol lowing conditions are true:  The existing nodes are running N GX and fi rewall monitoring is enabled on them.  NGX is not running on the system you are adding. If you try to add the system to the cluster using the join method under these conditions, it will not join because NGX is not running on it. In this situation you could manually add the system to the cluster by disa bling its firewall monitoring. Caution For security reasons, yo u should never ad d a system that is not running NGX to a cluster that is in service. This sh ould only be done in a test envir onment. Recommended Procedure Nokia recommends that you f ollow this general procedur e when building a cluster: 1. Fully configure the first cluste r node and make sure that all the appropriate features are cluster sharable. 2. Make sure that all of the join-time shared f eatures are configured appropriately on the first node. Remember that joining nodes inherit the configuration settings for each cluster sharable feature. 3. Create a cluster on another system. 4. Join the other system to the cluster . Note This is the most ef ficient approach to buildin g a cluste r and will configure all the cluster nodes consistently .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 231 Joining a System to a Cluster T o join a system to a cluster , perform this simple procedure: 1. Display the Interface Configuration page. 2. Configure interfaces with IP addresses in each of the networks used by the cluster and activate the interfaces. 3. Click T op. 4. Under T raffic M anagement Configuration, clic k Clustering Setup to display the Clustering Setup Configuration page. 5. Enter the ID of the existing cluster . 6. Enter the password for the user cadmin in both password fields. Note This must be the same pass word that you entered for cadmin when you created the cluster on the first node. 7. Click Apply 8. In the Cluster node address field, enter an IP address that meets the following c riteria:  Y ou should use an address of an interface on the cluster node that you configur ed first . Note Using an interface on the first system that you configured fo r clus te rin g ea ch time you join another system will make sure th at all nodes are conf igured appropriately .  The interface m ust be one of the cluster interfaces.  Y ou should use the “real” address of the in terf ace—not its cluste r IP address. (If the cluster is in forwarding mode and you supply a cluster IP address for joining purposes, the joining system will copy configuration settings from the master node, which might not be the one you want to copy the settings from.) 9. Click Join.  If the node successfully joins the cluster , V oyager displays a num be r of new fields.  If the node does not successfully join the cluster , you see a message indicating why . Correct the problem and attempt the join again. Managing a Cluster Y ou can choose between two different approaches to mak ing configuration changes on cluster nodes:
5 232 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Y ou can make changes that are implemented on all the nodes simultaneously . T o mak e changes in this way , you use Clus ter V oyager or the CCLI. (See the IPSO CLI Refer ence Guide for information abou t using the CCLI.) Note Nokia recomme nds that you us e Cluster V oyager or the CCLI to change cluster s ettings or to make changes to join-time sha red features.  Y ou can make configurati on changes on individual no des. If you want to make the same changes on other nodes, you must log into th em (as a system user) and make the same changes. There are some features that can be mo dified only by l ogging into individual no des as a system user . These are explained in “Removing a Node from a Cluster ,” “Changing Cluster Interface Configurations,” and “Deleting a Cluster Configuration.” Note If a feature has been specified as cluster sharable and you chan ge its configuration while logged into a node as a system user , the change is implemented on that node only . Making changes this way can lead to c onfusing or inco nsiste nt configurations. See “Cluster Administrator Users” for more information about ho w different users can ma nage clusters. Using Cluster V oyager Y ou can perform the tasks explained in th is section using Cluster V oyager or V oyager . Nokia recommends that you use Cluster V oyager whenev er possible. Doing so facilitates confi guration tasks and helps ensure that your cluster is configured consistently and correctly . T o start Cluster V oyager 1. In your browser ’ s address or URL field, enter an IP address of a system that is participating in the cluster or the appropriate shared cluster IP address (for example, th e internal cluster IP address). If you enter a shared cluster IP address, the master node responds. 2. Enter the user name and password of a cluster administrator user ( cadmin by default). Note If you forget the cadmin password, follow th e instructions in “If Y ou Forget the cadmin Password.” If either of the following conditions are true , you can log into Cluster V oyager , but you cannot make configuratio n changes unless you break the configuration l ock:  Someone else is logged into one of the cluster nodes as a sy stem user (using V oyager or the CLI) and has acquired an exclusive configuration lock
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 233  Someone else is logged into Cluster V oyager or the CCL I and has acquired an exclusive configuration lock If someone else has acquired an exclusive configuration lock when you attempt to log in and acquire a lock, V oyager will display a “permission denied” message and ask you to log in again. If you want to break the lock acquired by the other user , see “Obtaining a Configuration Lock” on page 25 for more information. If Y ou Forget the cadmin Password If you forget the password for the cadmin user , you are not able to start Cluster V oyager . T o recover from this situati on, follow these steps: 1. Log into one of the cluster nodes as a system user using a comma nd line session. 2. St art the CLI by entering clish 3. Enter set user cadmin oldpass “” newpass new_password The new password must have at least six characters. 4. Log out of the CLI by entering exit 5. Repeat step 1 through step 4 on the other cluster nod es. 6. Log into Cluster V oyager using the new password. Cluster Administrator Users Y ou can create users and ma ke them cluster admini strators by assigning them a cluster role using Role Based Administration. Be aware of the following constraints:  Y ou must log in as a system user to use Ro le-Based Administration—this feature is not accessible if you log in as a user with a clus ter role. (This is also true if you log in as cadmin .)  If you do not assign the default cluster administ rator role (clusterAdminRole) to the users you create, be sure to assign them a role of ty pe Cluster . The implications of this choice are explained below .  Users with the role clusterA dminRole automatically log in to Cluste r V oyager or the CCLI and have full access to all clustering features.  Users with the role type Clus ter automatically log into Clus ter V oyager or the CCL I and have access to the features that you assign to the role.  T o allow a user to administer a cluster , you must assign them the domain value that matches the appropriate cluster ID.  If you want to log into a node as a cluster admi nistrator , you must create the user on that node. That is, if you create a cluste r administrator user on node A but not on node B, you cannot log into node B as this user . However , any changes that you make to node A u sing
5 234 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Cluster V oyager or the CCLI are also implemented on node B. (Y ou can log into all nodes as cadmin because this user is created automatically on each node. ) Note If you assign the Clustering feature to a user with the role type System, that user can configure cluste ring on individual nodes but ca nnot use Cluster V oyager or the CCLI. See “Role-Based Administration” on page 293 for more information about creating and assigning roles. Monitoring a Cluster If you click Monitor on the Cluster V oyager home page, you see a number of links to pages that you can use to monitor the statu s of the cluster . These pages present status information for all the nodes. For example, the IPSO Cluster Process Utilization page sh ows the status of processes on each node. Configuring the Failure Interval The failure interval is used t o determine whet her a node should leave the cluster because it cannot synchronize quickly en ough with the othe r nodes. If a n ode does not receive cluster protocol information (over the primary or secondary cluster protocol network) fo r this length of time, it leaves the cluster and atte mpts to rejoin it. Y ou might ne ed to adjust this value if congestion on the primary or secondary network cau ses nodes to repeatedly leave and rejoin the cluster (though the cluster protocol attempts to pr event this situation by sending data at shorter intervals if it detects delays). T o change the number of milliseconds the node waits before assuming cluster breakup, enter a number in the Failure Interval fi eld, then click Apply and Sav e. Configuring the Performance Rating The performance rating is a meas ure of a cl uster member's throughput and performance capabilities. The higher the rating, the more wo rk a cluster member is capable of doing. In forwarding mode, cluster members use the pe rformance rating to elect the best performing system as the master . The cluster master receives all the packets for the cluster first, so the performance of the master affect s the performance of the whole cluster . If a joining system has a higher rating than the other nod es, it becomes the master . If more tha n one system have the same performance rating, the first system to join the cluster is the master . The cluster master takes the performance rating of the members into account when as signing workload (in all modes). Nodes with higher performa nce ratings receive a larger share of the workload than lowe r performing nodes. The default performance rating for a system reflects its perfo rmance relative to that of other Nokia platforms. Y ou can adjust the performance ra ting to change the amount of work a system is assigned relative to other members. If a cl uster uses forwarding mode, you can adjust the
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 235 performance rating to force a particular node to be the master (which will also have the ef fect of giving that node a lar ger share of work). T o change the performance rating, enter a number in the Performance Rating field (the range of values is 0 throu gh 65535), then click Apply and Save. If you change the master by adjusting the perform ance rating, or if the ma ster changes because a joining system has a higher rating t han the other nodes, the settings of join-time shared features are propagated across the cluster at that point. The settings on th e new master are replicated on the other nodes. Note Do not change the performance rati ng of the master to 0. This will cause the traf fic load to be distributed un eq u ally acro ss th e clu ste r . Note After you click Apply , you might see a message th at reads Joining in pr og ress. If so, r efresh your browser . The message disappears and yo u can proceed by clicking click Apply and then Save. Managing Join-Time Shared Features Y ou can change the conf iguration settings of j oin-time shar ed features while logged in as a system user (user with the role type System) or a cluster administrator , but the results are different:  When you log in as a cluster administrator (and use Cluster V oyager or the CCLI) and change a setting of a shared feature, the change is made on all the nodes. For example, if static routes are shared and you add a static route while logged in as a cluster administrator , the route is added to all the cluster nodes.  When you log in as a system user and change a configuration sett in g of cluste r shareable feature, the change is implemented on the node you are lo gged into but not implemented on the other nodes. This i s true even if you are logged into the master node. For example, if static routes are shared and you add a static route while logge d in as a system user , the route is added to the node you are logged into but not the other cluster nodes. Changes made as a cluster administrator overwr ite any conflicting setti ngs made by someone logged into an ind ividual cluster node as a system user . However , nonconflicting chang es made as a system user are not overwritten. For example, if you configure static routes on a node while logged in as sys tem user and later add sta tic routes as a cluster administrator, the latter routes are added to the list of ro utes on that node. The original routes are u nchanged.
5 236 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Nokia recommends that you do not make change s to cluster settings or join-time shared features on individual nodes—use Clu ster V oyager or the CCLI to make these ch anges. This will help you ensure that all the nodes are configur ed consistently . When you log in as a cluster administrator and chan ge a setting of a join- time shared feature, th e change is made across the cluster even if you did not shar e the featur e when you cr eated the cluster . However , systems that join the cluster late r d o not copy the conf iguration settings for that featu re. When you make changes to featur es that you re moved from the list of join-time shared features, you see the following message: This feature is not associated with cluster xxx. Any changes made would be propagated to all the cluster nodes. This message is alerting you to the fact that the change w ill be implemented on all the current nodes but systems that join late r will not implement the change. When you change the time on a node, a message s imilar to the following appears in the log: May 24 12:05:09 baston2 [LOG_NOTICE] xpand[803]: date set May 24 12:07:27 baston2 [LOG_WARNING] kernel: IP Cluster: last keepalive scheduled 530 ms ago This message is expected and does not indicate that there is any problem. Note Some settings of cluster sharea ble features ca nnot be configured as a cluster administrator . For example, you cannot use Cluster V oyage r to set SSH host and ident ity keys. T o configure t hese settings, you must log in to the indiv idual cluster no des as a sys tem user . Inst alling IPSO Images Note Y ou cannot upgrade a cluster directly from IPSO 3.6 to IPSO 3.8 or l ater . Y ou must upgrade from IPSO 3.6 to IPSO 3.7 and then upgrad e to 3.8 or later . If you want to upgrade a cluster from IPSO 3.7 or la ter to a later version of IPSO (or revert to the earlier version), Nokia recommen ds that you use Cluster V oyager to change the IPSO image on all the cluster nodes. T o download and insta ll an image in a cluster , follow these steps: 1. On the Cluster Config uration page, c lick Install New IPSO Image (Upgrade). 2. Use the Cluster New Image Inst allation (Upgrade) pa ge to do wnload the new IPSO image.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 237 If you specify an invalid FTP server or an invalid path to a valid server as the source of the image, Cluster V oyager does not respon d with an error message and displays the following messages instead: New Image installation in progress Please don't perform a cluster reboot until all nodes have finished the upgrade. If IPSO does not also display additional messages indicating that the download is proceeding (there might be a short d elay), th e FTP information might be incorrect. Correct the FTP information if required and begin the download again. 3. After the new image has been successfully installe d on all the nodes, yo u need to reboot the nodes so that they will run the new image. When the system prompts you to reboot the cluster , click Manage IPSO imag es (including REBOOT). 4. On the IPSO Cluster Image Manage men t page, click the Reboot button at the bottom of the page. Note Clicking this button allows you to perform a cluster safe reboot, which ensures that no traffic is dropped while the cluster reboots (see “Rebooting a Cluster” ). If you manually reboot each node by clic king the Reboot but tons associated with the individual nodes, there might be a period in which all the nodes are out of service. 5. On the Cluster Safe Reboot page, click Apply . The upgraded nodes retain any clu s ter co nfig ur ation information that was created with the previous version of IPSO. Rebooting a Cluster When you click Rebo ot, Shut Down System on the main configu ration page in Cluste r V oyager , you see the Cl uster Reboot, Shut Down System pa ge. At the bottom of this page is the Clus ter T raf fic Safe Reboot link. If you click this link and then clic k Apply , the cluster nodes are rebooted in a staggered manner . The process is mana ged so that only one node is out of service at a time. For example, if you reboot a three-node cluster , one of th e nod es controls the rebooting of the other nodes. This node is called the originating node . The originating node reboots each of the other nodes in order . It waits until each node has successfully rebooted and rejoined the cluster before rebooting the next node. Once all the ot her nodes have rebooted and rejoined, the originating no de reboots itself. Note The originating node is the no de that you are lo gged into. It might not be the cluste r master .
5 238 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The following is an illust ration of this process in a three node cl uster with nodes A, B, and C, in which C is the originating node. 1. If the node A restarts successfully and rejoins the cluster , node B restarts. If node A does not reboot and rejoin the clus ter successfully , the cluster reboot process is halted and the remaining two nodes continue functioning. Y ou should investigate and resolve the problem that prevented node A from restarting and rejoining the cluster . 2. If node A successfully restarts and rejoins th e cluster but node B does not complete the process, the cluster reboot process stops and nodes A and C continue functioning as a cluster . 3. If the nodes A and B complete the process, the node C restarts. As soon as it does, one of the other nodes becomes the originati ng node and the cluster continues to fu nction.  If the node C restarts success fully , it rejoins the cluster .  If the node C does not restart successfully , th e other two nodes continue to function as a cluster . Note Y our Cluster V oyager session st ays active thro ughout the process of rebooting the clu ster . Y ou can monitor the process by cli cking Cluster Safe Reboot S tatus. Caution Do not log out of Cluster V oyager , end your browser session, or otherwise br eak your connection with the cluster while a cluster safe reboot is in progress. Doing so causes the nodes that you are not logged in to to leave the cluster . (If you logged into Clu ster V oyager using a cluster IP address, you are l ogged into the master .) If this occurs, manually rejoin the systems to the clu ster . Y ou can also reboot all the cluster nodes simu ltaneously . In this case, your Cluste r V oyager session does not stay active th roughout the reboot process. T o reboot all the nodes simultaneously: 1. On the main configurati on page in Cluster V oyager , click Reboot, Shut Down System. 2. Click Reboot (do not click Clu ster T raffic Safe Reboot). Removing a Node from a Cluster If you want to remove a node fro m a cluster , you must log into the individual node as a system user . 1. On the Clustering Setup Configuration pa ge, change the clus ter state to down. 2. Click Apply . The node leaves the cluster , but the clus ter configuration information is saved. 3. T o rejoin the node to the cluster , simply click Join.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 239 Changing Cluster Inte rface Configurations If you want to change the cluster interface config uration of a node—for ex ample, if y ou wan t to change the primary interface—you must log into the node as a system user . Y ou c annot use Cluster V oyager or the CCLI. Note Any time you make a change to the clu ster in terface configuration, the node leaves and attempts to rejoin the cluster . 1. Log into the V oyage r on the node as a system user . 2. Display the Clustering Se tup Configuratio n page. 3. T o add an interface to the cluster , click Y es in the Select column. 4. T o change the primary interface, click a button in the Primary Interface column. Y ou can select only one primary interface for ea ch node, and the interface you select should be on a dedicated internal ne twork. Click Apply and Save. 5. T o change the cluster IP address for an interfa ce, enter a new IP address in the Cluster IP Address field for that interface, then click Apply and Save. Deleting a Cluster Configuration If you want to delete all the cl uster configuration information an d remove a node from a cluster , you must log into the node as a sy stem user . On the Clusteri ng Setup Configuration page, click Delete. Synchronizing the T ime on Cluster Nodes Y ou probably want to keep the times on the clus ter nodes synchronized. If you run Check Point’ s NGX, be sure to do so to prevent problems with fire wall synchronizatio n. T o make sure that the time is synchron ize d on cluster nodes you must:  Assign the same time zone to each node  Configure NTP so that each node ge ts its time from the same time server Assigning the T ime Zone T o conveniently assign the same time zo ne to each node, follow these steps: 1. Log into Cluster V oyager 2. Under System Configuration, click Local T ime Setup 3. Select the appropriate time zone. 4. Click Apply . All the cluster nodes are now set to the time zone you specified.
5 240 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring NTP There are two approaches to c onfiguring NTP in a cluster:  Using a device outside the cluster as the NTP server . In this case you use the IP address of the ser ver when configuring NTP on the cluster nodes.  Using the cluster master node as the NTP server . In this case you use one of the cluster IP addresses when configuri ng NTP on the cluster nodes. If the master node fails and anothe r node becomes the master , the new maste r becomes the time server . Caution Do not assign a specific node to be the time server for the cluster . If you configure NTP this way and the master node fails, the othe r nodes will not get thei r time from another server . This situation could lead to problems with firewa ll synchronization. The most co nvenient way to set up NTP in a cluster is to use Clus ter V oyager (or the CCLI) because you need to perform th e configuration st eps only one time instead of performing them on each node individually . The instructions prov ided in the following sections assume that you are using Cluster V oyager . Note Nokia recommends that you keep NTP a s a cluste r sharable feature (the default setting) so that if a node leaves and rejoins the cluste r it will automatically obtain the proper NTP settings. NTP Server Out side the C luster If you use a device outside the cluster as the NTP server , do the following steps on the NTP configuration page (you must enable NTP before you can access this page): 1. Log into Cluster V oyager . 2. Display the NTP Configuration page. 3. Enable NTP . After you enable NTP , you see, you see additional options. 4. Enter the IP address of the NTP server under NTP Servers. 5. Make sure that the NTP Master choice is set to No. 6. Click Apply . All the cluster nodes will now learn their time from the time server you specified. 7. Allow NTP traf fic in the appropriate firewall rule.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 241 Using the Master Node as the NTP Server T o configure the cluster master as the NTP server , do the following steps on the NTP configuration page: 1. Log into Cluster V oyager . 2. Display the NTP Configuration page. 3. Enable NTP . After you enable NTP , you see, you see additional options. 4. Enter one the cluster IP addresses under NTP Servers. The cluster IP addresses are the addresses tha t are shared by the interfaces participating in the cluster . 5. Make sure that the NTP Master choice is set to Y es. 6. Click Apply . Configuring NGX for Clustering If the cluster will be in service as soon as it becomes active, you shoul d configure and enable NGX before making the cl uste r active. Y ou must configure NGX appropriately . Follow the guidelines below when configuring NGX to work with an IPSO cluster . Refer to the Check Point document ation for details.  Each cluster node must run exactly the same version of NGX.  Y ou must install and enable exactly the same Check Point pack ages on each node. In other words, each node must have exactly the sam e set of packages as all the other nodes.  When you use Check Point’ s cpconfig program (at the command lin e or through the V oyager interface to this program), follow these guidelines:  Y ou must install NGX as an enforcement module (only) on each node. Do not install it as a management server and enforcement module.  After you choose to install NGX as an enforcem ent module, you are asked if you want to install a Check Point clustering prod uct. Answer yes to this question.  After you choose to install a Check Point clus tering prod uct (and reboot the system when prompted to do so, you should resume usin g the cpconfig program to finish the initial configuration of NGX. One of the options avai lable to you at this point is to enable CheckPoint Secu reXL. Do not enable SecureXL.  Create and configure a gateway cluster object:  Use the Check Point Smart Dashboard applica tion to create a gateway cluster object.  Set the gateway cluster object address to th e external clus ter IP a ddress (that is, the cluster IP address of the interface facing the Internet).  Add a gateway object for each Nokia appliance to the gateway cluster object.  In the General Properties dialog box for the gateway cluster object, do not check ClusterXL.
5 242 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Configure state synchronization:  Enable state synchronization and configure interfaces for it.  The interfaces that you configure for state sync hronization shou ld not be part of a VLAN or have more than one IP address assigned to them.  Enable antispoofing on all the in terfaces in the cluster, incl uding those used for firewall synchronization and clust er synchro nization .  Set the options the 3rd Party Configuration tab as follows:  Set the A vailability Mode of the gateway cluste r object to Load Sharing. Do not set it to High A vailability .  In the pull-down menu, select Nokia IP Clustering.  Check all the available check boxes.  Enable automatic proxy ARP on the NA T Global Properties tab .  In the NA T tab for the gateway object, select Hi de behind IP address and enter the external cluster IP address in the address field. Do not select Hide behind Gateway because this can cause packets to use the “real” IP address of th e interface, not the virtua l cluster IP address.  Add the cluster IP addresses in the T opology tab of the Gateway Cluster Properties dialog box).  Y ou can configure firewall synch ronization to occur on either of the cluster p rotocol networks, a production network (n ot recommen ded), or a dedicated network (avoi d using a production network for firewall synchr on ization). If you use a cluster protocol network for firewall synchronization, Nokia recommends that you use the second ary cluster protocol network for this purpose. Note The firewall synchronization network shou ld have bandwidth of 10 0 mbp s or greater .  Connection synchronization is CPU intensive, and Nokia recommends that you carefully choose which traf fic should have its connec tions synchronized. For example, you might choose to not synchronize HTTP traf fic.  If a cluster can no longer synchro nize new conn ections because it has reached its limit, it can fail. If you see a lar ge number of firewall sync hronization error messages (indicating that the cluster has reached the limit of connections it can synchronize), you can configure VPN-1 to drop conn ections that excee d the limit by entering the follow ing commands at the console: fw ctl set int fw_sync_block_new_conns 0 fw ctl set int fw_sync_ack_seq_gap 128 Entering these commands configures the cluste r to give preference to maintaining the synchronization st ate of the existing connections o ver establishing new connections.  If you use sequence va lidation in NGX, you should be aware that in the event of a clus ter failover , sequence validation is disabled for connections that are tr ansferred to another cluster member . Sequence valida tion is enabled for connections that are created after the failover .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 243 T o enable sequence valida tion in the Check Po int management appli cation and IPSO, follow these steps: a. On the main Configuration pa ge in Nokia Network V oyage r, click Advanced System T uning (in the System Con figuration section). b. On the Advance d System T uning pag e, click the button to enable seque nce validation. c. Enable sequence validation in the Ch eck Point management application. d. Push the new policy to the IPSO appliance. Clustering Example (Three Nodes) This section presents an example that shows how easy it is to configure an IPSO cluster . The following diagram illustrate s the example configuration. This example cluster has three firewall nodes: A, B, and C. T o the devices on either side of the cluster , A, B, and C appear as a single firewall. The following sections explai n th e steps you would perform to co nfigure this cluster . 192.168.1.0 192.168.2.0 Secondary Cluster Protocol Network: 192.168.4.0 Cluster IP: 192.168.4.10 Cluster (ID 10) External Router Primary Cluster Protocol Network:192.168.3.0 Cluster IP: 192.168.3.10 .1 .1 .1 .1 Firewall B eth-s1p1 eth-s2p1 eth-s3p1 eth-s4p1 .2 .2 .2 .2 .3 .3 .3 .3 Firewall A eth-s1p1 eth-s3p1 eth-s4p1 eth-s2p1 Internal Cluster IP External Cluster IP 192.168.2.5 Internal Router 192.168.1.5 192.168.2.10 192.168.2.10 192.168.2.10 192.168.1.10 192.168.1.10 192.168.1.10 Firewall C eth-s1p1 eth-s2p1 eth-s3p1 eth-s4p1 VPN-1/FireWall-1 Synchronization Network
5 244 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring the Cluster in V oyager 1. Using V oyager , log into node A. 2. Display the Interface Configuration page. 3. Configure interfaces with IP addresses in each of the networks shown in the example and activate the interfaces. For example, the IP address for inte rface eth-s1p1 woul d be 192.168.1.1. 4. Click T op. 5. Under T raffic M anagement Configuration, clic k Clustering Setup to display the Clustering Setup Configuration page. 6. Enter ID 10 for the cluster . 7. Enter a password for cadmin twice. 8. Click Apply . 9. Set the cluster mode to multicast with IGMP . This example assumes that you want to u se multicast with IGMP mode to achieve the maximum throughpu t. See “Clustering Modes” for more information about this feature. 10. Configure the clus ter interfaces. a. Click Y es in the Select column of the Interfa ces Configuration table for each appropriate interface. b. Enter each cluster IP address in the appropriate field:  For eth-s1p1, enter 192.168 .1.10.  For eth-s2p1, enter 192.168 .2.10.  For eth-s3p1, enter 192.168 .3.10.  For eth-s4p1, enter 192.168 .4.10. Note The cluster IP address must be in the same sub net as the real IP addr ess of the interface. 11 . In the Primary Interface column, click Y es fo r eth-s3p1 to make it the primary cluster protocol interface for the node. 12. In the Secondary Interface column, click Y es for eth-s4p1 to make it the secondary cluster protocol interface for the node. 13. Under FireW all Related Configura tion, set the firewall check so that IPSO does no t check to see if Firewall-1 is running be fore it activates the cluster . This example assumes that you have not enab led Firewall-1 before co nfiguring the cluster . 14. Make sure that are selected to be shared across the cluster . 15. Change the cluster state to On. 16. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 245 17. Click Save. 18. Configure static routes from this node to the internal and external networks using 192.168.1.5 and 192.168.2.5 as gateway addresses (next hops). 19. On nodes B and C, configure interfaces with real IP addresses in each of the four networks shown in the example. 20. Join nodes B and C to the clus ter . These nodes will copy the config uration information you entered on node A, including the static routes to the intern al and ext ernal networks. Configuring the Internal and External Routers Y ou would also need to perfo rm the following tasks on th e routers facing the cluster: 1. Because the cluster is using multicast mode with IGMP , configure the internal and external routers to accept multicast ARP replies for unicast IP addresses. (This is not necessary if you use forwarding mode.) 2. Configure static routes to the cluster:  On the internal router , configure a static ro utes for 192.168.2.0 (the external n etwork) using 192.168. 1.10 (the internal cluster IP address) as th e gateway address.  On the external router , configure a static ro ute for 192.168.1.0 (the internal netw ork) using the cluster IP 192.168.2.10 (the extern al cluster IP address) as the gatewa y address.
5 246 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Clustering Example With Non-Check Point VPN This section presents an example that shows how easy it is to configure an IPSO cluster to support a VPN with a non-Check Point gateway . The following diagram illustrates the example configuration: This example cluster is very similar to the previous example. The additional elements are:  Hosts in the 10.1.1.0 network (the remote encryption domain) use a VPN tunnel to access the 192.168. 1.x network (connected to the internal router).  The VPN tunnel end points are the external clus ter IP address and the external address of the remote non-Check Point VPN gateway . Here are the step s you would perform to configure the tun nel: 1. Follow the steps under “Configuring the Cluster in V oyager .” 2. Log into the cluster using Cluster V oyager . 3. Click the option for enabling non-Check Point ga teway and client support on the Clustering Setup Configuration page. 192.168.1.0 192.168.2.0 Secondary Cluster Protocol Network: 192.168.4.0 Cluster IP: 192.168.4.10 Cluster (ID 10) Primary Cluster Protocol Network:192.168.3.0 Cluster IP: 192.168.3.10 .1 .1 .1 .1 Firewall B eth-s1p1 eth-s2p1 eth-s3p1 eth-s4p1 Firewall C eth-s1p1 eth-s2p1 eth-s3p1 eth-s4p1 .2 .2 .2 .2 .3 .3 .3 .3 Firewall A eth-s1p1 eth-s3p1 eth-s4p1 eth-s2p1 Internal Cluster IP 192.168.2.5 Internal Router 192.168.1.5 Non-Check Point VPN Gateway VPN Tunnel Tunnel Endpoint (External Cluster IP) Tunnel Endpoint: 10.1.2.5 External Router Internet 192.168.2.5 10.1.1.0 Network 192.168.2.10 192.168.2.10 192.168.2.10 192.168.1.10 192.168.1.10 192.168.1.10 VPN-1/FireWall-1 Synchronization Network
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 247 4. In the Add New VPN T unnel section, enter 10.1.1.0 in the Network Address field. 5. In the Mask field, enter 24. 6. In the T unnel End Point field, enter 10.1.2.5. 7. Click Apply . 8. Click Save. 9. Configure the same tunnel in NGX. For more information, see “Configuring NGX for Clustering” and the Check Point documentation.
5 248 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 249 6 Configuring SNMP This chapter describes the Nokia IPSO impl ementation of Simple Network Management Protocol (SNMP) and how to con figure it on your system. SNMP Overview The Simple Network M anagement Protocol (SNMP) is the Internet standard protocol used to exchange manage ment information betwee n network devices. SNMP works by se nd ing messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themse lves in Management In formation Bases (MIBs) and return this data to the SNMP requesters. IPSO implements UCD-SNMP 4.0.1 as the bas e version of SNMP . Cha nges have been made to the base version to address security and other fi xes. For more information on Net-SNMP , go to http://www .net-snmp.org . Caution If you use SNMP , Nokia strongly recommends that you change the community strings for security purp o se s. If you do not us e SNM P , you should disable the co mm u nit y strings. SNMP , as implemented on Nokia pl atforms, supports the follow ing:  GetRequest, GetNextRequest, GetBulkRequest, and a select number of traps. The Nokia implementation also supports SetRequest for three attributes only: sysContact,sysLocation, and sysName. Y ou must configure a read-write community string to enable set operations.  SNMP v1, v2, and v3. For more information about SNMP v3, see “Managing SNMP Users.” Note The Nokia implement ation of SNMPv3 does not yet support SNMPv3 trap s.  Other public and proprietary MIBs as follows.
6 250 Nokia Network Voyager for IPSO 4.0 Refe rence Guide MIB Source Function Rate-Shape MIB propriet ary Moni toring rate-shaping stat istics and configuration. Monitoring system-specific parameters. IPSO System MIB proprietary Defines the system MIB for IPSO. The IPSO chassis temperature, fan group, a nd power-supply group function only on certain firewalls. IPSO Registration MIB proprietary Defines the obj ect ID (OID) prefixes. OID Regist ration MIB propriet ary Defines the o bject ID (OID) pr efixes. Unit T ypes MIB proprietary Contains OID values for the different types of circuit cards used in Nokia equipment. TCP MIB RFC 2012 Provides management information of TCP implementations. EtherLike MIB RFC 1650 Generic objects for Ethernet-like network interfaces. Host Resources MIB RFC 1514 Provides informa tion about th e system, such as hardware, software, processes, CPU utilizat ion, d isk utilization and so on. IANAifT ype MIB IANA Defines the IANAifT y pe textual conven tio n, including the values of the ifT ype object defined in the MIB-II ifT ab le. IF MIB RFC 2233 Describes generic objects for network interface sublayers IP MIB RFC 201 1 Provides management information for IP and ICMP implementations. IP Forwarding MIB RFC 2096 Displays CIDR multipath IP routes. ISDN MIB RFC 2127 Describes the management of ISDN interfaces. Note : The isdnMibCallInformation trap is not supported by IPSO. VRRP MIB RFC 2787 Provides dynamic failover statistics. RIP MIB RFC 1724 Describes RIP version 2 protocol. SNMP Framework MIB RFC 2571 Outlin es SNMP managemen t architecture. SNMP MPD MIB RFC 2572 Provides message processing and dispatching. SNMP User-based SM MIB RFC 2574 Provides m anagement information definitions for SNMP User-based Security Model SNMPv2 MIB RFC 1907 Defines SNMPv2 entities. Note: The warmS tart trap is not supported. SNMPv2 SMI RFC 2578
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 251 SNMPv2 TC RFC 854 Defines textual conventions for various value s reported in OIDs and Trap s. Dial-Control MIB RFC 2128 Describes peer information for demand access and o ther kinds of interfaces. Note: The dialCtlPeerCallInformation and dialCtlPeerCallSetup tra ps ar e not supported by IPSO. Entity MIB RFC 2737 Represents the multiple logical en tities that a a single SNMP agent supports. IPSO does not support the entConfigChange trap is not supported by IPSO. T unnel-MIB RFC 2667 Provides statistics about IP tunnels. UDP-MIB RFC 2013 Provides statistics about UDP implementations. Frame Relay DTE MIB RFC 21 15 Keeps statistics and errors in one or more circuits of a device implementing Frame Relay . T oken Ring MIB RFC 1748 Check Point MIB proprietary S tatistics and version information on any firewal ls currently installed. 1213 MIB RFC 1213 Contains the original definition of MIB-II. Nokia provides this MIB with the system to ensur e backwards compatibility with SNMP v1. IPSO-LBCluster-MIB proprietary Provides info rmation about IPSO load- balancing systems. HWM MIB proprieta ry Contains ha rdware management information. Note: IPSO does not send the trap s that this MIB supports when the Nokia p latform is used as an IP security d evice. Nokia Comm on MIB OID Registrat ion MIB proprietary Nokia Common NE Role MIB proprietary Nokia Enhanced SN MP Solution Suite Alarm IRP MIB proprietary Note : IPSO does not send traps that this MIB supports when the Nokia platform is used as an IP security device. Nokia Enhanced SN MP Solution Suite Common Definition MIB proprietary Note : IPSO does not send traps that this MIB supports when the Nokia platform is used as an IP security device. Nokia Enhanced SN MP Solution Suite PM Common Definition MIB proprietary MIB Source Function
6 252 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Both the proprietary MI Bs and the public MIBs are supplied with the system. T o view more detailed information about the MIBs, see the /etc/snmp/mibs directory . Note The SNMPv2-CONF MIB resides in the /etc/sn mp/mib s/unsupported directory . The SNMP agent implemented in Nokia IPSO enables an SNMP ma nager to m onitor the device and to modify the sysName, sysCon tact and sysLocation objects only . Note Y ou must configure an SNMP string first to configure sysCont act and sysLocation. Use Network V oy ager to pe rform the following tasks:  Define and change one r ead-only community string.  Define and change one read -write community string.  Enable and disable the SNMP daemon.  Create SNMP us ers.  Modify SNMP user accounts.  Add or delete trap receivers.  Enable or disable the various traps.  Enter the location and cont act strings for the device. SNMP Proxy Support for Check Point MIB IPSO supports the us e of a proxy for SNMP Ge tRequest and SNMP GetNextRequest for Check Point objects. The following are guidelines and limitations you should be aware of. Nokia Enhanced SN MP Solution Suite PM IRP MIB proprietary Note: IPSO does not send traps that this MIB supports when the Nokia platform is used as an IP security device. Nokia NE3S Registration MIB propriet ary Nokia Link Aggregation MIB proprietary Contains the traps required for managing link aggregatio n. Nokia NTP MIB propriet ary SNMPv2-CONF IPSO does not support this MIB but it is i ncluded for those customers who need it to enable the ir management tools. This MIB resides in the /etc/snmp/mibs/unsupp orted directory . MIB Source Function
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 253 Using the Check Point MIB Y ou must use the Check Point version of the Ch eck Point MIB (CP-MIB) text fil e in $FWDIR/ lib/snmp of your network management tool. Do not use the CheckPoint-MIB.txt included in releases before Nokia IPSO 3.7. Whenever IPSO SNMPd is started or restarted, it searches for the CheckPoint-MIB.txt. The following is an example of a message yo u may see as a result of the search: IP650 [admin]# Jan 31 12:17: 19 IP650 [LOG_ERR] snmpd: Cannot find module (CheckPoint-MIB) : At line 1 in (none) Y ou can ignore this message. Any SNMP requ ests to the CP-M IB when the Check Point SNMPd (CP-SNMPd) is not running time out. (The IPSO SNMPd does not resp ond.) The SNMP Proxy support is hard-coded to work only with the CP-SNMPd. It is not a generic proxy that you can use for accessing other MI Bs. If you change the following default configurations, the SNMP Pro xy for the CP-MIB does not work:  CP-SNMPd must continue to run on port 260.  CP-SNMPd must continue to accept SNMPv1 an d have a read community set to “public.”  CP-SNMPd must continue to be accessible th rough “localhost” on the Nokia IPSO device. The SNMP Proxy is not a trap proxy and only proxies SNMP Get and SN MP GetNext requests. When simultaneous SNMP queries arrive, the SNMP Proxy returns valid values to only one request. Because Nokia IPSO uses a proxy to su pport th e Check Point MIB, reference the Check Point documentation for any lim itations of the CP-SNMPd. Using cp snmp_st art Y ou must run the cpsnmp_start script to make sure that CP-SNMP d is running on Check Point versions NG FP1, FP2, and FP 3. Y ou do this by first enablin g the IPSO SNMPd from Nokia Network V oyager and then enablin g the CP-SNMPd by using /bin/cpsnmp_start on the command line. Note Whenever you use the cprest art or cpstop;cpst art commands, you must run the cpsnmp_ start script to restar t the CP-SNMPd when you are using NG FP3. Note Using FloodGate with Check Point NG FP1, FP 2, and FP3 causes SNM P query operations to fail, even on non-FloodGate CheckPoint MI B obje ct s. Y ou must restar t the CP- SNMPd to have SNMP query operations. On NG FP2, just disabling FloodGate migh t not enable
6 254 Nokia Network Voyager for IPSO 4.0 Refe rence Guide SNMP query operations. In this case, you mig ht have to delete the FloodGat e package fro m your system. Enabling SNMP and Selecting the V ersion The SNMP daemon is enabled by default. If yo u choose to use SNMP , configure it according to your security requirements. At minimum, you must ch ange the defau lt community string to something other than public. Y ou should also selec t SNMP v3, rather than the default v1/v2/v3, if your management statio n supports it. Caution If you do not plan to use SNMP to manage the ne twork, disable it. Enabling SNMP opens potential attack vect ors for surveilla nce activi ty by enabling an attacker to learn about th e configuration of the device and the network. Y ou can choose to use all versions of SNMP (v 1, v2, and v3) on your system o r to allow SNMPv3 access only . If your m anagement station supp orts v3, select to use only v3 on yo ur IPSO system. SNMPv3 limits co mmunity access; only reques ts from users with enabled SNMPv3 access are allowed and all other requests are rejected. T o enable or disable SNMP 1. Choose SNMP under Configurati on in the tree view . 2. Select Y es or No for Enable SNMP Daemon. 3. If you are en abling SNMP , click Apply . The SNMP configuration options appear . Caution T o run the Check Point and SNMP daemons simult aneously , you must start the Check Point SNMP daemon after you st art VPN-1/Firewall NG . If you start the Check Point SNMP daemon before you star t VPN-1FireW all-1 NG , the IPSO daemon does not start. 4. From the SNMP version drop-down l ist, select the version of SNMP to run:  SNMPv1/v2/v3 Select this option if your manageme nt station does not support SNMPv3.  SNMPv3 Select this option if your managemen t station supports v3. SNMPv3 prov ides a higher level of security than v1 or v2. 5. If you selected v1/v2/v3, en ter a new read-only community string under Community S trings. This is a basic security precautio n that you should always take.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 255 Note If you select the Disable checkbo x all com munity string s ar e di sable d a nd SNMPv1 and v2 do not function. This has the same ef fect as selecting only SNM Pv3 in the previous step. 6. (Optional). Set a read-w rite community string. Caution Set a read-write community string only if you have reason to enable set op erations, only if you enabl ed SNMPv3 (n ot v1/v2/v3) , and if your network is secu re. 7. Click Apply . 8. Click Save to make your changes permanent. Configuring the System for SNMP When you en able SNMP for your syst em, you can configure the following:  Specify an agent address. See “Setting an Agent Address” on page 255  Configure traps. See “Configuring T raps” on page 2 56. Setting an Agent Address An agent address is a specific IP address at which the SNMP agent lis tens and responds to requests. The default behavior is fo r the SNMP ag ent to listen to and respond to requests on all interfaces. If you specify one or more agent addresses , the system SNMP agent listens and responds only on those interfaces. Y ou can use the agent address as another way to limit SNMP access. For ex ample , you can limit SNMP access to one secure internal ne twork that uses a particular interfa ce by configuring that interface as the only agent address. T o set an SNMP agent address 1. Choose SNMP under Configurati on in the tree view . 2. Enter the valid IP address of a configured interface in the Agen t New Address field. Y ou can use the IP address of any existing and valid interface. 3. Click Apply . The IP address and a corresponding Delete check box appear . 4. Click Save to make your change permanent.
6 256 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note If no agent addresses are specified, the SNMP protocol resp ond s to requests from all interfaces. Configuring T rap s Managed devices use t rap messages to report events to the network management station (NMS). When certain types of events occur , the platform sends a trap to the management station. T raps are defined in text files locat ed in the /etc/snmp/mibs directory:  System traps are defined in the Nokia-IPSO-System-MIB.  The ifLinkUpDown trap is defined in the IF-MIB.  Clustering traps are defined in the Nokia-IPSO-LBCluster-MIB.  Disk mirror traps are defined in the Nokia-IPSO-System-MIB. Below is a list of the objects ass ociated with individual traps. The systemT rapConfiguratio nCh an ge, sy stemT rapConfigurationFileChange , and systemT rapConfigurationSaveCha nge traps are associated with the ipsoConfigGroup objects. These objects include ipsoConfigIndex, ipso ConfigFilePath, ipsoConfigFileDateAndT ime, ipsoConfigLogSize, ipsoConfigL ogIndex, and ipsoConfigLogDescr . The systemT r apDiskMirrorSetCreate, systemT rapDiskMirrorSetDe lete, systemT rapDiskMirrorSyncFailure , and systemT rapDiskMirrorSyncS ucce ss traps are assoc iated with the ipsoDiskMirrorGroup objects. These objects includ e ipsoT otalDiskMirrorSets, ipsoMirrorSetIndex, ipsoMirrorSetSource Drive, ipsoMirrorSet DestinationDrive, ipsoMirrorSetSyncPercent. The linkUp and linkDown traps are associated with the ifIndex, ifAdminStatus, and ifOperS tatus objects. Ta b l e 1 2 lists the types of SNMPv1 and SNMPv2 traps which IPSO supports. Note The Nokia implement ation of SNMPv3 does not yet support SNMPv3 trap s. T able 12 T ypes of SNMP T raps T ype of T rap Description coldS tart Supplies notification when t he SNMPv2 agent is reini ti alized. linkUp/linkDown Supplies notification w hen one of the links, whi ch is administ rat i v el y up , ei t he r come s up or is l ost .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 257 lamemberActive Supplies notification when a port is ad ded to a link aggregati on group. lamemberInactive Supplies notification w hen a port is re moved from a link aggregation gr oup. Authorization Supplies notif ication when an SNMP opera tion is not properly authenticated. Although all implementation of SNMPv2 must be capable of generating this trap, the snmpEnableAuthenTraps object indicates whether this trap is generated. vrrpT rapNewMaster Supplies notification when a new VRRP master is elected. vrrpT rapAuthFailure Supplies notification when an VRRP hello message is not properly authenticated. systemT rapConfiguration Change Suppl ies notification when a different configuration file is selected. systemT rapConfiguration FileChange Supplies notification when a diff erent configuration fil e is selected. systemT rapConfigurationSa veChange Supplies notification when a pe rma nent change to the system configuration occurs. systemT rapLowDiskSpace Supplies notification when space on the system disk is lo w . This trap is sent if the disk space utilization has reached 80 percent or more of its capacity . If this situation persist s, a subsequent trap is sent after 15 minutes. systemT rapNoDiskSpace Supplies notificat io n when the system disk is full. This trap is sent if 2 percent or less of the disk space remains available, or if the remaini ng disk space is equal to or less than 1 MB. If this situation persists, a subsequent trap is sent after 15 minutes. systemT rapDiskFailure Supplies notificatio n when a particular disk drive fails. Note: The systemT rapDiskFailure applies only to Nokia platforms that support disk mirroring. systemT rapDiskMirrorSetCreate Suppl ies notification when a system disk mirror set is created. systemT rapMirro r SetDelete Supplies notification when a system disk mirror set is deleted. systemT rapDiskMirrorSyncSuccess Supplies notif ication when a system disk mirror set is successfully synced. T able 12 T ypes of SNMP T raps T ype of T rap Description
6 258 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure traps, specif y the following information:  The location of the trap recei ver (manag ement station). See “Configuring T rap Receivers” on page 259.  Which types of traps to enable. See “Enabling or Disabling T rap T ypes” on page 259.  An agent address to be included in each trap message sent to the management station to identify which networ k device generated the trap. See “Setting the T rap PDU Agent Address” on page 259.  Location and contact informatio n prov ided to the management system about where yo ur device is located and who to contact a bout it. See “Configuring Location and Contact Information” on page 260. systemT rapDiskMirrorSyncFailure Supplies notificat io n when a system disk mirror set fails during syncing. Note: The disk mirror traps are supported onl y on systems where disk mirroring is supported . clusterMemberReject Supplies notification when a member request to join a cluster is rejected. clusterMemberJoin Supplies notification when a member node joins the cluste r . clusterMemberLeft Supplies notification w hen a member node leaves the cluster. clusterNewMaster Supplies notification when a cluster is formed and a new master is elected. clusterProtocolInterfaceChange Supplies notificat ion w hen a failover occurs from the p rimary cluster network to the secondary cluster network. systemPowerSupplyFailure Supplies notification when a power suppl y for the system fails. Note: For the IP2250, this trap is also sent if one of the power supplies is switched off. This trap incl udes the power supp ly index and is supported onl y on platforms with two power supplies installed and running. systemFanFailure Supplies notif ication when a CPU or chassis fan fails. Thi s trap includes the fan index. SystemOverT emperature Supplies notificatio n when a power su ppl y failure occurs because of high temperature. This trap is followed b y a power supply failure trap that specifies the power supply index that failed. This trap is supported on ly on platforms with two power supplies installed and running systemSnmpProcessShutdown Supplies notification when the status of the SNMP daemon is changed, either turned off or turned on. T able 12 T ypes of SNMP T raps T ype of T rap Description
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 259 Configuring T rap Receivers Y ou must specify the management stati on that accepts traps from your appliance, and the community string used on your manageme nt station (receiver) to control access. T o configure trap receivers 1. Choose SNMP under Configurati on in the tree view . 2. Enter the IP address (or the hostname if DNS is set) of a receiver in the Add New T rap Receiver text field. 3. Enter the community string for the specified receiver in the Community S tring for new T rap Receiver field. 4. Select the T rap SNMP V ersion for the trap receiver in the drop-down menu. The options are v1 or v2, and the defa ult is v1. This is the version of SNMP used by you r management station. 5. Click Submit. Enabling or Disabling T rap T ypes When you enable types of traps, the system se nds a trap message when that type of event occurs. For example, if you enable authorizat ion traps, the system sends a trap message to the management station when it receives a packet with an incorrect community string. T o enable or disable traps 1. Choose SNMP under Configurati on in the tree view . 2. T o enable any type of t rap, click On next to the name of the trap and click Apply . 3. T o disable any type of trap , click Off next to the name of the trap and click Apply . 4. T o make your changes permanent, click Save. Setting the T rap PDU Agent Address The trap PDU address is included in the protocol data unit (PDU) of each trap message sent to the management station that uses it to iden tify which network device generated the trap. This address must belong to a configured interface. If you do not configure an agent address for traps, the sys tem identifies the trap agent address as 0.0.0.0 in SNMP traps (in accordance with RFC 20 89). (For releases of Nokia IPSO previous to 3.7, the default was to use the IP address of the first valid interface.) T o set the trap PDU agent address 1. Choose SNMP under Configurati on in the tree view . 2. T o specify the IP address to be used for sent tr ap PDU, enter the IP addre ss in the T rap PDU Agent Address field. 3. Click Apply .
6 260 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. Click Save to make your changes pe rmanent. Configuring Location an d Cont act Information The settings for location and cont act information provid e information to the management system about where your device is loca ted and who to contact about it. Set the location and contact strings when you perform the initial configuration for SNMP on your system. T o configure location and contact information 1. Choose SNMP under Configurati on in the tree view . 2. In the SNMP Location String text field, enter the actual location of the device. Click Ap ply . 3. In the SNMP Contact S tring text field, ente r the name of department or person wh o has administrative responsibility for the device. 4. Click Apply . 5. Click Save to make your changes pe rmanent. Interpreting Error Messages This section lists and explains certain common error status values th at can appear in SNMP messages. W ithin the PDU, the thir d field can include an error-status integer that refers to a specific problem. The integer zero (0) means that no errors were detected. When the error field is anything other than 0, the next field includes an error-index value that iden tifies the v ari able, or object, in the variable-binding s list that caused the error . The following table lists th e error status codes and th eir correspon din g mean ings. Error status code Meaning Erro r status code Meaning 0 noError 10 wrongV alue 1 tooBig 1 1 noCrea tion 2 NoSuchName 12 inconsistentV alue 3 BadV alue 13 resourceUnavaila ble 4 ReadOnly 14 co mmitFailed 5 genError 15 undoFailed 6 noAccess 16 authorizationError 7 wrongT ype 17 notW ritable 8 wrongLength 18 i nconsistentName
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 261 Note Y ou might not see the codes. The SNMP manager or utility interprets the codes and displays and logs th e appropr iate messag e. The subsequent, or fourth field, contains the erro r index when the error-status field is nonzero, that is, when the error -status field returns a valu e other than zero, which indicates that an error occurred. The error-i ndex value identifies the variable, or object, in the variable-bindings list that caused the error . The first va riable in the list has index 1, the second has index 2, and so o n. The next, or fifth field, is the variable-bindings fiel d. It consists of a sequence of pairs; the first is the identifier . The second element is one of the following five: value, unSpecified, noSuchOjbect, noSuchInstance, and EndofMibV iew . The follo wing table describes each element. GetRequest The following table lists possible value field sets in the response PDU or error-status messages when performing a GetRequest. 9 wrongEncoding Error status code Meaning Erro r status code Meaning V ariable -bindings element Description value V alue associated with ea ch object instance; specified in a PDU request. unSpecified A NULL value is used in retrieval requests. noSuchObject Indicates that the agent does not implement the obje ct referred to by this object identifier noSuchInstance Indicates that this ob je ct does not exist for this operation. endOfMIBView Indicates an attempt to reference an object ide ntifier th at is beyond the end of the MIB at the agent. V alue Field Set Descr ip tion noSuchObject If a variable does not have an OBJECT IDENTIFIER prefix that exactly matches the prefix of any variable accessible by this reque st, its value field is set to noSuchObject . noSuchInstance If the variable's name does not exactly match the name of a variable, its value field is set to noSuchInstance .
6 262 Nokia Network Voyager for IPSO 4.0 Refe rence Guide GetNextRequest The only values that can be returned as the second element in the varia ble-bindings field to a GetNextReque st when an error -status code o ccurs are unSpecified or endOfMibV iew . GetBulkRequest The GetBulkRequest minimizes the number of protocol exchanges by letting an SNMPv2 manager request that the response be as large as possible given the constraints on the message size. The GetBulkRequest PDU has tw o fields that do not appear in the other PDUs: non-repeaters and max-repetitions. The non-repeaters field specifie s the number of vari ables in the variable- bindings list for which a single-lexicographic su ccessor is to be returned. The max-repetitions field specifies the number of lexicographic successo rs to be returne d for the remaining variables in the variable-bindings list. If at any point in the process, a lexic ographic successor does not exist, the endofMibV iew value is returned with the na me of the last lexic ogr aphic successor, or , if there we re no successors, the name of the variable in the request. If the processing of a variable name fails for any reason other than endofMibV iew , no va lues are returned. Instead, the responding entity returns a response PDU w ith an error-status of genErr and a value in the error -index field that is the index of the probl em object in the variable- bindings field. Configuring SNMPv3 IPSO supports the user-based security mo del (USM) componen t of SNMPv3 to provide message-level security . W ith USM (described in RFC 3414), access to the SNMP service is controlled on the basis of us er identities. Each user has a name, an authentication pass phrase (used for identifying the user), a nd an optional privacy pass phrase (used for cryptographically protecting against disclosure of SN MP message payloads). The system uses the MD5 hash ing algorithm to provide authentication and integrity protection and DES to provide encryption (privacy). Nokia recommends that yo u use both authentication genErr If the proce ssing of a variable fails for an y other reason, the responding entity return s genErr and a value in th e error-index field that is the index o f the problem object in the variable-binding s field. tooBig If the size of the me ssage that encaps ulates the generated response PDU exceeds a local limitation or the maximum message size of the request’s source party , th en the response PDU is discarded and a new response PDU is constructed. The new response PDU ha s an error-status of tooBig , an error-index of zero, and an empt y variable-binding s field. V alue Field Set Descr ip tion
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 263 and encryption, but you ca n em ploy them independently by specifyin g one or the other with your SNMP manager requests. The I PSO system responds accordingly . Note Nokia system s do not prot ect traps wi th authentication or encryption. Request Messages Y ou must configure your SNMP mana ger to specify the security you want. If you are using a UCD-SNMP/Net-SNMP based manager , here are the security-related optio ns you can use in request messages: For example, to send an snmpwa lk request from your manager with full protection, you would enter the following command: snmpwalk -v 3 -u username -a MD5 -A password -x DES -X password -l authPriv system_name OID For more information abou t USM, see RFC 3414. Managing SNMP Users SNMP users are maintained separately from system user s. Y ou ca n cre ate SNMP user accounts with the same names as existing user accounts or different. Y o u can create SNMP user accounts that have no corresponding system account. When you delete a system user account, you must separately delete the SNMP user account. T able 13 Security Relate d Options Used in Request Messages Option Description -u name Specifies the user name. -a MD5 Use MD5 hashing for authentication. -x DES Use DES for encryption . -A password Specifies the user ’s password/p ass p hrase. Use for authentication. The password/passphrase must have at least 8 characters. -X password Specifies the user ’s password/passphrase. Use for encryption. The password/passphrase must have at least 8 characters. -l [authNoPriv | authPriv | authPrivReq] Specifies the security level: • authNoPriv : use authenticati on only • authPriv : use authentication an d encryption is enabled • authPrivReq : use authenticatio n and encryption is required
6 264 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o view existing SNMP users, click SNMP un der Configuration > System Configur ation in the tree view and click Manage SNMP Users. Altern atively , you can click the Manage SNMP User Access link located on the Configuration > Sec urity and Access > Use rs page. The admin user or a user with privileges for th e SNMP feature can modify the security level, authentication pass phrase, and pr ivacy pass phrase for existing SNMP users, and cre ate or delete SNMP users. Pass phrases differ from passwords only in length—pass phrases are usually much longer than passwords. Their greater length makes pass phrases more secure. The IPSO implementation of SNMP supports DES and MD5 authentication to automatically generate USM keys. SNMP must be enabled on the system before you can set an SNMP user authentication or privacy pass phrase. Note If you chan ge the securit y level from eit her authPriv or authPrivReq to authNoP riv , the privacy pass phrase is au tomatically deleted. If you change it bac k to authNoP riv , you must supply a pr ivacy pass phrase. T o add an SNMP user 1. Click SNMP under Configuration in the t ree view . 2. Click Manage USM Users. 3. Enter the following inform ation for the new user:  User Name—The range is 1 to 31 alphanumeric characters with no spaces , backslash, or colon characters. This can be the same as a u ser ’ s name for system access, though the SNMP user account is handled as a separate entity .  Security Level. Select from the following:  Authentication Privacy—The user has auth entication and privacy pass phrases and can connect with or without privacy encryption.  Authentication, no privacy—Th e user has only an authentic ation pass phrase and can connect only without privacy encryption.  Authentication and privacy required—The user must connect using both authentication and encryption pass phr ases.  Authentication Pass Phrase—Used to identify the user . Enter a password for the user that is between 8 and 128 characters in length.  Privacy Pass Phrase—Used to cryptographi cally protect against disclosure of SNMP message payloads. Enter a pass phrase that is between 8 and 128 characters in length. 4. Click Apply . An entry for the new user appears in the SNMP USM Users table. 5. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 265 T o delete a USM user 1. Click SNMP under Configuration in the t ree view . 2. Click Manage USM Users at the bottom of the page. The Manage SNMP Users page appears. 3. Select the appropriate Delete check box. 4. Click Apply . 5. Click Save to make your changes permanent.
6 266 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 267 7 Configuring IPv6 This chapter describes the IPv6 features suppor ted by Nokia IPSO and how t o configure them on your system. IPv6 Overview IPv6 is the next generation IP proto co l and is expected to replace IPv4, th e cu rrent IP protocol. The Internet Engineering T ask Force (IETF) form ally began to work on the new protocol in 1994. IPv6 enhances IPv4 in many ways including:  Expanded addressing capabilities  Simplified header format  Improved support for extensions and op tions  Flow-labeling capability  Plug and play autoconfigura tion The IPv6 implementation includes basic featur es specified in IPv6 RFCs and features that support IPv6-capable hosts in a network. IPv6 in cludes a transition mechan ism that allows users to adopt and deploy IPv6 in a diffuse way and provides direct interopera bility between IPv4 and IPv6 hosts. IPSO supports the following features as specified in the corresponding RFCs:  IPv6 Specification (RFC 2460)  ICMP v6 (RFC 2463)  Neighbor Discovery (RFC 246 1, router only)  Basic IPv6 Socket Interface (RFC 25 53), except the following features:  Compatibility with IPv4 nodes  T ranslation of n odename to address  T ranslation of address to nodename  Socket address structure to nodename and servic e name  IPv6 Addressing Architecture (RFC 2373)  IPv6 Aggregatable Global Uni cast Address Format (RFC 2374)  IPv6 UDP support  IPv6 TCP suppo rt
7 268 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  IPv6 over IPv4 T unnel (RFC 2185)  IPv6 over Ethernet (RFC 2464)  IPv6 over FDDI (RFC 2467)  IPv6 over PPP (RFC 2472)  IPv6 over A TM (RFC 2492, PVC only)  IPv6 over ARCNET (RFC 2497)  IPv6 over T oken Ring (RFC 2470)  IPv6 over IPv4 (RFC 2529 )  IPv6 to IPv4 (Internet Draft)  Generic Packet T unneling (RFC 2473, IPv4 th rough IPv6 only)  RIPng for IPv6  Sta t i c R ou t e s  Route Aggregation  Route Redistribution  IPv6 inetd  IPv6 telnet client and server  IPv6 FTP client and server  Utilities (ping, netstat, tcpdump, ndp) Interfaces T o configure IPv6 logical interfaces 1. Click IPv6 Interfaces under Configuration > Sy stem Configuration > IPv6 Configuration in the tree view . 2. Click the logical interface link to conf igure in the Logical column . Example: eth-s1p1c0 3. Enter the IP address prefix in the New IP Addr ess text box and the mask length (in bits) in the New Mask Length text box. The default mask length i s 64. 4. Click Apply . 5. Click Save to make your changes pe rmanent. 6. Click Up at the top of the page to take yo u back to the IPv6 Lo gical Interfaces page. 7. T o enable the IPv6 address, click On in the IPv6 Active field. 8. Click Apply . 9. Click Save to make your change perman en t.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 269 T o delete an IPv6 address 1. Click IPv6 Interfaces under Configuration > Sy stem Configuration > IPv6 Configuration in the tree view . 2. Click the logical interface link to configure in the Logical column for which you want to delete an IPv6 address. Example: eth-s1p1c0 3. Check the delete box next to th e IPv6 address you want to delete. 4. Click Apply . 5. Click Save to make your changes permanent. T o disable IPv6 on an interface 1. Click IPv6 Interfaces under Configuration > Sy stem Configuration > IPv6 Configuration in the tree view . 2. Click Of f in the IPv6 active field ne xt to the name of that interface. Note Y ou cannot disable an IPv6 interface configured fo r a virtual router when the router is in the master sta te. If you try to disable the interfac e when the router is in the master st ate, Network V oyager displays an error message. T o disable the IPv6 interface, you must first delete the interface as a VRRP virtual address. Y ou can, however , disable an IPv6 inter face enabled on a virtual r outer when the router is in a backup state. 3. Click Apply . The list of addresses in the IPv6 address field fo r the specified logical interface disappear . 4. Click Save to make your changes permanent. T o configure neighbor discovery 1. Click Neighbor Discovery under Con fig uration > System Configuration > IPv6 Configuration in the tree view . 2. In the Global Neighbor Discovery Settings field, enter the value for the queue limit in the Queue Limit text box. This value represents the maxi mum number of output packets to be queued while the link- layer destination address is being resolved. 3. In the Global Neighbor Discovery Settings field, enter the value for the unicast retry limit in the Unicast Retry Limit text box. This value represents the number of times to retry Unicast Neighbor Discovery requests. 4. In the Global Neighbor Discove ry Settings field, enter the va lue for the multicast retry limit in the Multicast Retry Limit text box. This value represents the number of times to retry Multicast Neighbor Discovery requests. 5. In the Global Neighbor Discovery Settings fi eld, enter the value fo r the duplicate address detection retry limit in the Dup licate Address Detection Retry Limit text box. This value
7 270 Nokia Network Voyager for IPSO 4.0 Refe rence Guide represents the number of times to retry Dupl icate Address Detection Neighbor Discovery requests. 6. In the Permanent Ne ighbor Discove ry Entries field, enter the pe rmanent IPv6 address for the permanent neighbor discovery destination in the New Perman ent Neighbor Discovery Entry text box. 7. Click Apply . 8. Click Save to make your changes pe rmanent. 9. T o flush current dynamic Neighbor Discovery entries, click Flush in th e Dynamic Neighbor Discovery Entries field. 10. Click Apply . IPv6 and IPv4 Comp atibility Configuring IPv6 in IPv4 T unnels If your IPv6 traf fic needs to travel through IPv4 ne tworks to reach its destin ation, you need to set up a virtual link by configuring a tunnel. T o configure IPv6 in IPv4 tunnels 1. Click IPv6 in IPv4 T unnels under Configuration > System Configuration > IPv6 Configuration in the tree view . 2. Enter the IPv4 address of the local tunnel endpoint in the Local IPv4 Address text box. 3. Enter the IPv4 address of th e remote tunnel endpoint in the Remote IPv4 Address t ext box. Note The local address must be the address of anot her interface configured for the router . 4. (Optional) Enter the IPv6 link-lo cal address of the local tunnel en dpoint in the Local IPv6 Link Local text bo x. If you do not specify an addre ss a default will be configured. 5. (Optional) Enter the remote IPv6 link-local addr ess of the remote tunn el endpoint in the Remote IPv6 Link Local text box. 6. (Optional) Enter a value in the T i me to Live text box for the T ime to Live (TTL) packets sent on the tunnel. 7. Click Apply . 8. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 271 Configuring IPv6 to IPv4 This feature allows you to co nnect an IPv6 domain throug h IPv4 clouds without configuring a tunnel. T o configure IPv6 to IPv4 1. Click IPv6 to IPv4 und er Configuration > System Configuration > IPv6 Configuration in the tree view . 2. In the Enable IPv6 to IPv4 field, click Y es. 3. In the Active field, just below the Logical Inte rface field, click On to enable the logical interface. This value represents the pseudo -interface that is associated with this feature. It does not correspond to a specific ph ys ical device. 4. Enter the IPv4 address of th e local interface in the Lo cal IPv4 Address text box. Note This address must be the address of anothe r interface configured for the router . 5. (Optional) Enter a valuefor the T i me to Live (TTL) packets sent. 6. Click Apply . 7. Click Save to make your changes permanent. Configuring IPv6 over IPv4 This feature all ows you to tr ansmit IPv6 traf fic through IPv4 domains without configuring a tunnel. T o configure IPv6 over IPv4 1. Click IPv6 over IPv4 T unnels under Configurat ion > System Configuratio n > IPv6 Configuration in the tree view . 2. In the Enable IPv6 over IPv4 field, click Y es. 3. In the Active field, just below the Logical Interface field, click On. This value represents the pseudo -interface that is associated with this feature. It does not correspond to a specific ph ys ical device 4. Enter the IPv4 address of th e local interface in the Lo cal IPv4 Address text box. Note This address must be the address of ano ther interface configured for the router . 5. (Optional) Enter a value in the for th e T ime to Live (TTL) pa ckets sent.
7 272 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 6. Click Apply . 7. Click Save to make your changes pe rmanent. Configuring IPv4 in IPv6 T unnels This feature allows you to set up a po int-to-point link to pe rmit traf fic from IPv4 domains to travel through IPv6 do mains. T o configure IPv4 in IPv6 tunnels 1. Click IPv6 in IPv4 T unnels under Configuration > System Configuration > IPv6 Configuration in the tree view . 2. Enter the IPv6 address of the local tunnel endpoint in the Local IPv6 Address text box. 3. Enter the IPv6 address of th e remote tunnel endpoint in the Remote IPv6 Address t ext box. 4. (Optional) Enter a value in the Hop Limit te xt box for the maximum number of hops the packets sent on the tunnel can ta ke to reach their destination. 5. Click Apply . 6. Click Save to make your changes pe rmanent. Configuring an IPv6 Default or S t atic Route T o configure an IPv6 default or st atic route 1. Click IPv6 S tatic Routes under Config uration > System Configuration > IPv6 Configuration > Routing Config uration in the tree view . 2. T o enable a default route: a. Select On in the Default field. b. Click Apply . 3. T o create a new static route: a. Enter the IPv6 address prefix in the New Static Route text bo x. b. Enter the mask length (number of b its) in the Mask Length text box. c. Click Apply . 4. Select the type of next hop the route will take from the Next Hop T ype drop-down list— Normal, Reject, or Black Hole. 5. Select the interface that the route will use to reach the gateway in the Interface field. Note This interface must be specified only if the gateway is a link local address.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 273 6. T o specify the order i n which next hops are se lected, enter a value from one to eight in the Preference text box. The lower the value the more preferred the link. The next preferred value is selected as the next hop onl y when an interface fails. A non- reachable link is not selected as the next hop. The preference option also suppor ts equal-cost multipath routing. For each preference value, you can configure as many as eight gateway addresses. The ne xthop gate address for each packet to the destination is selected based on the nexthop al gorithm that is configured. 7. Click Apply . 8. Click Save to make your changes permanent. Routing Configuration Configuring OSPFv3 IPSO supports OSPFv3, which supports IPv6 ad dressing and is based on RFC 2740. OSPFv3 has essentially the same configur ation parameters as OSPFv2, exce pt that you enter them from the Network V oyager page that you access by clicking Routing Configuration under Configuration > System Configuration > IPv6 Co nfiguration in t he tree view . For more information, see “OSPF” on page 353. Configuring RIPng 1. Click RIPng under Conf iguration > System Configuration > IPv6 Configuration > Routing Configuration in the tree view . 2. T o enable RIPng, click On next to the logical interface on which you want to run RIP , and then click Apply . 3. Enter a value in the Metric text box for the RI Png metric to be added to routes that are sent by way of the specified interface. 4. Click Apply . 5. Click Save to make your changes permanent. Creating IPv6 Aggregate Routes 1. Click IPv6 route Aggreg ation under Configuration > System Config uration > IPv6 Configuration > Routing Config uration in the tree view . 2. Enter the IPv6 prefix for the new aggregate ro ute in the Prefix for New Aggregate text box. 3. Enter the mask length (number of b its) in the Mask Length text box. 4. Click Apply .
7 274 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. Scroll through the New Contribu ting Protocol List click th e protocol y ou want to use for the new aggregate route. 6. Click Apply . 7. Click Save to make your changes pe rmanent. 8. Click On in the Contribute All Routes from <Protocol> field. 9. (Optional) T o specify an IPv6 prefix, enter th e IPv6 address and mask length in the text boxes in the Prefix for New Contributing Route from <Protocol> field. 10. Click Apply , and click Save to make your changes permanent. Creating Redistributed Routes Redistributing St atic Routes into RIPng 1. Click IPv6 Route Red istribution under Configuration > System Configuration > IPv6 Configuration > Routing Config uration in the tree view . 2. Click Static Routes. 3. T o redistribute all currently valid static routes into RIPng, click the On button in the Redistribute All Statics in the RIPng field. 4. Enter a value in the Metric te xt box for the metric cost t hat the created RIPng routes will have. 5. Click Apply . 6. Click Save to make your changes pe rmanent. 7. T o redistribute a specific static route or routes into RIPng, click On next to the IPv6 interface for the static route to redistribute to RIPng. 8. Enter a value in the Metric text box for the metric cost that the created RIPng route(s) will have. 9. Click Apply . 10. Click Save to make your changes perman en t. Redistributing Aggrega te Routes in RIPng 1. Click IPv6 Route Aggregation under Conf iguration > System Configuration > IPv6 Configuration > Routing Config uration in the tree view . 2. T o redistribute all currently valid aggregate rout es into RIPng, click On in the Redistribute all Aggregates into RIPng field. 3. Enter a value in the Metric te xt box for the metric cost t hat the created RIPng routes will have 4. Click Apply . 5. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 275 6. T o redistribute a specific aggregate route or ro utes into RIPng, click On next to the IPv6 interface for the aggregate route to redistribute into RIP ng. 7. Enter a value in the Metric text box for the metric cost that the created RIPng route will have. 8. Click Apply . 9. Click Save to make your changes permanent. Redistributing Interface Routes into RIPng 1. Click IPv6 Route Redistribution under Configuration > System Configuration > IPv6 Configuration > Routing Config uration in the tree view . 2. Click Interface Routes. 3. T o redistribute all currently active interface ro utes into RIPng, click On in the Export all Interfaces into RIPng field. 4. Enter a value in the Metric text box for the metric cost that the created RIPng routes will have. 5. Click Apply . 6. Click Save to make your changes permanent. 7. T o redistribute a specific interface route or ro utes into RIPng, click On next to the IPv6 interface for the route to redistribute into RIPng. 8. Enter a value in the Metric text box for the metric cost that the created RIPng routes will have. 9. Click Apply . 10. Click Save to make your changes permanent. Router Discovery Configuring ICMPv6 Router Discovery The ICMPv6 Router Discovery Protoc ol allows hosts running an ICMPv6 router disc ov ery client to locate neighboring ro uters dynamically as well as to learn prefixes and configuration parameters related to address autoconfiguration. Nokia implements only the ICMPv6 router discovery server portion, which means that the No kia platform can advertise itse lf as a candidate default router , but it will not adopt a default router using the router discovery protocol. Beginning with IPSO 3.8.1 and as part of t he new support of VRRP for IPv6 interfaces, only the router in a VRRP master state sends router disc overy advertisements, and the advertisements are sent with the virtual IP address as the source address and the virtual MAC address as the MA C address. Routers in a VRRP backup state do no t send router discovery advertisements. When VRRP failover occurs, the new master begins to send out router discovery advertisements. For
7 276 Nokia Network Voyager for IPSO 4.0 Refe rence Guide more information about configurin g VRRP for IPv6 interfaces, see “Configuring VRRP for IPv6.” 1. Click ICMPv6 Router Discovery u nder Configuration > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. T o enable ICMPv6 router discovery , click On ne xt to the interface on which you want to run the protocol. 3. Click Apply . 4. (Optional) T o enable the mana ged addre ss configuration flag in the router advertisement packet, click Y es in the Man aged Config Flag field. This flag enables hosts to perform statef ul autoconfiguration to obtain addresses. 5. (Optional) T o enable the other stateful configur ation flag in the router advertisement packet, click Y e s in the Other Config Flag field. This flag enables hosts to perform stateful autoconfiguration to obtain information other than addresses. 6. (Optional) T o enable the MTU options field in the router advertisemen t packet, click Y es in the Send MTU Option field. 7. (Optional) Enter a value (in seconds) in the Mi n Adv Interval text box for the minimum time between which unsolicited multicast ICMPv6 ro uter advertisements are sent on the interface. 8. (Optional) Enter a value (in second s) in the Max Adv Interval text box f or the maximum time between which unsolicited multicast ICMPv6 router advertisements are sent on the interface in the Max Adv Interval text box. Whenever an unsolicited advertisement is se nt, the timer is set to a value between the maximum advertisement interval and the minimum advertisement interval. 9. (Optional) Enter a value (in second s) in the Router Lifetime text box for a router advertisement packets router lifetime field. A value of zero indicates that the router is not to be used as a default router . 10. (Optional) Enter a value in the Reachable T ime text box for the router advertisement packe ts reachable time field. The value represents the time that a node assu mes a neighbor is reachable after having received a reachability confirmation. 11 . (Optional) Enter a value (in seconds) in the Re transmission T imer text box for the rout er advertisement packets retr ansmission timer field This value represents the time between which neighbor solicitation messages are retransmitted if the node doesn’t receive a response. 12. (Optional) Enter a value in the Cur Hop Limit text box for the router advertisement packets hop limit field 13. (Optional) T o specify that the IPv6 prefix can be used for on-link determination, click Y es in the Onlink Flag field.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 277 14. (Optional) T o specify that the IPv6 pref ix can be used for autonomous address configuration, click Y es in the Autonomous Flag field. 15. (Optional) Enter a value (in seconds) in the Pr efix V alid Lifetime text box for the prefix information options valid lifetime field. This value represents the lengt h of time—relative to the time the packet is sent—that the prefix is valid for the purp ose of on-l ink determination. 16. (Optional) Enter a value (in seconds) in the Pr efix Preferred Lifetime text box for the prefix information options preferred lifetime field. This value represents the length of time—rela tive to the time the packet is sent—that addresses that are generated by the prefix through stateless autoconfiguration remain preferred. 17. Click Apply . 18. Click Save to make your changes permanent. VRRP for IPv6 Configuring VRRP for IPv6 Beginning with IPSO 3.8.1, No kia supports VRRP configuration for IPv6 interfaces. Nokia supports VRRP version 3, which i s based on VR RP version 2 as defined for IPv4 in RFC 3768, and Monitored Circuit. Unlike VRRP version 2, VRRP versio n 3 does no t support authentication, and the advertisement interval in the VRRP packet is 12 bits rather than eight bits. Also, for both VRRP version 3 and Monitored Circuit for IPv6 interfaces, the hello in terval is measured in centiseconds rather than seconds. In version 3, the first address in the pa cket must be an IPv6 link-local address. For general inform ation about VRRP , see “V irtual Router Redundancy Protocol (VRRP)” on page 183. For more information about how to configure Ch eck Point NG with Application Intelligence for VRRP for IPv6 see, “Configuring Check Point NGX for VRRP” on page 1 97 Note Check Point NG with Applicat ion Intelligence does not support user , se ssion, or client authentica tion for IPv6 interfac es. Also, Check Point NG does not support st ate synchronization for IPv6 interfaces. When a master router of a VRRP p air fails, and the backup router becomes the new ma ster , all previously esta blished connections are lost because state synchron iz ation does not occur . As part of the new su pport of VRRP for IPv6 interfaces, only the ro uter in a VRRP master state sends router discovery advertisements, and the advertisements a re sent with t he virtual IP address as the source address and the virtual MAC address as the MAC address. Route rs in a VRRP backup state do not send router discovery advertisements . When VRRP failover occurs,
7 278 Nokia Network Voyager for IPSO 4.0 Refe rence Guide the new master begins to sen d out router disc overy advertisements. For more information about configuring Router Discovery for IPv6 interfaces, see “Configuring ICMPv6 Router D iscovery .” Creating a V irtual Router for an IPv6 Interface Using VRRPv3 Y ou must configure a virtual router on an inte rface to enable other routers to back up its addresses. 1. Click VRRP for IPv6 under Configur ation > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. Click VRRPv3 button next to the in terface for which to enable VRRP . 3. Click Apply . 4. Enter a value from 1 to 255 in th e Own VRID text box to spe cify a virtual router ID for the virtual router . Click Apply . Additional configuration options appear on the Network V oyager page after you click Apply . Note Other routers on the LAN use the virtual route r ID to back up the he addresses of this router . No other router on the LAN can use this valu e to configure VRRP for its own addresse s. 5. From the Address drop-down list select an IP address to specify a virtual IPv6 address for the virtual router . Click Apply . Y ou must configure at least one virtual address, and at least one virtual IPv6 address must be the link-local address for the interface. T o remove a virtual IP address, click of f next to the entry for the IPv6 address. 6. (Optional) In the Hello Interval text box, enter a value from 1 to 4095 to specify the interval, in centiseconds, that is, 1 one-hundredth of a second, between VRRP advertisement transmissions. This value should be the same on all the routers with this virtual router configured. The default is 100 centisec onds, that this 1 second. 7. Click Apply . 8. T o make your changes permanent, click Save. Creating a V irtual Router to Back Up Another VRRP Router Addresses Using VRRPv3 Note Do not turn on the VRRP backup router before the VRRP master is configured. This lea ds to a service out a ge because the VRRP backup router t akes over the IP address while the master is still active with that IP addre ss. T o configure the master router , see “Cre ating a Vir tu al Router for an IPv6 Interface Using VRRPv3.”
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 279 Use this procedure to configure virtual routers to back up the addresses of other routers on a shared media network. 1. Click VRRP for IPv6 under Configuration > System Configuration > IPv6 Configuration > Router Services in the tree view . 2. Click VRRPv3 button next to the in terface for which to enable VRRP . 3. Click Apply . 4. In the Backup Router with VRID text box, ente r a value of from 1 to 255 to specify a virtual ID for the virtual router used to back up th e IP addresses of another system. The router you are backing up must also have this virtual ro uter configured for its addresses. Click Apply . Additional configuration options appear that let you enter the IPv6 addresses of the router you are backing u p. 5. (Optional) Enter a value from 1 to 254 in the Prio rity text box to specify the priority of this router during contention for the IP addresses of a failed router . Of the routers backing up the failed router , the one with the priority of highest value take overs the addresses. The default value is 10 0. 6. (Optional) In the Hello Interval text box, enter a value from 1 to 4095 to specify the interval, in centiseconds, that is, 1 one-hundre dth of a second, between VRRP adve rtisement transmissions. This value should be the same on all the routers with this virtual router configured. The default is 100 centisecon ds , that is, 1 second. 7. (Optional) Click Disabled n ext to Preempt Mode if you do not wan t a virtual router with a higher priority to preempt the current master router and become the ne w mas ter . The defau lt value is Enabled, which means that a virtual ro uter with a higher priority than the current master pr eempts the master and becomes the new master router . 8. (Optional) Click Enabled next to Accept Mode if you want the virtual ro uter when it is in a master state to accept and respond to IP pack ets sent to virtual IPv6 addresses. The VRRP protocol specifies not to accept or respond to such IP packets, so th e default is Disabled. 9. Enter an IPv6 address for this virtual router in the Backup Address text box. The first back- up address you configure must be a link-local address. Any link-local address must belong to the fe80::/64 subnet, and global addresses must belong to the subnet of the interface. 10. (Optional) If the router you are bac king up ha d more than one IP address, repeat step 10. 11 . Click Apply , and then click Save to make your changes permanent. Monitoring the Firewall St ate Y ou can configure the system to monitor the stat e of the firewall and respond appropriately . If a VRRP master detects that the firewall is not ready to handle traffic or is not functioning properly , the master fails over to a backup system. If a ll the firewalls on all the systems in the VRRP group are not ready to fo rward traf fic, no traf fic will be forwarded.
7 280 Nokia Network Voyager for IPSO 4.0 Refe rence Guide This option does not affect the fun ctioning of your system if a firewall is not installed. 1. Click VRRP for IPv6 under Configur ation > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. Click Enabled in the Monitor Firewall S tate field. 3. T o disable this option, if you have enabled it, click Disabled. The default is Enabled. 4. Click Apply , and then click Save to make your changes permanen t. Setting a V irtual MAC Address for a Virtual Router This feature allows yo u to set a virtual MAC (VMAC) address for a virtual router by using one of three options. The implementa tion continues to su pport the default selection of a VMAC through the method outlined in th e VRRP protocol specification. All three modes are useful for V irtual LAN deploy me nts, which forward traffic based on the VLAN address and de stination MAC address.  The Interface mode selects the interf ace hardware MAC address as the VMAC.  In the Static mode, you specify fully the VMAC address.  In the extended mode, the system dynamica lly calculates thre e bytes of the interface hardware MAC address to extend its range of uniqueness. T o set the virtual MAC address 1. Click VRRP for IPv6 under Configur ation > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. Y ou can set the VMAC option for an interface on which you enable VRRP or Monitored Circuit a. T o enable VRRP , click the VRRPv3 button ne xt to the interface for which to enable VRRP , and then click Apply . T o specify the virtual router ID for the virtual router used to back up the local interface address(es) of the interface, e nter a value of from 1 to 255 in the Own VRID text box. Click Apply . T o specify the virtual router ID for the virtual router used to back up IP address(es) of another system, enter a value of from 1 to 255 in the Bac kup Router with VRID edit box. Click Apply . A Backup Address text box appears that allows you to add an IP address for this virtual router . b. T o enable Monitored Circuit, click the Monitored Circuit button next to the interface for which to enable Monitored Ci rcuit, and then click Apply . T o specify the virtual router ID for the virtual router to be used to back up the local interface address(es), enter a value of from 1 to 255 in the Create V irtual Router text box. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 281 Enter the IP address you want to assign to the virtual router back up in the Backup Address edit box. Click Apply . Note The IP address(es) associated with the monito red circuit virtual router must not match the real IP address of any host or r outer on the network of the interface. 3. T o set a VMAC address, click the VMAC Mode drop-down list and select either Interface, Stat ic, or Extended. VRRP is the default. If you select Static, you must enter the VMAC address that you want to use in the S tatic VMAC text box. Click Apply , and then click Save to make your chan ge s permanent. Note If you set the VMAC mode to interface or st atic, you will get syslog error messages when you reboot, or at failover , indicating duplicate IP addresses for the master router and b ackup router . This is expected behavio r since both the mas ter router and the backup router will be using the same virtual IP address temp orarily until they resolve into master and backup. Changing the IP Address List of a V irtual Router in VRRPv3 Y ou must configure at least one virtual address for a virtual router . Addresses already configured are displayed in the List of IPv6 addresses field. Addresses that belong to the interface but not selected for the virtual router are disp layed in the Addresses drop-down list. 1. Click VRRP for IPv6 under Configuration > System Configuration > IPv6 Configuration > Router Services in the tree view . 2. Locate the virtual router an d the inte rface with the IP address to change. Y ou can locate the virtual router informatio n by using the VRID value displaye d in th e Router with VRID field. 3. T o remove an IP address from th e list, in the List of Ipv6 addresses field, click Off next to the address yo u want to delete. Click Apply . 4. T o add an IP address, select an address from the Address drop-down list. Click Apply . 5. T o add a backup IP address, enter the IP address in the Backup Address text box. Click Apply . 6. T o make your changes permanent, click Save. Removing a V irtual Router in VRRPv3 When you disable a virtual ro uter , the VRRP operation terminates, and th e configuration information no longer appears on the VRRP for IPV6 Configuration page in Network V oyag er .
7 282 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Failover of the default router no longer occurs. When you disab le a virtual router , you must first remove the VRRP configuratio n for that virtual router fro m all of the backup routers. Y ou must not delete the virtual router on the de fault router first, as it stops sending VRRP advertisements. This results in the backup routers assuming that the default router has failed, and one of the backup routers automa tically adopts the backup address of the default router . This situation results in two rout ers having the address of the default router configured. 1. Click VRRP for IPv6 under Configur ation > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. Locate the virtual router to remove. a. T o locate a virtual router use d to back up the local interface IP addresses, find the correct virtual ID in the Own VRID field. b. T o local a virtual router used to back up the IP addresses of another router , find the correct virtual ID in the Router with VRID field. 3. Click of f next to the entry for the VRID o f the virtual router yo u want to remove. 4. Click Apply . All the information about that specific virtual router disappears from the Network V oyager configuration page. 5. T o make your changes permanent, click Save. Creating a V irtual Router in Monitored Circuit Mode for IPv6 The monitored circuit feature makes the election of the virtual master router dependent on the current state of the access link. Y ou can se l ect which interface s on which to associate dependency and configure a priority delta for each interface you select. The up and down status of each interface is monitored, and the election of the VRRP master dynamically adapts to the current state of each interface selected for depe ndency . For specific information on configuring specific interfaces on which to associate de pe ndency , see “Setting Interface Dependencies for a Monitored Circuit V irtual Router for IPv6.” The IPv6 address associated with a monitored circ uit virtual router must not match the actual IPv6 address of the host or router on the network of the interface. The first a ddress you configure must be a link-local address. 1. Click VRRP for IPv6 under Configur ation > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. T o enable Monitored Circuit, click the Monitored Circuit butto n next to the interface for which to enable Monitored Ci rcuit, and then click Apply . 3. T o specify the virtual router ID for the virtual router to be used to back up the local interface address(es), enter a value of from 1 to 255 in the Create V irtual Router text box. Click Apply . 4. (Optional) In the Hello Interval text box, enter a value from 1 to 4095 to specify the interval, in centiseconds, that is, 1 one-hundredth of a second, between VRRP advertisement transmissions. This value should be the same on all the routers with this virtual router
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 283 configured. The default is 100 centisecon ds , that is, 1 second. 5. (Optional) Click Disabled n ext to Preempt Mode if you do not wan t virtual router with a higher priority to preempt the current master router and become the ne w mas ter . The defau lt is Enabled, which me ans that a virtual router with a higher priority than the current master preempts th e master and be comes the new ma ster router . 6. (Optional) Click Enabled next to Accept Mode if you want to a virtual router in a master state to accept and respond to IP packets sent to virtual IPv6 addresses. The VRRP protocol specifies not to accept or respond to such IP packets, so the default is Disabled. 7. Enter an IPv6 address for this virtual router in the Backup Address text box. The IPv6 address associated with a monito red circuit virtual router must not match the actual IPv6 address of any host or outer on the network of the interface. The fi rst back-up address you configure must be a link-local address. Any link-local address must belong to the fe80::/64 subnet, and global addresses must bel ong to the subnet of the interface. 8. (Optional) If the router you are b acking up h as more than one IP address, repeat step 10. 9. (Optional) Click Enabled in the Auto-deactiv ation field to set the minimum value for the effective priority of the virtual router to ze ro (0). The default is Disabled, which sets the lowest value for the effective priority of the vi rtual router to one (1). A VRRP virtual router with an effective priority of 0 does not become the master even if the re are not other VRRP routers with a higher priority for this virtual router . Click Apply . 10. (Optional) T o config ure a virtual MAC (VMAC) address for the virtual router , see “Setting a V irtual MAC Address for a V irtual Route r .” 11 . Click Apply , and then click Save to make your changes permanent. Setting Interface Dependencies for a Monitored Circuit V irtual Router for IPv6 The Monitored Circuit feature lets you select one or more interfaces with which to associate dependencies. The up and down status of each in terface is monitored, and the election of the VRRP master dynamically adapts to the current state of each interface selected for dependency . Follow this procedure after yo u create a monitored circuit virtual router . For more information, see “Creating a V irtual Router in Monitored Circuit Mode for IPv6.” 1. Click VRRP for IPv6 under Configuration > System Configuration > IPv6 Configuration > Router Services in the tree view . 2. Click the Monitor Interface drop-d own list for the specific virtual router entry and select the interface you want to monitor . 3. In the Priority Delta text box, enter a value of from 1 to 254 t o specify the priority delta associated with the interface you selected. When an inte rface goe s down, the priority delta value for the that interface is subtract ed from the ba se priori ty value of the virtual router ,
7 284 Nokia Network Voyager for IPSO 4.0 Refe rence Guide resulting in the ef fective priority value. This ef fective priority value of the virtual router is used to determine the election of th e VRRP master router . Note Y ou must enter a priority delta value for each interf ace you select to monitor . If you do not enter a priority delt a value, Network V oyager displays an e rror message. 4. Click Apply . 5. Repeat steps 4 and 5 for each interface you want to monitor . 6. T o remove a specific monitored interface depe ndency , click off next to the name of the interface you want to remov e from the monitored list. Click Apply . The name of the interface disappears from the list of monitored interfaces 7. Click Save to make your changes pe rmanent. Changing the List of Addresses in a Monitored Circuit V irtual Router for IPv6 1. Click VRRP for IPv6 under Configur ation > System Configuration > IPv6 Configuration > Router Serv ices in the tree view . 2. Locate the virtual router an d the inte rface with the IP address to change. Y ou can locate the virtual router information by using the V irtual Router ID value displayed in the V irtual Router field. 3. T o remove an IP address from the list, click Off next to the ad dress you want to delete. Click Apply . 4. T o add an IP address to the list, enter the IP address in the Backup Address text box. Click Apply . The first back-up address you co nfigure must be a link-local address. Any link-local address must belong to the fe80::/64 su bnet, and global addresses must belong to the subnet of the interface. 5. T o make your changes permanent, click Save. T raffic Management Configuring traffic management features for IPv6 is essentially the same as for IPv4. See Chapter 10, “Configuring T raf fic Management” for more information.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 285 Security and Access Configuration T o enable FTP , TFTP , or T elnet access 1. Click Network Access Services under Co nfiguration > System Configuration > IPv6 Configuration > Security and Access Configuration in the tree view . 2. Select Y es next to the types of access you want to allow for IPv6—FTP , T elnet, and TFTP . 3. Click Apply . 4. Click Save to make your changes permanent.
7 286 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 287 8 Managing Security and Access This chapter desribes how to manage passwords, user accounts, and groups, how to assign privileges using role-based administration, and ho w to configure network access, services, and Network V oyager session management. It also describes how to configure AAA for a new service, encryption acceleration, and virtual tunn el interfaces (VTI) which support Check Point route-based VPN. Note When users log in to Network V oyager , the navigation tree displa yed depends on the role or roles assigned to their user acco unt. If the roles do not provide acces s to a feature, they will not see a link to the feature in the tree. If they have read-only access to a feature, they w ill see a link and be able to access the p age, but all the controls will be disabled. Managing Passwords Y ou can change your own password. Any user with privileges to the Users feature can reset the passwords of any user , includin g the adm in and monitor users, without providing the current password. Caution Because a user with read/write permissi on to the Users feat ure can change the password of any user , including the ad m in use r . Y ou should be cautiou s in ass igning this permission. T o change the current user ’s p assword 1. Click Change Password under Con figuration in the tree view . 2. Enter your old password in the Old Password text box. 3. Enter your new password and enter it agai n in the Confirm New Password text box. 4. Click Apply . 5. Click Save to make your changes permanent.
8 288 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o change another user ’s p assword 1. Log in as a user who has read/write permissions for the Users feature. Note Admin users or any user with the User feature assigned to them can change a user’s password without providin g th e ex isting password. 2. Click Manage User under Configura tion > Secu rity and Access > Users in the tree view . 3. In the table for the user whose password you wa nt to change, enter the new password in the New Password and in the Confirm New Password text boxes. 4. Click Apply . 5. Click Save to make your changes pe rmanent. Managing User Account s Y ou can use Nokia Network V oyager to add users to your IPSO system, and to edit the user ID, group ID, home directory , and default shell for a user . Y ou can also enter a new password for the user . For information about how to give privileges to users, see “Role-Based Adminis tration” on page 293 . T o view a list of all users, choose Configuratio n > Security and Access > Users in the tree view . Y ou can also view the user name that you used to log in by clicking Home under Configu ration in the tree view . The following users are created by default and cannot be deleted.  admin —Has full read/write ca pabilities to all features access ible through Network V oyager and the CLI. This user has a User ID of 0, a nd thus has all of the privileges of a root user .  monitor —Has read-only capabilities for all features in Network V oyager and the CLI, and can change its own password. Y ou must establish a password fo r monitor before the account can be used.  cadmin —Has full read/write capabilities to all feat ures on every node of the cluster . This user only appears if clustering is configured on your system. When you add a n ew user , the user is given read-o nly privileges to the Network V oyager home page and CLI prompt but they cannot access other Network V oyager pages or execute commands from the CLI prompt. Note Y ou can assign administrative privileges or any read/write roles withou t assigning a user ID of 0. If you assign a user ID of 0 to a user account, the user is equivilent to the Admin user and the roles assigned to that acco unt cannot be modified.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 289 After you create a new user , go to Role-Based Ad ministrati on > Assign Ro le to Users to gra nt the user additional access privileges. For more information, see “Role-Based Administration” on page 293 . Ta b l e 1 4 de scribe s the attributes associat ed with each user account. Adding and Deleting Users In addition to regular users who have access to various features of Network V oyager and the CLI, you can create SNMP users. SNMP users ar e visible only in the Manage SNMP Use rs page of Network V oyager , they are not displayed on the system User Management pages. For more information on SNMP u sers, see “Managing SNMP Users” on page 263. Note When you add a user with cluster perm issions, the user is not automat ically created on the other nodes of the cluster . T o add this user to other nodes of the cluster , you must log in to each node as a system admin user (cluster admin users do not have RBA access). T able 14 User Account Attribut es Attribute D escription Name Name used to identify th e user . Range: 1-32 characters User ID Unique ID number for the user acco unt. The system will not allow you to create a user with a dup licate User ID. Range: 0-65535; 0-102 and 65534 are reserved for system use. For example, the admin user is UID 0, the monito r user is UID 102, and the cluster administrator (cadmin) is UID 101. Group ID Primary group for the user . The us er can be assigned to othe r groups as reflected on the Grou ps p age. Files and dire ctories owned by the user are assigned the permissions of that use r ’s primary group. Range: 0-65535. Nokia recommends that you reserve 0 to 100 for system use, although this i s not enfo rced. Numb ers 0 and 10 are reserve d for the predefined Wheel and Other groups respectively . GIDs 65533 & 65534 are also reserved. Home directory This is the full UNIX path name of a directory wher e th e user will log in. The home directory for all us ers must be /var/e mh ome/< username >. Shell All users exce pt the admin user ar e assigned by default to th e CLI shell (/etc/cli.sh). New password Use this field to ente r a new password if you are changing it. Range: 6-128 characters. All printable characters are allowed . New password (verify) Re-enter the new password if you are changing it.
8 290 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o add a user 1. Click Users under Configuration > Security and Access Configuration in the tree view . 2. In the Add New User section, en ter the name of the user , a unique user ID, and the home directory for the new user . The home directory must be /var/emhome/< username >. Note Y ou must complete all fields (Username, UID, and Home Directory). If you do not complete these fields, an error message appears that says “ not all fields are complete ”. 3. Click Apply . An entry for the new user appears on the page. 4. Enter a password in the New password text box and enter it again in the New password (verify) text box. 5. Click Apply . 6. (Optional) Modify the primary Gro up ID and Shell. 7. Click Save to make your changes pe rmanent. T o remove a user 1. Click Users under Configuration > Security and Access Configuration in the tree view . 2. In the Add new user field, click Off. 3. Click Apply . 4. Click Save to make your changes pe rmanent. Note When you remove a user , that user can no lon ger log in although the use r ’s home directory remains on the system. T o remove the user ’s directory , use the Unix shell. Also, since the user ac co un ts for SNMP are ma in tained separately , you may need to delete the SNMP account for the user , if ther e is one. For mo re information, see “Managing SNMP Users” on page 263. Managing and Using S/Key S/Key is a one-time passw ord system that you can enable to protect the password of admin or monitor accounts when users conn ect through T e lnet or FTP . Y ou must first enable S/Key and then enter an S/Key secret password. After you configure the S/Key for a user , a sequence number and a seed appear before each TELNET or FTP pa ssword prompt. Enter these two items as arguments to the S/Key program runnin g on a secure machine. After you enter the se arguments and your S/Key secret key , the key program produc es a passw ord that you use to log in only once.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 291 T o configure S/Key 1. Click Users under Configuration > Security and Access Configuration in the tree view . 2. Enable the Admin S/Key or Monitor S/Key by selecting either the Allowed or Required radio buttons.  Disabled—S/Key passwords are turned off and cannot be used.  Allowed—the user can use either a standard text password or an S/K ey one-time password.  Required—only S/Key one-time passwords are allowed for connecting through T elnet or FTP . 3. Click Apply . The Current Standard password, S/Key Secr et Password, and S/Key Secret Password (verify) text boxes appear . 4. Enter the current standard password in the Current Standard password text box. 5. Choose a secret password for S/Key that is betw e en four and eight alphanumeric characters long, and enter it in the S/Ke y Secret Password text box. 6. Enter the S/Key secret password again in th e S/K ey Secret Password (verify) text box. 7. Click Apply . The sequence number and the seed appear . Th e sequence number begins at 99 and goes backward after every subsequent S/K ey password is generate d. The seed is associated with the S/Key secret password. 8. Click Save to make your changes permanent. Using S/Key Y ou must have an S/Key calculato r on your pl atform to generate the S/Key one-tim e password (OTP). Many UNIX-derived and UNIX-like sy stems include the S/Key calculator command key . Many GUI calculators in clude support for MD4 (S/Key) algorithms and MD5 (OPIE) algorithms. Be sure to configure such calculators to use MD4 algorithms. Note The OTP is typically a string, or strings, that cont ain a series of words, for example, NASH TINE LISA HEY WORE DISC. Y ou must enter a ll the words in the valid string at the password prompt. T o use the S/Key 1. Log in to the firewall with a T elnet or FTP client. 2. At the prompt, enter either admi n or monito r as a user name. 3. The server returns an S/Key challenge, whic h is comprised of the S/key seq ue nce number and seed, for example, 95 ma74213.
8 292 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The server also returns a prompt for a password. 4. Copy the S/Key sequence number and seed into the S/Key calculator on your platform. 5. Copy the S/Key challenge into the S/Key calculator on your local platform. 6. Enter the S/Key Secret Password. The calculator returns the OTP for this session. Note For more help on how to ente r S/Key info rm a tion, se e yo ur S/Key ca lculato r documentation . 7. Copy the OTP into the T elnet or FTP session. Disabling S/Key T o disable S/Key 1. Click Users under Configuration > Security and Access Configuration in the tree view . 2. Click Disabled in the S/Key Password field. 3. Click Apply . The sequence number and seed disappear . 4. Click Save to make your changes pe rmanent. Managing Group s Y ou can define and configure g roups with IPSO as you can with similar UNIX-based systems. This capability is retained under IPSO for advanced applications and fo r retaining compatibility with UNIX. T o view a list of all existing groups, click Ma n age Groups under Configuration > Security and Access > Groups in the tree view . T wo groups are created by de fault and cannot be deleted:  Other grou p —All users are assigned by default to the Other group. If you edit a user’ s primary group ID to be something oth er than the default, you can use the Edit Group page to add the user to the Other group. All of the user s in the Users group might not appear in the list of current members, because the list does no t show users who are added to the group by default, only users wh o are explicitly added.  Wheel group —Controls which users have root access to the system. Users must be members of the wheel group to use th e su command to log in as root. Use groups for the following purposes:  Specify UNIX file permissions. By default all users are assigned to the Other group.  Use the Wheel group to control which us ers have root access to the system.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 293  Control who can log in through SSH. For most other functions that are generally associated with groups, use the role-based administration feature, described in “Role-Based Administration” on page 293. T o add or edit a group 1. Click Groups under Configuration > Security and Acce ss Configuration in the tree view .. 2. Under Add Group Name, enter the name (eight or fewer characters) of the new group and a group ID number . The group ID must be unique. Suggested va lues are between 101 and 65000. Range: 0- 65535. Nokia r ecommends that you reserve 0 to 100 for system use, although this is not enforced. Numbers 0 and 10 are reserved fo r the predefined Wheel and Other groups respectively . GID s 65 533 & 65534 are also res erved. 3. Click Apply . The new group information ap pears on the page. 4. T o add a n ew member to a g roup, enter the us er name in the Add n ew member text box and click Apply . 5. T o delete a member from the group, select th e user name from the Delete member text box and click Apply . 6. Click Save to make your changes permanent. Role-Based Administration When you add a n ew user , the user is given read-o nly privileges to the Nokia Network V oyager home page and CLI prompt but cannot access other Network V oyager pages or exec ute commands from the CLI prompt. Y ou must assign roles to the user to provide additional access privileges. Role-based administration (RBA) allows IPSO administrators to create and use separate roles. W ith RBA, an administrator can allow users to a ccess specific features by including the features in a role and assigning the role to users. Each role can incl ude a combination of administrative (read/write) access to some features, monitoring (read-only) access to other features, and no access to still other features. This featur e also provides improved auditing capabilities. T o assign a set of access permissions to a user, cr eate a role that specifies levels of access to features you want to include, then assign this role to the relevant user . Y ou can also specify which access mechanisms (Network V oyager or the CLI) are available to the user when you assign a role to the user . If your system is part of a clus te r , you can create and assign role s that provide access to the entire cluster for the associated features. See “Creating Cluster Administrator Users” for detailed information about this type of user .
8 294 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Managing Roles T o view a list of existing roles on your system, click Manage Roles under Configuration > Security and Access >Role Based Administration in the tree view . The following roles are predefined on the system:  adminRole — Give s the user read/write access to every feature on the system.  monitorRole —Gives the user read-only acce ss to every feature on the system.  clusterAdminRole —Gives the user read/write acce ss to ev ery feature on every node in the cluster except for role-based administration. T o configure role-based administration, you must log in to each node of the cluster as an admin rather than a cluster admin. When you create a new role, you can select on ly system access features or cluster access features, not a combination of both. Likewise, a si ngle user can only be assigned syste m roles or cluster roles, you cannot assign an system ro le and a cluster role to the same user . Note When you assign a role cont aining access to a featur e to a user , the user gets access to the configuration p ages for that feature but not to the monitor p ages for that feature. T o provide access to the monitor p ages, you must include the monitor privilege for that fe ature in the role definition. T o add or edit a role 1. Select one of the following:  T o add a role, click Ad d Role under Conf iguration > Security and Access > Role Based Administration in the tree view .  T o edit a role, click Manage Roles under Configuration > Security and Acce ss > Role Based Administration in the tree view , then click the name of the role. Caution Because a user with read/write permissi on to the Users feat ure can change the password of any user , including the ad min user , you shou ld be cautious in assigning roles that conta in this permission. 2. If applicable, select a role type fro m the Role T ype drop-d own list. Y ou might see only one selection, System, meaning that this role will apply to this machine only . The Cluster selection appears only if clsute ring is enable d. A user account be assigned only roles containing system access features or cluster access features, not a combina tion of both. 3. If you are adding a role, enter a name in the Ro le Name text box. The role name can b e any combination of letters and numbers, but it must start with a letter . Y ou cannot edit the name of an existing role.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 295 4. Add features by moving them to the R W (Read/W rite) or RO (Read Only) columns, depending on the permission le vel yo u want to give to this role. Remove the features by moving them back to the A vailable column. Press Shift-click to select a range of features, or Ctrl-click to select multiple features one at a time. Note If you assign the Clustering feature to a user with the role type System, that user can configure clustering on individual nodes but canno t use Cluster V oyager or the CCLI. 5. Click Apply . 6. Click Save to make your changes permanent. T o delete a role 1. Click Manage Roles under Configuration > Security and Access > Role Based Administration in the tree view . 2. Check the Delete check box for th e role. 3. Click Apply . 4. Click Save to make your changes permanent. Note Y ou cannot delete the admi nRole, cluste rAdminRole, or monit orRole default roles. Assigning Roles and Access Mechanisms to Users T o give a user permissions for various features, a ssign the role or roles that contain the feature permissions to the user . Y ou can also specify whether a user can use Nokia Network V oyager and the CLI by assigning access mech anisms to the user from the Assign Roles to User page. When you create a role, you associate a role type. The role types are:  System —A system role assigned to a user provide s the user with access to the associated features on this machine only .  Cluster —A cluster role assigned to a user provid es the user with ac cess to the associated features on every node in the cluster . T o assign roles and access mechanisms to users 1. Click Assign Role to Users under Confi guration > Security and Access > Role Based Administration in the tree view . 2. Click the name of the user to wh ich you want to assign roles. The Assign Roles to User page appears.
8 296 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 3. Assign roles to or remove them for the user by selecting them and clicking Assign or Remove. Use Shift-click to select a range of roles, or Ctrl-click to select multiple roles at a time. Note Y ou cannot change the roles assigned to the Admin, Cluste r Admin, or Monitor users. 4. If you assign a cluster role to a use r, you mu st also assign them the domain value that matches the appropriate cluster ID. 5. Click Apply . 6. Click Save to make your changes pe rmanent. Creating Cluster Administrator Users Y ou can create users and make them cluster admini strators by assigning them a cluster role. Be aware of the following constraints:  Y ou must log in as a system user to use ro le-based administration— this feature is not accessible if you log in as a user with a clus ter role. (This is also true if you log in as cadmin .)  If you do not assign the default cluster administ rator role (clusterAdminRole) to the users you create, be sure to assign them a role of ty pe Cluster . The implications of this choice are explained below .  Users with the role clusterA dminRole automatically log in to Cluste r V oyager or the CCLI and have full access to all clustering features.  Users with the role type Clus ter automatically log into Clus ter V oyager or the CCL I and have access to the features that you assign to the role.  T o allow a user to administer a cluster , you must assign them the domain value that matches the appropriate cluster ID.  If you want to log into a node as a cluster admi nistrator, you must create the user on that node. That is, if you create a cluster adm i nistra tor user on node A but not on node B, you cannot log into node B as this u ser . However , any changes that you make to node A using Cluster V oyager or the CCLI are also implemented on node B. (Y ou can log into all nodes as cadmin because this user is created automatically on each node. ) Note If you assign the Clustering feature to a user with the role type System, that user can configure cluste ring on individual nodes but ca nnot use Cluster V oyager or the CCLI.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 297 Configuring Network Access and Services Ta b l e 1 5 lis t s the options that you ca n configure for network access. Ta b l e 1 6 lis t s the se rvices you can enable on the appliance or for the cluster . T able 15 Network Access Conf iguration Options Option Description FTP Access Enable or disable FTP access to this appliance. Y ou can use FTP access to obtain configuration files from the applian ce. FTP access is disable d by default. Y ou should onl y enable it when it is specifically required due to the security vulnerabili ties inherent in F TP . If you enable FTP access, you u sually should require S/Ke y passwords for the admin and monitor use rs as described in “Managing and Using S/Key” on page 290. FTP Port Number Specifies the port numb er on wh ich the FTPD server listens. Normally , this value should be left at 21, the default valu e. TFTP Access Enable or disable TFTP access to this appliance. T elnet Access Enable or disable T elnet access to th is appli ance. T elnet access is enabled by default. Once you have enabled SSH and have tested your SSH access, you should di sable telnet access to avoid security vulnerabilities. If you enable telnet a ccess, you usual ly should require S/Key passwords for the admin and monitor users as described in “Managing and Using S/Key” on page 290. Admin Network Login Allow or restrict admin login for telnet ac cess to this applaince . Note that this does not affect admin connections through Network V oya ger or FTP . COM2 Login Allow or restrict log i n on the seri al port ttyd1 com2 that may be connected to an external modem. COM3 Login Allow or restrict log in on the serial port ttyd2 com3 that may be provided by an internal modem. COM4 (PCMCIA) Login Allo w or restrict login on the serial port ttyd3 com4 that may be provided by a PCMCIA modem. T able 16 Network Services Service De scription Echo The echo service sends back to the originati ng source an y data it receives. Discard The disca rd service throws away any data it receives. Chargen The chargen service sends data without regar d to the input. The data sent is a repeating sequence of printable characters.
8 298 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o enable network access options and services 1. Click Network Access and Services under Configuration > Security and Access in the tree view . 2. Select the Y es radio button for the access op tions and services you want to enable. 3. If you are enabling login to COM2 , COM3, or COM4, configure a modem as desc ribed in the following procedures. 4. Click Apply . 5. Click Save to make your changes pe rmanent. Configuring a Modem on COM2, COM3, or COM4 Ta b l e 1 7 des cribe s the modem co nfiguration parameters. Daytime The daytime service sends the current date and ti me as a characte r string without regard to the input. T ime The time se rvice sends back to the originating source the time, in seconds, since midnig ht January 1, 1900. This value is sent as a binary number , not a human-readable string. T able 16 Network Services Service De scription T able 17 Modem Configuratio n Parameters Parameter Description Modem On/Off Select the appropriate radio button to turn modem on or off. Modem S tatus Shows whether the system dete cts a modem on the port and whether it is online. Options: Modem Detected / No Modem De tected Inactivity T i meout (minutes) The length of time, in minutes, that a connect ed call on the modem can remain inactive (that is, no traffic is sent or received) before the call is disconnected. Y ou can set th e value to 0 to disable the timer (that is, the call will never be disconnected due to inactivity). S tatus Poll Interval (minutes) This value is the le ngth of time, in minutes, between mod em-line status tests. Once ev ery interval, the system test s that the modem is present and online. If the modem is not detect ed or is offline, a message is logged using syslog. Settin g the value to 0 disabl es the Modem S t atus monitor . Enable Dialback When set to Y es, an incomi ng call on the mode m is dropped after you log in, and the mode m automatically call s the Dialb ack Number and connects a login process to the line.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 299 T o configure a modem on COM2, COM3, or COM4 1. Click Network Access and Services under Conf iguration > Security and Access in the tree view . 2. Click Modem Configuration next to the appropriate serial port. The Modem Configuration page appears. 3. Select the On radio butto n to turn on the modem. The modem is configured to answer any incoming calls. 4. Enter values for Inactivity T imeout and Status Poll Interval, select whether to enable dialback and, if yes, enter a valu e in the Dialba ck Number field. Ta b l e 1 7 describes these fields. 5. Click Apply . 6. Click Save to make your changes permanent. 7. If you are configuring a mo dem on COM4: a. Select the type of modem (Osite ch Five of Clubs, Ositech Five of Clubs II, or Ositech Five of Clubs III). The Ositech mode m page that you selected appears. b. Enter a country code. Cod es ar e listed in the tables below . Y ou can also vie w them by clicking Help from the Network V oyager page. c. Click Apply . d. Click Save to make your changes p ermanent. Note When you dial into a Nokia appliance th at has an Ositech Five of Club s III modem installed, be sure to set the connection rate to 9600 BPS. If you do not, the text you receive from the appliance will be unreadable. Ta b l e 1 8 lists the country codes that you select from wh en entering the code for an Ositech Five of Clubs card in step 7 of the preceding procedure. Dialback Number If you enabled modem dialback, enter a value in the Dialba ck Nu mber field. The dialback featu re uses this number to back an auth enticated user (for example, 408 555 0093). If dialba ck is disab led, ignore this value. Country Code Applies only to COM4. The country setting for the mo dem sets parameters in the modem to comply with standards of the specified country . T able 17 Modem Configurat io n Parameters Parameter Description
8 300 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Ta b l e 1 9 lists the country codes that you select from wh en entering the code for an Ositech Five of Clubs II or III card in step 7 of the preced ing procedure. Configuring Nokia Network V oyager Access When you set up your system for the fi rst time, perform th e following tasks:  Configure basic Nokia Network V oyager options.  Change your SSL/TLS certificat e from the default certificat e. T able 18 Country Codes for Ositech Five of Clubs Card Code Country Code Country Code Country 1 Australia 17 Greece 12 Portugal 2 Belgium 99 Iceland 13 Spain 20 Canada 7 Ireland 14 Sweden 3 Denmark 8 Italy 25 Switzerland 4 Finland 9 Luxembourg 16 United Kingd om 5 France 10 Netherlands 22 United S tates 6 Germany 1 1 Norway T able 19 Country Codes for Ositech Five of Clubs Card II and III Code Coun try Code Country Code Country 09 Australia 46 Greece A0 Spain 0F Belgium 57 Iceland A5 Sweden 20 Canada 59 Italy A6 Switzerland 31 Denmark 69 Luxembourg B4 United Kingdom 3C Finland 7B Netherlands B5 United St ates 3D France 82 Norway 42 Germany B8 Portugal
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 301 Configuring Basic Nokia Network V oyager Options Y ou can configure the following options for Nokia Network V oyager access:  Allow Network V oyager access (enabled by default)  Enable session managem ent (enabled by default)  Specify a Network V oyager SSL/TLS port number  Require encrypti on Note Changes to some of the se settings might make Network V oyager unusable . Y ou can use the CLI set voyager commands to regain access. T o configure Web access for Nokia Network V oyager 1. Click V oyager Options under Configuration > Security and Access > V oyager in the tree view . 2. Select Y es for the Allow V oyager W eb Access field. This option is selected by default. Caution If you uncheck the check bo x, you must use th e CL I to acce ss your IP secu rity platfo rm. 3. T o enable cookie-based session management, select Y es for the Enable Session Management field. 4. Enter the time interval for which a Network V oyage r user is allowed to be logged in without activity in the Session T imeout in Minutes text box. The default value is 20 minutes. If the user clos es the browser with out logging out, the exclusive configuration lock remains in ef fect until the session time-out interval expires. 5. Enter the number of the port to use for SSL/ TLS-secure connections in the port number text box. The default is port 443. Using the default port allows users to connect to Network V o yager without specifying a port number in the URL. If you change the port number , users must specify a port number in the URL: for example, https ://hostname:<portnumber>/. 6. Select the appropriate encryption level for yo ur security needs from the Require Encryption drop-down list; for example, 40-bit key or st r onger . Note The encryption level you enter is the minimum level of encryption you require . Y ou might obtain stronger en cryption by default if your Web browser support s it. 7. Click Submit.
8 302 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Generating and Inst alling SSL/TLS Certificates IPSO uses the Secure Sockets Layer/T ranspor t Layer Security (SSL/TLS) protocol to secure connections over the Internet from the Nokia Ne twork V oyager client to the IPSO system. SSL/ TLS, the industry standard for secure W eb conn ections, gives you a secure way to connect to Network V oyager . Creating a unique private key for your security platform and keeping it secret is critical to preventing a variety of a ttacks that could compromise the security platform security . When you set up your system for the first time, change your SSL/TLS certificate from the default certificate. IPSO includes a defa ult sam ple certificate and private key in the /var/etc/ voyager_ssl_server .crt and /var/etc/voyager_ssl_serve r .key files respectively . The certificate and private key are for testin g purposes onl y and do not provide a secure SSL/ TLS connection. Y ou must generate a certific ate, and the privat e ke y associated with the certificate, to create a secure connection by using SSL/TLS. Note For security purposes, ge nerate the certific ate and private key over a trusted connectio n. Generating an SSL/TL S Certificate and Keys T o generate a certificate and it s associated private key 1. Click Generate Certificate for SSL under Conf iguration > Security and Access > V oyager in the tree view . 2. Choose the Private Key Size that is ap propriate for your security needs. The larger the bit size, the more secure the pr ivate key . The default and recommended choice is 1024 bits. 3. (Optional) Enter a passphrase in the Enter P assphrase and the Re-enter Passphras e fields . The passphrase must be at least four character s long. If you use a passphras e, you must enter the phrase later when yo u install your new key . 4. In the Distinguished In formation section, enter identifying information for your system: a. In the Country Name field, enter the two-le tter code of the country in which you are located. b. In the State or Province Name field, en ter the name of your state or pr ovince. c. (Optional) In the Locality (T own) Name field, enter the name of your locality or town. d. In the Organization Name field, enter the na me of your compan y or organization. If you are requesting a certificate from a certificate authority , the certificate authority may require the of ficial, legal name of your or ganization. e. (Optional) In the Organizational Unit Name fiel d, enter the name of your departme nt or unit within your company or or ganization. f. In the Common Name (FQDN) field, enter the common name that identifies exactly where the certificate will go. The common name is most commonly the fully qualified
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 303 domain name (FQDN ) for your platform: fo r example, www .ship.wwwidgets.com. If you are generating a certificate signing request fo r a CA, that CA might impose a different standard. g. (Optional) In the Email Address field, enter th e email address to use to contact the person responsible for this system or for its certificate. 5. Select one of the following:  Certificate Signing Request (CSR) Select this option if you are requesting a certificate from a certification authority .  Self-Signed X.509 Certificate Select this option to create a certificate t hat you can use immediately , but that will not be validated by a certification authority . 6. Click Submit. 7. If you generated a certificate signing request , a screen appears that contains a certificate request—New X.509 certificate signing request—and its associated private key—New private key . a. Send the New X.509 certificate signing request to your certification authority . Be sure to include the lines -----BEGIN CER T IFICA TE REQUEST ----- and -----END CER TIFICA TE REQUEST -----. b. Store the new private key that yo ur certificat ion authority securely sends. Install the private key and the certificate. (See Insta lling a Certificate later in this section.) 8. If you generated a self-signed certificate , a screen appears that contains a certificate (New X.509 Certificate) and its associated private key . Y ou must perform a cut-and-paste operation to move the certificate and the private key to the V oyager SSL Certificate page, as de scribed in the following procedure. Inst alling the SSL/ TLS Certificate T o install the certificate and it s associated private key 1. Click Install Certificate for SSL under Conf iguration > Security and Access > V oyager in the tree view . 2. Open the files that contain your certificate and private key . 3. Perform a cut-and-paste operation on your certif icate to move it to the New server certificate field in the Install Certificate for SSL page. Be sure to include the lines -----BEGIN CER TIFICA TE ----- and -----END CER TIFICA TE - ----. 4. Perform a cut-and-paste operation on your priv ate key to move it to the Associated private key field in the Install Certificate for SSL page. Be sure to include the lines -----BEG IN RSA PRIV A TE KEY ----- and -----END RSA PRIV A TE KEY -----.
8 304 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. If you entered a passphrase when you generate d the certificate and private key , you must enter the passphrase in the Passphrase field. 6. Click Submit. T roubleshooting SSL/TLS Configuration Y ou might have trouble accessing Nokia Networ k V oyager if SSL/TLS is not configured correctly . If you have trouble accessing Network V oyager , try the following remedies.  Check that you are using the correct URL. When you enable SSL/TLS, you must use https rather than http when you connect through your W eb browser , unless the Redirect HTTP Requests to HTTPS option is enabled.  Check that you are using the co rrect PEM-encode d certificate an d private key , and that they are installed properly with the dashed begin and end lines. Y ou can view the certificate and private key in the /var/etc/voy ager_ssl_server .crt and /var/etc /voyager_ssl_serv er .key files respectively .  Check the HTTP daemon error message log. Y o u can find the messag es in the following logs: /var/log/httpd_e rror_log and /v ar/log/ssl_engine_log. The messages can help you troubleshoot furthe r and might contain important informatio n for Customer Support should you contact them. Secure Shell (SSH) IPSO uses the Secure Shell (SSH) program to provide secure connections for the CLI. SSH allows you to securely log in to another computer over a network, execute commands on a remote platform, and move files from one pl atform to another platform. SSH provides a connection similar to T elnet or rlogin, except that the traf fic is encrypted and both ends are authenticated. The Nokia SSH implementation supports both SSHv1and SSHv2. Some of the dif ferences between SSHv1 and S SHv2 include what part of th e packet the protocol encrypts and how each protocol auth enticates: SSHv1 authenticat es with server and host keys, while SSHv2 authenticates by using only host keys. Even though SSHv1 uses se rver and host-key authentication, SSHv2 is a more secure, faster , and more portable protocol. In some cases, SSHv1 might be more suitab l e be cause of your client software or your need to use the authentication modes of the protocol. Properly used, SSH provides you with session protection from the following security threats:  DNS spoofing  Interception of passwords  IP spoofing  IP source routing  Person-in-the-middle attacks (SSHv2 only)
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 305 Y ou should use SSH, instead of utilities such as T elnet or rlogin that are not secure, to connect to the system . Y ou can also tun nel HTTP over SSH to use Network V o ya ge r to securely manage your platform. T o use SSH, you must obtain an SSH client for the other end of the conn ection. SSH clients are available for a number of platforms. Some are free while others are commercial. An SSH client is already installed on your platform; however , you probably wan t a client to connect from another host, such as your desktop computer , and you must install a client there as well. Initial SSH Configuration When you first activate your system, SSH is alread y enabled and host keys for your platform are generated and installe d. SSH au tomatically authenticates users who log in with the standard password mode of login . Y ou do not need to do any other configuration unless yo u want users to be able to use public-k ey authentication as well. T o permit public-key authentication, you mu st first authorize the users’ client identity keys for th is system, as described in “Configuring Secure Sh ell Authorized Keys” on page 308. T o configure SSH 1. Click SSH Configuration under under Configuration > Security and Access > Secure Shell (SSH) in the tree view . 2. Select Y es in the Enable/Disable SSH Service field. Note The first time you enable SSH it generates both RSA v1, RSA v2, and DSA host ke ys. This process will take a few minutes. 3. Click Apply . 4. Select whether the admin user can log in with SSH.  Ye s —the admin user can log in using SSH and can use the password mode of authentication to do so. Th is is the default setting.  No —the admin user can no t log in.  Without Password —the admin user can log in, but mu st use public-key authentication to do so. 5. Click Apply . 6. (Optional) In the Configure Serv er Authentication of Users table, click Y es for each type of authentication to be used. Note Y ou can authenticate SSH connections by us ing public ke ys (for RSA and DSA SSHv2), standard user and password information, rhos t s files, and RSA keys (for SSHv1). Y ou
8 306 Nokia Network Voyager for IPSO 4.0 Refe rence Guide can permit any combination of these methods. In all cases the default is Y es, except for rhost and rhost with RSA au thentication . The rhost authe ntication is insecure and Nokia does not recommended using it. 7. Click Apply 8. (Optional) In the Configure Server Protocol De tails field, click the version of SSH to be used. The default is both 1 and 2. 9. (Optional) T o generate an RSA v1 host key (use with SSHv1), select the key size, listed in bits, from the Generate New RS A v1 Host Key drop-down list. 10. Click Apply . 11 . (Optional) T o generate an RSA v2 host key (use with SSHv2), select the key size, listed in bits, from the Generate New RS A v2 Host Key drop-down list. 12. Click Apply . 13. (Op tional) T o generate a DSA host key (use with SSHv2), select the key size, listed in bits, from the Generate New DSA Host Key drop-down list. The recommen d va lu e is 1024 bits. 14. Click Apply . 15. Click Save to make your changes perman en t. Note When you generate new keys, you might need to chan ge the configurations of each client, or the clients migh t return errors. For more information, see your SSH client docu mentation. Configuring Advanced Options for SSH The advanced SSH Server Conf iguration page a llows you to confi gure the Secure Shell (SSH) daemon settings, access methods, ac cess filters, and logg ing behavior . These settings strictly control the SSH connections that the system a ccepts. These are optional settings. T o use SSH, enable it in the Enable/Disable SSH Service text field . Y ou do not need to configure other options or advanced opt ions. T o configure advanced options 1. Click SSH Server Advanced Options und er Configuration > Security and Access > Sec ure Shell (SSH) in the tree view . 2. Click Y e s in the Enable/Di sable SSH Service field. Note The first time you enable SSH it generates both RSA and DSA host keys. This process take s a few minutes.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 307 3. Click Apply . 4. (Optional) In the Configur e Server Access Contr ol table, enter the group and use r nam es in the appropriate text boxes . Y ou can use wild card characters when you spec ify multiple group or user names separated by spaces. Note If you specify users or group s, only those users and groups are allowed or forbidden. Group settings only apply to a user ’s prim ary group—the GID setting in the V oyager Password page. For mor e information on ho w to configure users and groups, see “Managing User Account s” on page 288 and “ Man aging Groups” on p age 292. 5. Click Apply . 6. Click the option to use in the Perm it Admin User to Lo g In field. The default is Y es, which allows th e admin user to log in using SSH. 7. Click Apply 8. In the Configure Server Authentication of Us ers table, click Y es for each authentication option to be used. Note Y ou can authenticate SSH connections by us ing public ke ys (for RSA and DSA SSHv2), standard user and password information, r host s files, RS A keys (for SSHv1), or any combination of these methods. In all cases t he default is Y es, except for rhost an d rhost with RSA authentication. The rhost utility is insecure an d Nokia does not recommend using it. 9. Click Apply 10. (Optional) In the Configure User Login Envi ronment table, click Y es for each desired action. The default is Y es in the Print message of the day on login field. The default is No in the Use login(1) program for int eractive logins field. 11 . Click Apply 12. (Optional) In the Configure Server Protocol Details table, select the method of encryption (SSHv2), enter appropriate values in the text boxes, and click the choice to use in the Send Keepalives to the Other Side and Protocol V ersion(s) fields. The default settings are Y e s and Both 1 and 2 in these fields respectively . Note The default setting in the Cipher to us e field is all ciphers o n. If you deselect all choices in the this field, the setting revert s to the default setting.
8 308 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 13. Click Apply . 14. (Optional) In the Configure Service Details field, click the choices and enter appropriate values in the text boxes. 15. Click Apply . 16. (Optional) In the Configure Server Implemen tation Details table, select the appropriate setting from the drop-down list, and click the choice. The default setting in the Message logging level field is INFO, and the default setting in the Strict checking of file modes field is Y es. 17. Click Apply . 18. Click Save to make your changes perman en t. Configuring Secure Shell Authorized Keys The Secure Shell (SSH) Authorized Keys feature lets you create clients that can access accounts on your system without using a password. T o configure an au thorized key , you need to have information about the clients’ keys. For SSHv1 implementation, you need to enter the RSA key and su ch information as key size, exponent, and modu lus . One commonly used file name on your SSH client that is us ed for storing this information is identity.pub . For SSHv2 implementati ons , you need to enter the RSA/DSA key . One common ly used file name on yo ur SSH client that is used for storing this information is id_dsa.pub . For more information, consu lt your SSH client software documentation. Field Name Default V a lue Allow remote connections to forward ports No Ignore user ’s own known_ho sts file No Ignore .rhosts and .shosts files Y es T ime (seconds) before regenerating server key 3600 seconds Login grace time (sec) 600 seconds Max unauthenticated connections 10
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 309 T o configure authorized keys 1. Click SSH Authorized Keys under Config uration > Security and Access > Secure Shell (SSH) in the tree view . Note If you previously configur ed authorized keys for user accoun ts, the information appears in the View/Delete Per- User Authorized Keys table. T o delete the authorized key for each user click the Delete check box. 2. Select the user name from the Username drop-down list. 3. Complete the following, d epe nding on the autho r ized key you are adding.  T o add an RSA authorized key to use in SSH v1—enter the key size, exponent, modulus, and an optional comment in the Add a New Authorized Key (RSA, for protoc ol version 1) table.  T o add a RS A authorized key to use in SS Hv2—enter the RSA key , in either OpenSSH format or SSHv2 format, de pending on your client, and optional comment in the (RSA, for protocol version 2) tab le.  T o add a DSA autho rized key to use in SS Hv2—enter the DSA key , in either OpenSSH format or SSHv2 format, de pending on your client, and option al comment in the Add a New Authorized Key (DSA, for protocol v ersion 2) table. 4. Click Apply . 5. Click Save to make your changes permanent. Changing Secure Shell Key Pairs The following procedu re describes how to generate new RSA and DSA keys. When you generate new keys, you might need to change conf igurations of each client, or the client might return errors. For more information, see your SSH client documentation. T o configure key pairs 1. Click SSH Key Pairs under Configuration > S ecurity and Access > Secure Shell (SSH) in the tree view . 2. (Optional) T o generate an RSA host key (to us e with SSHv1), select th e key size, listed in bits, from the Generate New RS A v1 Host Key drop-down list. Note The most secure value is 1024 bi ts. V alues over 1024 bits cause problems for some clients, including thos e based on R SAREF . 3. Click Apply .
8 310 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. (Optional) T o generate an RSA host key (to us e with SSHv2), select the key size, listed in bits, from the Generate New RS A v2 Host Key drop-down list. 5. Click Apply . 6. (Optional) T o generate a DSA host key (to u se with SSHv2), select the key size, listed in bits, from the Generate New DS A Host Key dro p -down list. The recommen d va lu e is 1024 bits. 7. Click Apply . 8. Click Save to make your changes pe rmanent. Note Re-creating keys might cause pr oblems with so me clients, because the ser ver use a key diff erent from the one it used before. Y ou can reconfigure the client to accept the new key . Managing User RSA and DSA Identities This procedure describes how to manage the public and privat e-key p airs of g iven users o n yo ur application platform. T o manage user identities 1. Click SSH Key Pairs under Configuration > S ecurity and Acces s > Secure Shell (SSH) in the tree view . 2. Click the V iew/Create Identity Keys for User ‘user name’ link for the appropriate user . 3. (Optional) T o create an RSA identity to use with SSHv1, select the key length in the Generate key of size field in the Gene rate New RSA v1 Identity for user name. 4. Enter the passphrase in the Enter password field, and then again to verify it. 5. (Optional) T o create an RSA identity to use with SSHv2, select the key length in the Generate key of size field in the Gene rate New RSA v2 Identity for user name. 6. Enter the passphrase in the Enter passwor d field and then again to verify it. 7. (Optional) T o create a DSA identity to use with SSHv2, select the key le ngth in the Generate key of size field in the Genera te New DSA Identity for user name. 8. Enter the passphrase in the Enter passwor d field and then again to verify it. 9. Click Apply . 10. Click Save to make your changes perman en t.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 311 T unneling HTTP Over SSH T o tunnel HTTP over SSH 1. Generate a key . 2. Put authorized public keys on the system. 3. Log in and redirect a port on your platform to th e remote platfo rm. Depending on what type of terminal you are usin g complete the following.  From a UNIX terminal —Use the -L option to redirect a port to port 80 on the remote platform. The fo llowing exam ple redirects port 8000. At the shell prompt, type: ssh -l admin Nokia Platform.corp.com -L 8000:127.0.0.1:80  From a W indows terminal —Use the client to redirect port 8000. a. When you open a connectio n, click Properties. b. Select the Forward tab. c. Enter a new local port-forwarding en try by clicking on new . d. The source port should be 800 0. The destination host should b e 127.0.0.1, and the destination port sho uld be 80. For security reasons, check the allow local connections only box. e. Click OK twice to return to the connection dialog box. f. Press OK to connect to the remote host. Note T o redirect a port permanently , choose Save As in the File menu and save the configuration to a file. This allows you to redirect the sa me p orts every time you create an HTTP tunnel ov er SSH Network V oyager Session Management IPSO session management lets administrators prevent multiple users from maki ng simultaneous configuration changes, whe ther they are using Nokia Netwo r k V oyager or the CLI. When you log in, you can acquire an exclusive configura tion lock so that other users cann ot make configuration changes to an ap pliance while you are logged in to it. Sessions are logged out automatically after a period of in activity that you can specify , or the user can manually log out at any time.
8 312 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Network V oyager uses cookies to keep track of HTTP sessions. Network V oyager cookie based session management does n ot store user names or passwords in any form in the cookies. Y ou should continue to access Network V oyager from a secu re workstation. For information about configuration locks an d instructions about how to override a configuration lock, see “Obtaining a Configuration Lock” on page 25. Enabling Enabling or Disabling Session Management Network V oyager dession management is enabled by default. If you disable session management, the login window asks o nly for user name and password, with no options for configuration locks. Note Y ou r browser mu st be config ured to acc e pt cookies to enable session management. T o enable or disable session management 1. Click V oyager Options under Configuration > Security and Access > V oyager in the tree view . 2. Select Y es for Enable Cookie-Based Session Management to enable session management; select No to disable session management. 3. Click Apply . A new login window opens. See “Obtaining a Configuration Lock” on page 25. 4. Close your browser an d make a new connection to the system. Configuring Session T imeout s Y ou can adjust the time interval which Network V oyager allows a user to be logged in without activity . If you close your browser without logging out, the configuration lo ck remains in effect until the interval expires. T o set the session timeout interval 1. Click V oyager Options under Configuration > Security and Access > V oyager in the tree view . 2. In the Session T imeout text box, enter the time in seconds. The default is 20 minutes. 3. Click Submit.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 313 Authentication, Authorization, and Accounting (AAA) Creating an AAA Configuration Use this procedure to crea te an AAA configuration for a new service. A serv ice is a name that is used by an application uses to invoking the Pluggable Authentication Module (P AM) Application Programming Interface (API) that is part of the AAA. The P AM mechanism provides for authentication, accou nt management and session management algorithms that are contained in shared modules. The P AM infrastructure loads the se modules when the application needs to access the algorithms. T o create an AAA configuration 1. Click AAA under Configuration > Security and Ac cess in the tree view . 2. Create an AAA Configuration entry using one or more of the following elements: a. “Creating a Service Module Entry” b. “Creating a Service Profile” c. “Creating an Auth entication Profile” d. “Creating an Accounting Profile” e. “Creating a Se ssion Profile” Which element to create depends on the needs of the service that uses AAA; at a minimum, a. and b. and one of c., d. or e. is needed before Apply is selected. If any items are to be configured individually , co nfigure them in the following order:  e  d or c  b  a The steps for configuring each of these eleme n ts is described in th e following subsections. Note Y ou can add an Author ization, Accounting, or Se ssion profile without using any of them in a Service Profile. 4. Click Apply . 5. Click Save to make your ch anges permanent.
8 314 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Creating a Service Module Entry T o create a service module entry 1. Enter the name of the service in the New Service text bo x under the Service Module Configuration table. 2. In the Profile text box under the Serv ice Module Configuration table, en ter either an existing Profile Name from the Service Profile t able, if the requirements of the service match one of the existing pro files, or a unique profile name , if the requirements of the service do not match any of the existing profiles. Creating a Service Profile T o create a service profile 1. Enter the name of the profile in the Service Pr ofile text box under the Service Profile table; make sure that the name does not match any of the Profile Names in the Service Profile table. 2. In the Auth. Profile text box under the Servic e Profile table, enter eit her an existing item from the Auth. Profile table, if the servi ce requirements match one of the existing authentication profiles, or a unique authenticatio n profile name, if the service requirements do not match any of the existin g authentication profiles. Leave the Auth. Profile text box blank if the service requirements do not include authentication services. 3. In the Acct. Profile text box under the Servi ce Profil e table, enter either an existing item from the Acct. Profile table, if the service re quirements match one of t he existing accounting profiles, or a unique accounting pro file name, if the service requirem ents do not match any of the existing accounting profiles. Leave the Acct. Profile text bo x blank if the service requiremen ts do not include accounting services. 4. In the Session Profile text box under the Servic e Profile table, enter either an existing item from the Session Profile table, if the servi ce requirements ma tch one of the existing of the existing session profiles. Leave the Session Profile text box blank if the service requirements do not include sess ion services. Creating an Authentication Profile T o create an authentication profile 1. Enter the name of the authentication profile in the New Au th. Profile text box under the Auth. Profile table; make sure that the name does not match any of the Names in the Aut h. Profile table. 2. Select the item in the T ype drop-down lis t that matches the service requireme nts.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 315 For a description of the authentication algor ithms that the list items represent, see “Authentication Pr ofile T ypes.” 3. Select the item in the Control drop-down list that matches the service requirements. V alues other than required are effectiv e only when the service requir es more than one Auth. Profile. For a description of the effect on result disp osition and subsequent al gorithm invocation that the list items represent, see “Pr ofile Contr ols.” Note The Server/File field is unused. Authentication Profile T ypes The following table describes the authentication algorithms that th e values represent in the T ype drop-down lists under Auth. P rofile. Note Modules listed in the Module column reside in the /usr/lib directory . T ype Module Descript ion HTTP pam_httpd_auth.so.1.0 Uses the l ocal password database to authenticate the user , using a special algorith m specifically for the Apache Web server . When the user requests a Network V oyager page, this module is called to auth ent icate the user , which, in turn, verifies the user name and password supplied during the Network V oyager login against the information in /etc/master.passwd . Then the modul e performs Lawful Interception Gateway processing to determine whether the user can access the indicated Network V oyager page. PERMIT pam_permit.so.1.0 Doe s not do any authenticati on. It returns a P AM_SUCCESS when invoked. RADIUS pam_radius_auth.so.1.0 A client/server authentication system t hat supports remote administrator login to Network V oyager and command- line configuration, and sele cted management functions. ROOTOK pam_rootok_auth .s o.1.0 Performs one task: If the user id is 0, it returns P AM_SUCCESS with the sufficient contro l flag. It can be used to allow password-free access to some services for root. SECURETTY pam_securetty_auth.so.1.0 Allo ws root logins only if the user is logging in on a secure TTY .
8 316 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Creating an Accounting Pro file T o create an account profile 1. Enter the name of the accounting profile in th e New Acct. Profile text box under the Acct. Profile table; make sure that the name does not match any of the Nam es in the Acct. Profile table. 2. Select the item in the T ype drop-down list th at matc hes the service requirements. (For a description of the accounting algorithms that the list items represent, see “Accounting Profile T ypes.” ) 3. Select the item in the Control drop-down list that matches the service requirements. V alues other than required are effectiv e only when the service requires more than one Acct. Profile. (For a description of the ef fect on result disposition and subsequent algorithm invocation that the list items represent, see “Pr ofile Contr ols.” ) Note The Server/File field is unused. SKEY pam_skey_auth.so.1.0 Implements the S/Ke y algorithm. The user provides the one-time pass phrase, which is used to authenticate the user by using the password database. SNMPD pam_snmpd_auth.so.1.0 Authenticates t he SNMP packets from a user (Management S tation). When an SNMP user is added in the system through Network V oyager , a corresponding authentication and privacy key is created and kept in the usmUser database, /var/ucd-snmp/snmpd.conf. When an SNMP packet is received, the user name in the packet is used to retrieve the user information from the database and imported to the SNMP ag ent local store by this module. This information is then used to authen ticate the packets. T ACPLUS pam_t acplus_auth.so.1.0 A c lient/serve r authentication system t hat supports remote administrator login to Network V oyager and command-line configuration, and selected management functions. The implemented protocol is called T A CACS . UNIX pam_unix_auth.so.1.0 Uses the local p a ssword database to au thenticate the user to allow access to the system. When the user ente rs the user name and password, this module is called to authenticate the user , which, in turn, verifies the user name and password from /etc/passwd and /etc/ master.passwd files. T ype Module Des cription
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 317 Accounting Profile T ypes The following table describes the account manageme nt algorithms that are represented by the values in the T ype drop-down lists under Acct. Profile. Note Modules in the Module column reside in the /usr/lib directory . Creating a Session Profile T o create a session profile 1. Enter the name of the session profile in the New Sess. Profile text box under the Session Profile table; make sure that the name does not match any of the Names in the Session Profile table. 2. Select the item in the T ype drop-down lis t that matches the service requirements. For a description of the session algorithm s that the list items represent, see “Session Profile Ty p e s . ” 3. Select the item in the Control drop-down list that matches the service requirements. V alues other than required are effective only when the service requires more than one Session Profile. (For a description of the ef fect on result disposition and subsequent algorithm invocation that the list items re present, see Profile Controls.) Session Profile T ypes The following table describes the session manageme nt algorithms that the values represent in the T ype drop-down lists under Session Profile. T ype Module Description PERMIT pam_permit.so.1.0 Retur ns P AM_SUCCESS when invoked. UNIX pam_unix_acct.so.1.0 Provides the basic UNIX accounting mec hanism by checking if the password is still valid. If the password is expired for some reason, this module logs in a ppropriate messages. This module also prompts for a password change if the password is going to expire soon. T ype Modu le Description PERMIT pam_permit.so.1.0 Returns P AM_SUCCESS when invoked. UNIX pam_unix_sess.so.1.0 L ogs a message to indicate that a session has started or stopped.
8 318 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Modules in the Module column resid e in the /usr/lib directory . Profile Controls Control values determine how the results of multiple authentica t ion, ac counting, or session algorithms are handled and when additional algor ithms in a list are invoked. Specifies lists of algorithms by defining multiple entries under the Auth. Profil e, Acct. Profile, and Session Profile columns of a Service Profile. The following table describes these effects for al gorithm invocation not at the end of the list. The following table describes these effects for algo rithm invocation for a single item or an item at the end of the list. Creating a Service Module Example In creating a new service, there are unique re quirements for authentic ation, accounting and session management, as follows: Control Description required The result is retained and the next algorithm is invoked. requisite A resul t of failure is reported imme diately and no further algorithms are invoked. sufficient If no previous algorithm reported failure, a result of success is reported immediately and no further algorithms are invoked; a result of failure for this a lgorithm is discarded; if a previous algorithm has reported failure or t he result of this algorithm is fa ilure, th e next algorithm is invoked. optional A result of failure is ignored and a result of success is retained; the next algorithm is always invoked. Control Description required The result is combined with the results of previou s algorithms such that an y failure result causes failure to be reported. requisite The result is reported immediate ly . sufficient The result is reported immediately optional A resu lt of success is reported.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 319 The screens following graphic shows an example of creating a new service. Configuring RADIUS RADIUS, or remote authentication dial-in us er service, is a client and server-based authentication software system th at supports remote-access appli cations. This service allows an organization to maintain user profi les in a centra lized database that resi des on an authentication server that can be shared by multiple remote access servers. A host contacts a RADIUS server , which determines who has access to that service. Beginning with IPSO 3.5, Nokia pro vides RADIUS client support only . T o configure RADIUS servers for a single authentication profile 1. Click AAA under Configuration > Security and Ac cess in the tree view . 2. In the Auth. Profile section, en ter a name for the RADIUS serv ice in the New Auth. Profile text box. For more information, see “Creating an Authentication Profile.” 3. Click the T y pe drop-down list and select RADIUS as the type of service. Service Auth. Mgmt. Acct. Mgmt. Session Mgmt. my_svc required: PERMIT requi red: PERMIT required: PERMIT ip_source: NONE
8 320 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. Click the Control drop-down list and select required, requisite, sufficient, optional or NOKIA-SER VER-AUTH-SUFFICIENT to determine the level of authentication to apply to a profile. For more information, see “Profile Controls.” 5. Click Apply , and then click Save to make your changes permanen t. The name of the RADIUS authentication pr ofile appears in the Auth. Profile table. 6. Y ou must now configure one or more serv ers to use in a single authentication profile. In the Auth. Profile table, click the Servers link in the row for the RADIUS authorization profile you configured. Thi s action takes you to the AAA RADIUS Authori zation Servers Configuration page. 7. In the RADIUS Servers for Auth. Profile table, en ter a unique integer to indicate the priorit y of the server in the Priority text box. There is no default. Y ou must enter a value in the Priority text box. Note Y ou can configure multiple servers for a pr ofile. The priority va lue determines which server to try first. A smaller numb er indica te s a hig her prio rity . 8. Enter the IP address of the RADIUS se rver in the Host Address text box. RADIUS supports only IPv4 addresses. 9. Enter the port number of the UDP port to cont act on the server host in the Port # text box. The default is 1812, which is specified by the RADIUS standard. The range is 1 to 65535. Caution Firewall softw are often bl ocks traffic on port 18 12. T o ensure that RADIUS packets are not dropped, make sure that any firewa lls between the RADIUS server and IPSO devices are configured to allo w traffic on UDP port 1812. 10. Enter the shared secre t used to authenticate the authorization profile between the RADIUS server and the local client in the Secret text box. Y ou must also configure this same value on your RADIUS server . Enter a text string without a backslash. For more information see RFC 2 865. The RFC recommends that the shared secret be at least 16 characters long. Some RADIUS servers limit the shared secret to 15 or 16 characters. Consult the documentation for your RADIUS server . 11 . (Optional) Enter the number of seconds to wait for a response after contacting the server in the T imeout text box. Depending on your clien t configuration, if th e client does not receive a response , it retries the same server or attempts to contact another serv er . The default v alue is 3. 12. (Optional) Enter the maximum number of times to attempt to contact the server in the Max T ries text box.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 321 If all the attempts do not make a reliable conn ec tio n within t he timeout period, the client stops trying to contact the RADIUS server . The default is 3. Note The maximum tries value include s the first attempt. For example, a value of 3 means the client makes two additional attempts to co ntact the RADIUS server after the first attempt. 13. Click Apply , and then click Save to make your changes permanent. Repeat steps 1 through 14 to configure additio nal RADIUS authenticati on profiles. Y ou must configure a RADIUS authenticat ion server for each profile even if you ass ociate the new profile with a server that you previously configured for an existing RADIUS authentication profile. Repeat steps 8 through 14 of this pro cedure to configure additional AAA RADIUS authentication servers only . Configuring T ACACS The T ACACS authenticatio n mechanism allows a remote server that is not part of IPSO to authenticate users (checks pas swords) on beha lf of the IPSO system. T A CACS encrypts transmitted passwords and other data for security . In the IPSO 3.6 release, T ACACS is supported for authentication only , and not for accounting. Challenge-response authentication, such as S/Key , over T A CACS is not supported by IPSO at this time. Y ou can configure T ACACS support separately for various services. The Network V oyager service is one of those for which T ACACS is supp orted and is co nfig ured as the httpd service. When T ACACS is configu red for use wit h a se rvice, IPSO contacts the T ACACS server each time it needs to check a user password. For the Network V oyager service this occurs for each HTTP request (every page view). If the server fails or is unreachable, the password is not recognized and you are not allowed access. In Network V oyager , this denial is effective immediately . Before you chan ge the Networ k V oyager configuration, confirm any new configuration. T o configure T ACACS servers for a single authentication profile 1. Click AAA under Configuration > Security and Ac cess in the tree view . 2. In the Auth. Profile section, enter a name fo r the T ACACS service in the New Auth. Profile text box. For more information, see “Creating an Auth entication Profile.” 3. Click T ype and select T ACPLUS from the dr op-down list as the type of service. 4. Click Control and select required, requis ite, sufficient, optional or NOKIA-SER VER- AUTH-SUFFICIENT from the drop-down list to de termine the level of authentication to apply to a profile. For more information, see “Profile Controls.”
8 322 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. Click Apply , and then click Save to make your changes permanen t. The name o f the T ACACS au thentication profile appears in the Auth. Profi le table. 6. Y ou must now configure one or more serv ers to use in a single authentication profile. In the Auth. Profile table, click the Servers link in the row for the T ACACS authorization profile you configured. This action takes you to the AAA T ACACS Authorization Servers Configuration page. 7. In the T ACACS Servers for Auth. Profile tabl e, enter a unique in teger to indicate the priority of the server in the Priority text box. There i s no default. Y ou must enter a value in the Priority text box. Note Y ou can configure multiple servers for a pr ofile. The priority va lue determines which server to try first. A smaller numb er indica te s a hig her prio rity . 8. Enter the IP address of the T ACACS Server in the Host Address text box. T ACACS supports only IPv4 addresses. 9. Enter the port number of the TCP port to contact on the server host in th e Port # text box. The default is 49, which is specified by th e T ACACS standard. The range is 1 to 65535. 10. Enter the shared secret used to authenticate the a uthorization profile between the T ACACS server and the local client in the Secret text box. Y ou must also configure this same value on your T ACACS server . Enter a text string without a backslash. 11 . (Optional) Enter the number of seconds to wait for a response after contacting the server in the T imeout text box. Depending on your cli ent configuration, if the c lient does not receiv e a response, it retries the same server or attempts to contact anothe r server . The default value is 3. 12. Click Apply , and then click Save to make your changes permanent. Repeat steps 1 through 13 to configure additio nal T ACACS authentication profiles. Y ou must configure a T ACACS authentication server fo r each profile even if you associate the new profile with a server that you previously c onfigured for an existing T ACACS authentication profile. Repeat steps 8 through 13 of this pro cedure to configure additional AAA T ACACS authentication servers only . Deleting an AAA Authentication Server Configuration T o delete an authentication server 1. Click AAA under Configuration > Security and Access in the tree view . 2. In the Auth. Profile table, cl ick the S ervers link in the ro w for the RADIUS or T ACACS authentication profile.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 323 This action takes you to the page for AAA RAD IUS or T ACACS Authentication Servers Configuration. 3. In the RADIUS or T ACACS Servers For Auth. Profile table, check the Dele te check box next to the row for the RADIUS or T ACACS server to disable. Note Y ou must have at least one RADIUS or T A CACS server configured to ma intain RADIUS or T ACACS service. 4. Click Apply , and then click Save to make your changes permanen t. Changing an AAA Configuration T o change an AAA configuration 1. Click AAA under Configuration > Security and Ac cess in the tree view . 2. Change one or more of the following elements of an AAA Co nfiguration:  Changing the Service Profile  Changing an Authentication Profile Configuration  Changing an Authentication Profile Configuration  Changing an Accounting Profile Configuration  Changing a Session Profile Configuration  Deleting an Item in a Service Profile Entry The steps for changing each of these eleme nts is described in the following subsections. 3. Click Apply . 4. Click Save to make your changes permanent. Changing the Service Profile Y ou can add one or more authentication, accounting, or session profiles to a service profile. Note that the authentication, accountin g, and session profiles must exis t before you can add them to the service profile. T o add an authentication profile 1. Enter the name of the service prof ile in the Service Profile text box; the name is shown in the Profile Name column of the Service Profile table. 2. Enter an authentication profile from the Name column of the Auth. Profile table into the Auth. Profile text box o f the Service Profile table. If the requirements for the servic e do not match any of the entri es in the Auth. Profile, create a new Auth. Profile using Creating an Authenti cation Profile and enter that name in the Auth. Profile text box.
8 324 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note The algorit hm is added t o the end of the list. The order of algorithms in the list is the order that they a re invoked. T o change the order , delete the algorithms whic h are out o f order by using “Deleting an Item in a Service Profile Entry ,” and add them in t he desire d order us ing this procedure. Creating a S ta cked Service Module When you create a service, the requirement for multiple authentication algorithms i s as follows. The following graphic screens below show an ex ample of how to cre ate a service which has the requirement for multiple authentication algori thm s. Only the portion of the page that has changes is shown here. Service Authentication Ma nagement my_svc requisite: SKEY required: SECURETTY
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 325 T o add an accounting profile 1. Enter the name of the profile in the Service Profile text box; th e name is shown in the Profile Name column of the Service Profile table. 2. Enter an item from the Name column of the Acct. Profile table into the Acct. Profile text box of the Service Profile table. If the requirements for the service do not match a ny of the entries in the Acct. Profile table, create a new Acct. Profile by using Creating an Accounting Profile and enter that new name in the Acct. Profile text box. Note The algorithm is added to the end of the list. The order of algorithms in the list is the order that they are invoked. T o change the order , delete the algorithms which are out of order , using Deleting an It em in a Service Profile Entry , a nd ad d them in the desired order using this procedure. T o add a session profile 1. Enter the name of the profile in the Service Profile text box; th e name is shown in the Profile Name column of the Service Profile table. 2. Enter an item from the Name column of the Session Profile table into the Session Profile text box of the Service Profile table. If the requirements for the service do not matc h any of the entries in the Session Profile table, create a new Session Profile and enter th e new name in the Sessio n Profile text box. Note The algorithm is added to the end of the list. The order of algorithms in the list is the order that they are invoked. T o change the order , delete the algorithms which are out of order , using “Deleting an Item in a Service Profile Entry ,” and add them in t he desired order using this procedure. Changing a Service Module Configuration In the Service Module Configuration table enter the name of an existing Service Profile in the text box in the P rofile column. Y ou can not assign a different service profile name to th e following services:  httpd  snmpd Changing an Authenticati on Profile Configuration In the Auth. Profile table make one or more of th e following changes to the Auth. Profile name is in the Name column:
8 326 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Select a different item i n the T ype list that matches the new requirements of the service. For a description of the authentication algor ithms that the list items represent, see Authentication Profile T ypes.  Select a diff erent item in the Control list that matches the new requirements of the service. V alues other than required are effecti ve onl y when the service requires more than one Auth. Profile. For a description of the ef fect on result disposition and subsequent algorithm invocation that the list items re present, see Profile Controls. Note The Server/File field is unused. Changing an Accounting Profile Configuration In the Acct. Profile table, make one or more of the following ch ang es to the row where the service Acct. Profile name is in the Name column:  Select a different item i n the T ype list that matches the new service requirements. For a description of the accounting algorithms that the list items represent, see Accounting Profile T ypes.  Select a diff erent item in the Control list that matches the new service requirements. V alues other than required are effective only when the service requires more than one Acct. Profile. For a description of the ef fect on result disposition and subsequent algorithm invocation that the list items re present, see Profile Controls. Note The Server/File field is unused. Changing a Session Profile Configuration In the Session Profile table, make on e or more of the following chang es to the row where the service session profile name is in the Name column:  Select a different item i n the T ype list that matches the new service requirements. For a description of the session algorithms that the list items represent, see Session Profile Ty p e s .  Select a diff erent item in the Control list that matches the new service requirements. V alues other than required ar e effective only when the service requires more than one Session Profile. For a description of the ef fect on result disposition and subsequent algorithm invocation that the list items represent, see Profile Controls.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 327 Deleting an Item in a Service Profile Entry  Highlight one of the entries in the lists under the Auth Profile, Acct Profile or Session Profile column in the Service Profile ta ble for the entry you want to change.  Select the Delete check box of the same entry . Deleting an AAA Configuration T o delete an AAA configuration 1. Click AAA under Configuration > Security and Ac cess in the tree view . 2. Delete one or more of the rows of a table by selecting the check box in the Delete column of the table for that row . Note An item might not be deleted if it is refere nced by another item; for example, a Service Profile might not be deleted if it is used in the Profile column of on e of the rows in the Se rvice Module Configuration t able. 3. Click Apply . 4. Click Save to make your changes permanent. Y ou cannot delete the following services:  httpd  snmpd  login  sshd  other Encryption Acceleration The Nokia encryption accelerator cards provid e high-speed cryptographic p rocessing that enhance the performance of virtual private network (VPN) tunnels. By ta king over cryptographic processing, the cards allows the appliance CPU to perform other tasks. These cards include the Nokia Encryption Accelerator Card and the Nokia Encr ypt Card. For information on which security algorithms your encryption accelerator ca rd supports, refer to the installation documenta tion for yo ur card. Y ou can hot swap an encryption accelerator card—remove the card while your network application platform is running and then reinsert it or insert another accelerator card—on some appliances.
8 328 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Enabling Encryption Accelerator Cards If you do not intend to use SecureXL, y ou must ma nually enable the encryption accelerator card after you install it. If you enab le SecureXL, the encryption accelerator card is automatically enabled—you do no t need to perform any ot her software task to activate the card. Note Y ou cannot enable the card before you install it. The option s in Network V oyager for enabling the card do not appear until it is inst alled. T o enable the encryption accelerator card when yo u are using Check Point software to create and manage VPN tunnels, comple te the following procedure. T o enable the card for a Check Point VPN 1. Click IPSec und er Security and Acc ess in the tree view . 2. Scroll down the page and click IPSec Advanced Con figuration. 3. At Hardware Device Co nfiguration, click On. 4. Click Apply to en able the card. Monitoring Cryptographic Acceleration Y ou can also monitor encryption accelerator card interfaces with Network V oyager . T o monitor the encryption accele rator cards, click Cr yptographic Accelera tor Statistics under Monitor > Hardware Monitoring in the tree view . IPSec T unnels (IPSO Implement ation) Developed by the Internet Engineering T ask For ce (IETF), IPSec is the industry standard that ensures the construction of secure virtual priv ate networks (VPNs). A VPN is a private and secure network implemented on a public and ins ecure network. Secure VPN s are as safe as isolated of fice LANs running entirely over private lines and much more cost ef fective. Note Because the IP2250 applian ce requires the use of Check Point’s SecureXL, this p latform does not support IPSO’ s implementation of IPsec. The IPSec protocol suite provid es t hree new protocols for IP:  An authentication header (AH) that provides connectionless integrity and data origin authentication. The IP header is included in the authenticated data. It does not of fer encryption services.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 329  An encapsulation security payload (ESP) that provides auth entication and confidentiality through symmetric encryption, and an optional anti-replay ser vice. ESP does not include the IP header in the auth entication/confidentiality .  A protocol negotiation and key exchange pr otocol (IKE) for easie r administration and automatic secure connections. IKE introd uces two negotiations. Phase 1 negotiation authenticates both peers and sets up the secu rity for the Phase 2 negotiation. IPSec traf fic parameters are negotiated in Phase 2. T ransport and T unnel Modes The basic buildin g blocks of IPSec, AH and ESP , use symmetric cryptographic techniques for ensuring data confidentiality and data signatures for authenticating the data’ s source. IPSec operates in two modes:  T ransport mo de  T unnel mode In transport mode the original IP header remain s the outer header . The security header is placed between the IP header and the IP payload. This mode offers some light band width savings, at the expense of exposing the original IP header to third party elemen ts in the packet path. It is generally used by hosts—communica tion endpoints. This mode can be used by routers if they are acting as commun ication endpoint s. W ith IPSec tran sport mode:  If AH is used, selected portion s of the original IP header and the data payload are authenticated.  If ESP is used, no protection is of fered to the IP header , but data payloa d is authenticated and can be encrypted. IP header AH Paylo ad IP header ESP header Payload ESP trailer ESP auth IP header AH Authenticated Payload 00126 IP header ESP header Payload ESP trailer ESP auth Authenticated Encrypted 00127
8 330 Nokia Network Voyager for IPSO 4.0 Refe rence Guide In tunnel mode, the original IP datagram is placed inside a new datagram, and AH or ESP are inserted between the IP header of the new packet and the original IP datagram. The new header points to the tunnel en dpoint, and the original header poin ts to the final destination of t he datagram. T unnel mode offers the advantage of complete protection of the encapsulated datagram and the possibility to use private or public address space. T unnel mode is meant to be used by routers—gateway s. Hosts can operate in tunnel mode too. W ith IPSec tunn el mode:  If AH is used , the outer header is authen ticated as well as the tunneled packet:  If ESP is used, the protection is offered only to the tunneled packet, not to the new outer IP header . By default, ESP , providing the highest le vel of confidentiality , is used in this release. Building VPN on ESP T unneling takes the original IP header and enca psulates it within ESP . Then it adds a new IP header , containing the address of a gateway , to the packet. T unnelin g allows you to pass nonrouteable and private (RFC 19 18) IP addresses through a public network th at otherwise would not be accepted. T unneling with ESP using encryption also has the advantage of hiding the original source and destination addresses from the users on the public network, reducing the chances of traffic analysis atta cks. T unneling with ESP can co nceal the addresses of sensitive internal nodes, protecting them from attacks a nd hiding its existence to outside machines. Protocol Negotiation and Key Management T o successfully use the IPSec protocol, two gatewa y systems must negotiate the algorithms used for authentication and en cryption. The gateway systems must authenticate themselves and choose session keys th at will secure the traf fic. The exchange of this information leads to the creation of a security association (SA). An SA is a policy and set o f keys used to protect a one- New IP header AH Old IP header Payload New IP header ESP header Old IP header Payload ESP trailer ESP auth New IP header AH Old IP header Authenticated Payload 00128 New IP header ESP header Old IP header Authenticated Payload 00129 ESP trailer ESP auth Encrypted
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 331 way communication. T o secure bidirectional comm unication between two hosts or two security gateways, two SAs (one in eac h dire ction) are required. Processing the IPSec t raf fic is lar gely a questio n of local implementatio n on the IPSec system and is not a standardization subject. Howeve r , some guidelines are defined to ensure interoperability between multivendor IPSec systems. “Security Architecture for IP”, RFC 240 defin es a model with the following two databases:  The security policy database that contains the security rules an d security services to offer to every IP packet going through a secure gateway  The SA database that contains parameters ass ocia ted with each active SA. Examples are the authentication algorithms, encr yption algorithms, keys, lifetimes for each SA (by seconds and bytes), and mo des to use. T o offer a secure and automated IPSec SA negotiation, IETF added a new protocol. The Internet Key Exchange, (IKE, RFC 2409), bas ed on ISAKMP (RFC 2408), is a more extended framework for SA authen tication an d key exchange. IKE is implemented on top of UDP , port 500. IKE provides authenticated secure key exchan ge with perfect forward se crecy (based on the Diffie- Hellman protocol) and mutual peer authen tication using public keys or shared secrets. The IKE protocol defines two phases:  Phase 1 In order to safely set an IPSec SA, the two peer s first establish a secure channel, which is an encrypted and authenticated connection. The tw o peers agree on authentication and encryption methods, exchange keys, and verify each othe r ’ s identities. The secure channel is called ISAKMP Security Association. Unlike IPSec SAs, ISAKMP SAs are bi-directional and the same keys and algorithm s protect inbound and outbound communications. IKE parame ters are negotiated as a unit and are termed a protec tion suite. Mandatory I KE parameters are: a. Symmetric Encryption algorithm b. Hash function c. Authentication method: pre-shared key and X. 509 certificates. See the following section on “Using PKI” . d. Group for Diffie-Hellman Other optional parameters such as SA lifetim e can also be part of the protection suite.  Phase 2 IPSec SAs are negotiated once the secure ISAK MP channel is established. Every packet exchanged in phase 2 is authenti cated and encrypted according to keys and algorithms selected in the previous phase. The one method to complete phase 1 is Main Mode. The Main Mode negotia tion uses six messages, in a three two-way exchange. The messages containing the identity information are not authenticated nor encrypte d. One mode is defined for phase 2. This mode is called Q uick Mode. Quick Mode uses three messages, two for proposal parameters and a third one to acquit the choice. W ith “perfect forward secrecy” enabled, the default value in Nokia’ s configuration, a new Dif fie-Hellman
8 332 Nokia Network Voyager for IPSO 4.0 Refe rence Guide exchange must take place during Quick Mode . Consequently , the two peers generate a new Diffie-Hellman key pair . Using PKI For Phase 1 negotiation of IKE, the IPSec systems can use X.509 certificat es for authentication. X.509 certificates are issued by Certificat e Authoritie s (CA). IPSO IPSec implementa tion supports Entrust VPN connector an d V erisign IPSec on site services. Contact any of the listed CA vendors for certificate signing services. T o use the X.509 certificates, the IPSec system should follow these steps: 1. Install the trusted CA certificates (all, incl uding yours) of all the peer IPSec systems. 2. Make a certificate request with all the informat ion required to identify the system such as your IP address, a fully qualified domain name, or ganization, or ganization unit, city , state, country , and contact email address. 3. Forward the certificate request to the CA or corresponding RA (R egistration Authority) using the W eb interface or another file transfer mechanism. CA or RA verifies the identity of the IPSec sy stem and generates the approved certificate. A certificate is valid only for a certain period of time. 4. Download and install the approved device certificate and the CA certificate on the IPSec system. 5. Link the certificate to an IPSec policy . Note The IPSO Web-b ased Network V oyager interfa ce provides the mechanism you need to complete all the above steps. IPSec Implement ation in IPSO Note The IP2250 appliance does no t support IPSO’s implem ent ation of IPSec. The IPSO operating system provides a native IPSec implementation supporting ESP in tunnel mode. This implementation is compliant with the following RFCs: T able 20 IPSec RFCs RFC Description RFC 2401 Security Architectur e for the Internet Protocol RFC 2402 IP authentication header
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 333 The IPSec configura tion in Network V oyager is based on three IPSec objects: proposals, filters, and policies.  Proposals —Define the combination of encryption an d authentication algorithms that secure phase 1 negotiation (Ma in Mode) as well as phase 2 nego tiations (Quick Mode) and IPSec packets.  Filters —Determine which packets relate to cert ain proposals. The filters are matched against the source or destination fields in th e packet header depending on whether the filters are used as source or destination filters. If applic able, Protocol and Port fields are also used.  Policies —Link the type of IPSec security that prop osals with traf fic define. The traffic is defined by a list of filters specified for the so urce address and a second list specified for the destination address. If th e source address of a packet match es a filter from the source filter list and the destination address matches a filter from the destination filter list, IPSec is applied to the traffic. Protocols and ports are used in the matching process, if applicable. The kind of security applied to a de fined traffi c is specified by a list of proposals ordered by priority . This list is offered to the other peer beginning with the lowest priority value proposal. Proposals and filters can be reused in different policies. Other elements defined in a policy are authentications methods (Preshared Keys or X.509 Certificates) and lifetime attributes. Miscellaneous T unnel Requirement s IPSec tunnels are defined by local and remote tu nnel addresses. The tunnel requires a policy to define what traffic is encapsulated by the tunnel and wh at security to u se in the encapsulation. The traffic that matches filters as sociated to the policy is encapsulated by using tunnel a ddresses. Policies can also be reused in different tunnel s. An IPSec tunnel cannot fun ctio n wit hou t an associated policy . RFC 2406 IP Encapsulating Security Payload (ESP) Supports algorithms: 3DES, DES, and Blowfish for encryption and SHA-1 and MD5 for authentication. RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP RFC 2408 Internet Security Association and Key Management Protocol (IS AKMP) RFC 2409 The Internet Key Exchange (IKE) RFC 241 1 IP Security Document Roadmap RFC 2412 The OAKLEY Key Determ ination Protocol RFC 2451 ESP CBC-Mode Cipher Algorithms T able 20 IPSec RFCs RFC Description
8 334 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note Native IPSO IPSec tunnels cannot coexist in the same machine with Check Point IPSec software. Be fore you use IPSO IPSec softw are, ensure that no Check Point software is running. Likewise, before you use Check Point IPSec software, ensure that no IPSO IPSec software is runn ing . Y ou can create IPSec tunnel rules with or wit hout a logical interface for all IPSO platforms except the IP3000 series. For the IP3000 series pl atform, you must create a logical interface with each tunnel rule. Y ou can create tunnel rules w ithout logical interfaces if you require a lar ge number of tunnels. However , creating IPSec tunnels without interfaces can slow down non- IPSec traffic. Phase 1 Configuration For IPSO, the Phase 1 encryption and authentication algorithms are the same as those used in Phase 2. However , if Phase 2 encryption is NULL, such as with an AH proposal or NULL- encryption-ESP proposal, IPSO uses 3DES as Phase 1 for the encryption algorithm. The values set in the Lifetime table are used as the hard lifetime of the Phase 2 SA. Phase 1 lifetimes are calculated as Hard Phase 1 lifetime ( seconds) = 5* Ha rd Phase 2 lifetime (seconds). The soft limit value is approximately 80-90 pe rcent of the hard-limit value, depending on whether the device is working as a session initiator or responder . If you create tunnels between an IPSO platform and non-IPSO systems, configure the non-IPSO system so that the Phase 1 lifetim e is five times the Phas e 2 life time. Set the encryption to 3DES, and set the authentication so that it is the same as the Phase 2 algorithm. Platform Support IPSec is supported across all Nokia security appliances. IPSec Parameters The two IPSec peers should agree on authentic ation and encryption methods, exchange keys, and be able to verify each other ’ s identities. While you configuring the peer IPSec devices, consider the following:  At least one proposal (encryption algorithm an d hash function) should match on the peer devices. See “Proposal and Filters” in “ Creating an IPSec Policy” for more information.  Authentication method:  If you are using Shared Secret, both device s should have the same shared secret . See “Putting It All T ogether” in “Creating an IPSec Policy” for more information.  If you are using X.509 certificates, both de vices should install all the trusted CA certificates in the trust hierarchy . See “T rusted CA Certificates” in “Creating an IPSec Policy” for more information.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 335  Some IPSec systems require that the SA lifetim es (seconds, as well as me gabytes) match on both devices. See “Putting It All T ogether” in “Creating an IPSec Policy” for more information.  IKE and PFS groups should match on both devices. See “Putting It All T ogether” in “Creating an IPSec Policy” for more information. The Diffie-Hellman key exchange uses the IK E group during the establishment of Phase 1 ISAKMP SA. V alue options are 1, 2, or 5; 2 is the default value. The Diffie-Hellman key exchange uses the PFS group in Phase 2 to construct key material for IPSec SAs. The value options are 1, 2, 5, or none; 2 is the default. Setting the val ue to none disables PFS. Note When IPSO is acting as the responde r of the Phase 2 negotiation, it always accept s the PFS group proposed by the initiato r . Creating an IPSec Policy Choosing IPv4 or IPv6 Ge neral Configurat ion Page T o chose IPv4 or IPv6 general configuration p ages 1. Click IPSec unde r Security and Acces s in the tree view . . 2. Access the appropriate IPSec General Configuration page:  T o display the IPv4 IPSec General Conf iguration page—click on the IPSec link  T o display the IPv6 IPSec General Config uration page—first click on the IPv6 Configuration link; this takes you to the main IPv6 page. Ne xt, click on the IPSec link; this takes you to th e IPv6 IPSec General Configuration Page.  If you are on the IPv4 General Configuratio n p age—6to move to the IPv6 General configuration page, scroll down to the botto m of the page and click the IPv6 IPSec General Configuration link. Note Application procedures are th e same for bo th configuration page types. The primary diff er ence is the format of the IP addresses. IPv4 uses dotted quad form at and IPv6 uses canonical address format. Selected range value s mig ht be different; consult the inline Help option for specifics. The following sections describe how to create an IPSec policy .
8 336 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Proposal and Filters 1. Under the Proposals table, enter a name for a new proposal in the New Proposal text box. Click either ESP or AH. Note If you click AH, the Encryption Alg (algorithm) must always be set to NONE. If this is not done, an error message appears when you click Apply . 2. From the drop-down list in the Authenticatio n Alg and Encryption Alg fields, select the necessary algo rithms. Click Apply . 3. Under the Filters table, enter a new filter name in the New Filter text box for the subnetwork that you want to control. 4. Enter the subnet address and th e mask length in the Address and Mask Length text boxes. Note Destination filters across multip le rules (tunnel or transport) should not overlap, alth ough source filters can overlap. 5. Click Apply . The new filter information is ad ded to the Filters list. If needed, you can then define a protocol or a port. Defaults are assumed . Re peat this operation for as many networks you need. Note Each Network V oyager page displays a maximum of 10 prop osals or 1 0 filters. If you cr ea te more than 10, they are continued on new page s. Access these p ages by clicking the link directly below the appropr iate section. The lin k to more p a ges appe ars only after yo u create more than 10 proposals or filters. Skip to “Putting It All T ogether” if you do not plan to use a X.509 c ertificate and want to use shared secret for authentication. T rusted CA Certificates T rusted CA certificates are the publicly available certificates of the CAs. T o select a trusted CA certificate 1. Under the T rusted CA Certificates table, enter a name in the New CA text box. Click Apply . 2. An Apply Successful message appe ars and the name of the CA you just entered appears in the T rusted CA Certificates table.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 337 3. Click on the new link with the sa me name that you entered in Step 1. This action takes you to the IPSec Certificate Addition page for that specific certificate. 4. On the Certificate Addition page, you have two choices:  If you have the PEM (base64 ) enc oded certifi cate, select the Paste the PEM Certificate option.  If you know the URL to the certificate (includi ng the local file), select the Enter URL to the Certificate option. 5. Click Apply . Note This action takes you to the next page that ask s for the PEM enc oded cer tific at e or the URL information of the certificate. If you have the PEM encoded cert ificate, pr oceed to step 5; if you reach the URL to the certificate, skip to step 6. 6. If you are asked to enter the PEM code d certificate, use the co p y and paste function of your browser to copy the PEM text of the certifi cate into the text box t itled Paste the PEM Encoded Certificate; click Apply . This actio n should print a Success message. Click on the link titled IPSec General Configuration page to re turn to the main IPSe c configuration page. 7. If you are asked to enter URL info rmation of the certificate, ente r the URL to the certificate. Examples are:  http://test.acme.com/dev1.cert  ftp://test.acme.com/dev1.cert  file://tmp/dev1.cert  1dap://test.acme.com/cn=dev 1.acme.com?pem_x509?sub Enter the HTTP realm information (only for the HTTP protocol); enter the user name and password if needed to conn ect to the FTP/HTTP server . 8. Click Apply . This action should print a Success message. Click on the link titled IPSec General Configuration page to return to the main IPSec Configuration page. Repeat the steps in this procedure for every trus ted CA certificate that needs to be installed. Note On successful completion, a green button ap pe ars under the Certificate File column. The green butt on indicates tha t the certificat e file is present on the machine and it is also a link to view the installed certificate. Device Certificates A device certificate is used to identify a par ticular IPSec system. Follow the steps below .
8 338 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o enroll and install a device c ertificate 1. Under the Device Certificates table, enter a name in the New Certificate text box, then click Apply . 2. An Apply Successful message appe ars and the name of the CA you just entered appears in the Device Certificates table. 3. Click on the new link wit h the same name that you ent ered in step 1. This action takes you to the IPSec Certif icate Enrollment page for that named item. 4. Enter all the fields on the page that id entifies the IPSec system and click Apply . This action should take you to the page where a PEM-encoded certificate request is shown. Note Remember the passphr a se th at yo u entered for fu ture reference. 5. Click on Save to avoid the risk of losing you r private key . 6. If you have access to the CA/RA enrollment pa ge, open the page in a separate browser window . Use the copy and paste function or your br owser to paste the PEM certificate request into the CA/RA certificate enrollment page. Note Some CAs do not expe ct th e he ad e r (-- - -BEGIN CERTIFICA TE REQUEST ----) and the footer (----END CERTIFICA TE RE QUEST ----) lines in the text. Alternatively , you can copy the text in a file and send the file to the CA/RA by FTP or some other file transfer mechanism that is supported. Contact the CA for details. 7. If you could successfully make the certifi cate request select Completed the certifica te request at the CA site option; otherwis e, select the W ill do it later option. 8. Click Apply . If you chose Completed the certificate request a t the CA site, proceed to step 8. If you chose the W ill do it later option, skip to step 10. 9. If you chose the Completed the request at the CA site, a new link Click here to install the Certificate appe ars toward s the bottom of the page. T o install the certificate, click the link to go to the page described in steps 3–6 under “T rusted CA Certificates.” Note Before you install the certific ate, e nsure that CA approved the certificate and that you know how to access the ap pr o ved cer tific at e. If yo u ne ed to wait for th e CA ’s approv al,
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 339 you can click on the link with the Ce rtif icat e name in the IPSec General Configuration page to install the certificate. 10. If you chose Will do it later to make the cer tificate request, the link on the main IPSec General Configuration still points to the certificate request page. Y ou can repeat steps 5 through 8 to install the certificate. 11 . If you finished all the steps, two green buttons appear . Y ou can click on the button under the Cer tificat e column to view the certificate. Advanced IPSec The following options ar e available through the IPSec Advanced Configuration page; the link is at the bottom of the IPSec General Configuration Page:  Log Level—IPSO IPSec provides three leve ls of message logging through the syslog subsystem:  Error (default value)—only error messag es or audit messages are logged.  Info —provides minimum information about the successful connections to the system. Also includes error messages.  Debug —besides the informational messages, gives full details of the negotiations that the subsystem performs. Note In any of the log level options, confidential in fo rmation (such as secret s or session ke ys) are not shown.  Allowing tunnels without logical interfaces This option allows for the creation of IPSec tu nnels that are not associated with a logical tunnel interface. Y ou can create tunnels without logical interfaces if you want a greater number of tunnels and to achieve scalability . The Create a logical interface field appears only if the Allow tunnels withou t logical interface field is sele cted to On in the Advanced Configuration page. Note Enabling this op tion might slow down forwa rding of non-IPSe c packets.  LDAP servers IPSO IPSec implementation supports automa tic CRL retrieval follo wing the LDAPv2/3 protocol specification (RF C 2251). T o retrie ve CRL automatically from the centralized directory enter the URL of the directory server . Because of differ ent implementations, the inte rnal configuration of th e directory server might not be compatible with IPSO th at has implemented LDAP query formats.
8 340 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Putting It All T ogether T o complete creating an IPSec policy 1. Under the Policies table, enter a name for a new policy in th e New Policy text box, then click Apply . An Apply Successful message appe ars and the policy name appears in the Policies table. 2. Click on the policy name in the Policies table. The IPSec Policy Conf iguration page for the name appears. 3. Under the Linked Proposal s table, from the drop-down list in the Add a Prop osal field, select the name of the proposal to use in this policy . Assign a priority in the Priority text box, then click Apply . Repeat this step for every prop osal that must be offered to the other peer . The proposals are offered starting with the lo west priority value (one). 4. Select the authentication method (Pre-Shared Se crets or X.509 Certificates) needed in this policy , then clic k Apply . Note Only one method can be active at a time. 5. If you chose Pre-Shared Secret, enter the shared s ecret in the Enter Shared Secret text box. Enter the secret again, in the Shared Secr et (V erify) text bo x, for verification. 6. Click Apply . If the secret has been entered correctly the red light of the Secret Status field turns green after you click Apply . 7. If you chose X.509 Certificates, select the certif icate name from the list of device certificates that identifies this machine. 8. In the Lifetime table, if the default lifetime va lues ar e not appropriate, modify them in the Seconds and Megabytes text boxes. Note Lifetimes must be set to th e same value between peers when negotiation is initiated. If they are not set the same, IPSO IPSec might deny th e negotiation. 9. In the Diffie-Hellman Groups table, if the default values in the IKE Group and PFS Group text boxes are not appropriate, modify them, then click Apply . Note Each Network V oyager page displays a maximum of 10 policie s. If you cre ate more than 10 policies, they are continued on new p ages. Acce ss these p ages by clicking the link directly
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 341 below the policy section. The link to more p ages appears on ly after you create more th an 10 policies. Creating an IPSec T unnel Rule T o create an IPSec tunnel rule 1. Click IPSec under Configuration > Security and Access in the tree view . 2. Click the IPSec link. 3. Under the IPSec T unnel Rule s heading, enter a name in the New T unnel text box. 4. If the Create a logical interface option appears and you w ant to create a logical inte rface, set the button to Y es. 5. Enter the IP address of the local end of th e IPSec tunnel in the Local Address text box. The local address must be one of the system interface addresses and must be the remote endpoint configured for the IPSe c tunnel at the remote gateway . 6. Enter the IP address of the remote interface to which the IPSec tunnel is bound in the Remote Address text box. The remote endpoint cannot be one of the sy stem interface addres ses a nd must be the local endpoint configured for the IPSe c tunnel at the remote gateway . 7. Click Apply . An Apply Successful message appears and an entr y for the new tunnel appears in the IPSec T unnel Rules table. Note IPSO can support up to 1500 rules. However , each Network V oyager page displays a maximum of 10. If you create more than 10 r ules, they are continued on new pages. Access these pages by clicking the link direct ly below the rule sect ion. The link to more pages appears on ly after you create more than 10 rule s. 8. Click on the new link wit h the name that you entered in the IPSec T unne l Rules table. The IPSec T unnel page appears. 9. (Optional) Activate Hello Protocol in side the tunnel, then click Apply . Note This and the following tw o steps are not ap plicable for tu nnels without lo gical interfac e parame ters.
8 342 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The hello protocol determines the connectivity of an end-to-e nd logical tunnel. As a result, the hello protocol modifies the link status of the logical interface. If the connectivity of an unavailable tunnel is restored, the hello protocol brings up the link . 10. (Optional) If the hello protocol is active, enter a value for the Hello Interval and Dead Interval text boxes, then click Apply . The Hello Interval text box specifies the in terval (number of seconds) between the Hello packets being sent through the tunnel. The Dead Interval text box de termines the interval (number of seconds) in which yo u do not recei ve an Hello packet before the link status changes to unavailable. 11 . (Optional) Change the logical name of the in terface to a more meaningful one by entering the preferred name in the Logical Name text box, then click Apply . 12. From the drop-down list in the Select Policy field, select the policy name that is needed, then click Apply . This action displays a new table, Linked Policy . 13. From the drop-down list in the Source Filters column, select a filter na me that corresponds to the source of the traffic that this policy will protect, then click Apply . Repeat this operation to add as many filters as necessary . Click Apply after each selection. Note If there are 40 or mo r e sou rc e or des tin atio n filters, they do not appear as a list on the Network V oyager page. T o view a filter that is not displayed , type the name of the filter in the appropr iat e field . 14. From the drop-down list in the Destination Filters column, select a filter name that corresponds to the des tination of the traffic that will be protected by this poli cy . Click Apply . Repeat this operation to add as many filters as necessary . Click Apply after each selection. 15. ((Optional) In the Options table, select the op tion Include End-Points in the Filters, then click Apply . 16. Click Save to make your changes perman en t. T ransport Rule T o create a transport rule 1. Click IPSec under Configuration > Security and Access in the tree view . 2. Click the IPSec T ransport Rules Configur ation link at the bottom of the page. The IPSec T ransport Rules page appears. The stru cture of this page is common to both IPv4 and IPv6. 3. Enter the name of the new rule in the New T ransport Rule field. In the Select a policy field select the desire d option from the drop-down list, the click Ap ply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 343 The new entry appears in the IPSec T ransport Rules table. 4. (Optional) T o change the policy entry without ch anging the name of th e associated transport rule, perform the following steps: a. Click in the blank square next to the current policy entry . Click Apply . The policy name is removed. b. Under the Policy column, select a policy op tion from the drop-down list and click Apply . The new policy is entered wit hout chan ging the associated transport rule. 5. From the drop-down list in the Source Filters column, select a filter na me that corresponds to the source of the traffic that will be protected by th is policy . Click Apply . Repeat this operation to add as many filters as necessary . 6. Click Apply after each selection. Note Select as source filters o nly filters tha t pr esen t a single host but no subnet. Note If you have 40 or more source or destination filters, they are not disp layed as a list on the Network V oyager page. T o v iew a filter th at is not displayed, typ e th e na m e of th e filter in the appro pri at e field . 7. From the drop-down list in the Destination Filters column, select a filter name that corresponds to the destination of the tr af fic to be protected by this policy . 8. Click Apply and then cl ick Save to make your changes permanent. 9. T o delete any entries, check the Delete check box and click Apply . Click Save to make delete permanent. Note Each Network V oyager page displays a maximum of 10 transport rules. If you create more than 10 rules, th ey are continued on new p ages. Access the new pages by clicking the link directly belo w the rule sect ion. The link to more pages appe ars only af ter you create more than 10 tran sport rules.
8 344 Nokia Network Voyager for IPSO 4.0 Refe rence Guide IPSec T unnel Rule Example The following steps tell how to configure a samp le IPSec tunnel. The following figure below shows the network config ur ation for this example. T o configure Nokia Platform 1 1. Click IPSec under Configuration > Security and Access in the tree view . 2. Under the Proposals table, enter md5-des as a na me for a new proposal in the New Proposal text box. 3. In the T ype field, select the ESP button. 4. Select MD5 from the Authentication Alg drop-down list and DES from the Encryption Alg drop-down list. Click Apply . 5. In the Filters table, enter site_A as a new filter name in the New Filter text box. Enter 192.68.22.0 in the Address text box and 24 in the Mask Length text box. Click Apply . The new entry appears in the Filters table. 6. In the Filters table, enter site_B as a new filter name in the New Filter text box. Enter 192.68.23.0 in the Address text box and 24 in the Mask Length text box. Click Apply . Note In this example, th e au th en tication method is a pr eshared secret, so you don’t need to select a certificate. 7. (Optional) Click the IPSec Ad vanced Configuration link. Nokia Platform 1 Nokia Platform 2 192.68.22.0/24 192.68.23.0/24 192.68.26.74/30 192.68.26.65/30 00040 Internet IPsec T unnel Remote PCs Site A Remote PCs Site B
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 345 8. (Optional) From the drop-down list in the Log Level field, select Info. Click Apply . 9. (Optional) Click Up. 10. In the Policies table, enter rule_1 as the name for a new policy in the New Policy text box. Click Apply . 11 . In the policies table, click on rule_1 . The correspondin g Configuring Policy page appe ars to complete the missing parameters of the policy . 12. Select MD 5- DES from the Add a Proposal dro p-down list. Enter 1 in the Priority text box. 13. If no default is selec ted, select Pre-Shared Secret in the Authentication Method field. 14. Ente r a text string, such as secret , in the Enter Shared Secret text box and Shared Secret (V erify) text box. Click Apply . 15. Click Up to return to the I PSec General Configuration p age. Under the IPSec T unnel Rules table, enter IPSec_tunn in the New T unnel field. 16. If Create a logical interface appears, select Y es. 17. Enter 192.68.26.65 in the Local Address text box. 18. Enter 192.68.26.74 in the Remote Address text box. Click Apply . 19. Click on the name in T unnel Rules table. The IPSec T unnel IPSec_ tunn page appears. 20. (Optional) Click On to activate Hello Protocol. Click Apply . The Hello In terval and Dead Interval text boxes appear . 21. (Optional) Enter 60 as a value in the Hello Interval text box and enter 180 as a va lue for the Dead Interval text box. Click Apply . 22. From the drop-down list in the Sel ect Polic y field, select rule_1. Click Apply . A new table, Linked Policy , appears. 23. Select SITE _A from the Source Filters drop-down list. 24. Select site_B from the Destin ation Filters drop-down list. 25. Click Apply . 26. Click Save to make your changes permanent.
8 346 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configure Nokia Platform 2 Now set up network application platform 2 (Nokia Platform 2). Perform the same steps that you performed to configure Nokia Platfo rm 1, with the following changes. 1. Ste p 1 8 ; e n te r 192.68.26.74 in the Local Address text box. 2. Ste p 1 9 ; e n te r 192.68.26.65 in the Remote Address text box. 3. Step 24; select SITE _B from the Source Filters drop-down list. 4. Step 25; select SITE _A from the Destination Filters drop-down list. IPSec T ransport Rule Example The following procedure tells you how to config ure a sa m ple IPSec auth en tic at ion connection. The following figu re shows the network configuratio n for this example. T o configure Nokia Platform 1 (IPSO) 1. Click IPSec under Configuration > Security an d Access in the tree view of the network application platform 1 (Nokia Platform 1, IPSO). 2. Under the Proposals table, enter ah -md5 as a name for a new proposal in the New Proposal text box. 3. In the T ype field, click AH. 4. Select MD5 from the Authentication Alg drop-d own list an d None from th e Encryp tion Alg drop-down list. Click Apply . 5. In the Filters table, enter local as a new filter name in the New Filter text box. Enter 192.68.26.65 in the Address text box and 32 in the Mask Le ngth text box. Click Apply . The new entry appears in the Filters table. 6. In the Filters table, enter remote as a new filter name in the New Filter text box. Enter 192.68.26.74 in the Address text box and 32 in the Mask Le ngth text box. Click Apply . Internet Nokia Platform 1 (IPSO) PC 1 192.68.26.74/30 eth-s1p3c0 192.68.26.65/30 00130
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 347 Note In this example, the authen tication me th od is a preshar ed secret, so you do not ne ed to select a certificate. 7. (Optional) Click the IPSec Ad vanced Configuration link. 8. (Optional) From the drop-down list in the Log Level field, select Info. Click Apply . 9. (Optional) Click Up. 10. In the Policies table, enter rule_2 as the name for a new policy in the New Policy text box. Click Apply . 11 . In the policies table, click on rule_2. The correspondin g Configuring Policy page appe ars to complete the missing parameters of the policy . 12. Select AH - MD 5 from the Add a Proposal drop-down list. Enter 1 in the Priority text box. 13. If no default is selec ted, select Pre-Shared Secret in the Authentication Method field. 14. Enter secreted in the Enter Sh ared Secret text b ox and Shared Secret (V erify) text box. Click Apply . 15. Click Up to return to the I PSec General Configuration p age. 16. Select IPSec Transport Rules Configuration link. The IPSec T ransport Rules page appears. 17. In the New Transport Rule text box unde r the IPSec T r ansport Rule s table, enter IPSec_trans . 18. In the Select a policy text box, select rule _2. 19. Select Apply . The new transport rule appears in the IPSec T ransport Rules table. 20. Select local from the Source Filters drop-down list. 21. Select remote from the Destin atio n Filters drop-down list. 22. Click Apply . 23. Click Save to make your changes permanent.
8 348 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configure PC1 Y ou now need to set up PC 1. Perform the same steps that you perform ed to configure Nokia Platform 1 (IPSO), with the following changes. 1. Step 6; for the local filter , enter 192.68.26.74 in the Address text box. 2. Step 7; for the remote filter , enter 192.68.26.65 in the Address text box. Changing the Local/Remote Addr ess or Local/Remote Endpoint of an IPSec T unnel 1. Click IPSec under Configuration > Security and Access in the tree view . 2. In the Name column, click the name link for which you want to change the IP address. Example: tun0c1 3. Y ou are taken to the IPSec T unnel page. 4. (Optional) Enter the IP address of the local en d of the IPSec tunnel in the Local Address te xt box. The local address must be one of the system’ s interfaces and must be the same as the remote address configured for the IPSec tunnel at the remote router . 5. (Optional) Enter the IP address of the remote end of the IPSec tunnel in the Remote Address text box. The remote address cannot be one of the system’ s interfaces and must be the same as the local address configured for the I PSec tunnel at the remote router . 6. Click Apply . 7. T o make your changes permanent, click Save. Removing an IPSec T unnel T o remove an IPSec tunnel 1. Click IPSec unde r Security and Acces s in the tree view . The IPv4 IPSec General Configuration page appears by default. If the IPv6 General Configuration page is desired, scroll to the bo ttom of the page and click on the IPv6 IPSec General Configuration link. 2. Under the IPSec T unnel Rules heading, click in the Del ete sq uare o f t he tu nn el n ame(s) yo u wish to delete. 3. Click Apply . An Apply Successful message appears and the tunnel(s) selected for deletion are removed from the IPSec T unnel Rules table. 4. T o make your changes permanent, click Save.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 349 Miscellaneous Security Settings The Miscellaneous Security Settings page unde r Configuration > Security and Access allows you to change the handling of TCP packets. Th e default behavio r is for IPSO to drop TCP packets that have both SYN and FIN bits set. This behaviour addresses a CER T advisory . For more information on that advisory , go to http://www .kb.cert.org/vul/id/464133. Y ou must change the default configuration if yo u want your Nokia platform to accept packets that have both the SYN and FIN bits set. Comp lete the following proced ure to config ure your platform to accept packets that have both SYN and FIN bits set. T o set TCP flag combinations 1. Click Miscellaneous Security Se ttings under Configuration > Secu rity and Access in the tree view . 2. Select On next to Allow TCP/IP(rfc1644) mode (SYN-FIN together). Select Off to return to the default configura tion if you have enabled your platform to accept packets that have both SYN and FIN bit s set.. 3. Click Apply 4. Click Save to make your change permanent
8 350 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 351 9 Configuring Routing This chapter describes the IPSO routing subs yste m, how to configure the various rou ting protocols that are supporte d, route aggregation, and route redi stribu tion. Routing Overview The Nokia routing subsystem, Ipsilon Scalable Routing Daemon (IPSRD), is an essential part of your firewall. IPSRD’ s role is to dynamically compute paths or routes to remote networks. Routes are calculated by a routing p rotocol. IPSRD provides routing pro tocols, allows routes to be converted or redistributed between routing pr otocols, and, when there are multiple protocols with a route to a given destination, allows you to specify a ranking of protocols. Based on the ranking, a single route is installed in the forwarding table for each destination. Y ou can monitor routing by following links from Network V oyager . Another mo nitoring tool is ICLID, which provides interactive, text-bas ed monitoring of the routing subsystem. Routing Protocols Routing protocols compute the best route to each destination. Routing protocols also exchange information with adjacent firewalls. The best route is determined by the cost or metric values. Routing protocols can be b roken up into two major categories: exterior gateway protocols (EGPs) and interior gateway pro tocols (IGPs). Interior gateway pro tocols exchange routin g information inside an autonomous system (AS). An AS is a routing domain, such as inside an organization, that contacts its o wn routing. An EGP ex chang es routing information between ASes and provides for specialized policy-bound filtering and con figuration. IPSRD supports three interior gateway p rotocols: RIP (Routing Information Pro tocol), IGRP (Interior Gateway Routing Protocol), an d OSPF (Open Sho rtest Path First). Static routes and aggregate routes are also supp orted. For more information on static routes, see “Static Routes” on page 394. For more inform ation on aggregate routes, see “Route Aggregation” on page 398.
9 352 Nokia Network Voyager for IPSO 4.0 Refe rence Guide RIP RIP is a commonly used IGP . RIP version 1 is described in RFC 1058, and RIP version 2 is described in RFC 1723. IPSRD supports these ve rsion, as well as RIPng, which supports IPv6 interfaces. RIP uses a simple distance vector algorithm called Bellman Ford to calculate routes. In RIP , each destination has a cost or metric value, which is based solely on th e nu mber of hops between the calculating firewall and the given destination. The maximum metric value is 15 hops, which means that RIP is no t suited to networks within a diameter greater than 15 firewalls. The advantage of RIP version 2 over RIP version 1 is that it supports non-classful routes. Cl assful routes are old-style class A, B, C routes. Y ou should use RIP version 2 instead of RIP version 1 whenever possible. IGRP IGRP (Interior Gateway Routing Protocol) is a di stance vector protocol. IGRP has a number of metrics for each destination. Th ese metrics include link delay , ba ndwidth, reliability , load, MTU, and hop count. A sing le composite metric is formed by combin ing metrics with a particular weight. Like RIP version 1, IGRP does not fully support non-classful routing. OSPF OSPF (Open Shortest Path First) i s a modern link-state routing protocol. It is described in RFC 2328. It fully supports non-classful networks. OSPF has a single, 24-bit metric for each destination. Y ou can configure th is metric to any desired value. OSPF allows the AS to be brok en up into areas. Areas allow you to increase overall network stability and scalability . At area boundaries, routes can be aggregated to reduce the number of routes each firewall in the AS must know about. If there are multiple paths to a single destination with the same computed metr ic, OSPF can install them in to the forwarding table. DVMRP DVMRP (Distance V ector Multicast Routing Prot ocol) is a multicast routing protocol (RIP , OSPF , and IGRP are unicast routing protocols). Mul ticasting is typically used for real-time audio and video when there is a single source of data and multiple receivers. DVMRP uses a hop-based metric and, like RIP , a distance-vector route ca lc ulation. BGP BGP (Border Gateway Protocol) is an ex terior gateway protocol that is used to exchan ge network reachability information between BGP-speaking systems running in each AS. BGP is unlike interior gateway protocols (IGRP or OSPF ), which periodical ly flood an intra-domain network with all the known routing table entries and build th eir own reliability . Instead, BGP uses TCP as its underlying transport mechanism and sends update only when necessary .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 353 BGP is also a path-vector routing protocol, which limits the distribution of a f irewall’ s reachability information to its peer or neighbor firewalls. BGP us es path attributes to provide more information about ea ch route. BGP maintains an AS pa th, which i ncludes the number of each AS that the route has transited. Path attrib utes may also be u sed to distinguish between groups of routes to determine administrative pr eferences. This allows greater flexibility in determining route preference and achiev es a varie ty of administrative ends. BGP supports two basic types of sessions between neighbors: internal (IBGP) and external (EBGP). Internal sessions run between firewalls in the same autonomous systems, while external sessions run between firewalls in differ ent autonomous systems. Route Map s Route maps are used to con t rol which routes are accepted and announced by dynamic routing protocols. Use route maps to configure inboun d route filters, outbound route filters and to redistribute routes from one protocol to an other . Y ou can define route maps only using the CLI, th is feature is not available in Network V oyager . For information on route map commands, see the CLI Refer ence Guide . Route maps support both IPv4 and IPv6 protoc ols, including RIP , BGP , RIPng, OSPFv2, and OSPFv3. BGP-4 policy can o nly be specified us ing route maps. For the other protocols , you can use either route maps or the Route Redist ribution and Inbound Rout e Filters features that you configure u sing Network V oyager . Route ma p for import policy corresponds to Inbound Route Filters; route map for export polic y corresponds to R out e Redistribution. Note Route maps of fer more configuration options than the Network V oyager configuration for route redistrib ution and inbound route filt ers. They are not functionally equivalen t. Protocols can use route maps for redistribution and Network V oyager settings for inbound route filtering and vice versa. However , if one or more route maps are assigned to a protocol (for import or export) any correspon din g Network V o yager configuration (for route redistribution or inbound route filte rs) is ignored. OSPF Open Shortest Path First (OSPF) is an interior gateway protocol (IGP) used to exchange ro uting information between routers within a single auto nomous system (AS). OSPF calculates the best path based on true costs using a me tric assigned by a network administrator . RIP , the oldest IGP protocol chooses the least-cost path based on ho p count. OSPF is more ef fi cient than RIP , has a quicker convergence, and prov ides equal-cost multipath routin g where packets to a single destination can be sent using more than one interface. OSPF is suitable for complex networks with a large number of routers. It can coexist with RIP on a network.
9 354 Nokia Network Voyager for IPSO 4.0 Refe rence Guide IPSO supports OSPF v2, which supports IPv4 addressi ng, and OSPFv3, which sup ports IPv6 addressing. T ypes of Areas Routers using OSPF send packets called Link Stat e Advertisements (LSA) to all routers in an area. Ar eas are smaller groups within the AS that you can design to limit the flooding of an LSA to all routers. LSAs do not leav e the area from which they origin ated, thus increasing efficiency and saving network ba ndwidth. Y ou must specify at least one area in your OSPF network—the backbone a r ea , which has the responsibility to propagate information betwee n areas. The backbone area has the identifier 0.0.0.0. Y ou can designate other areas, d epending on your netwo rk design, of the following ty pes:  Normal Area —Allows all LSAs to pass through. The backbone is always a normal area.  St u b A r e a —Stub areas do not allow T ype 5 LSAs to be prop agated into or throughout th e area and instead depends on default routing to external destinations. Y ou ca n configure an area as a stub to reduce the number of entries in the routing table (routes external to the OSPF domain are not added to the routing table).  NSSA (Not So S tubby Area) —Allows the import of external routes in a limited fashion using T ype-7 LSAs. NSSA border route rs transl ate sele cted T ype 7 LSAs into T ype 5 LSAs which can then be flooded to all T ype -5 capable areas. Configure an area as an NSSA if you want to reduce the size of the routing tabl e, but still want to allow routes that are redistributed to OSPF . It is generally recommended that you l imit OSPF areas to about 50 routers based on the limitations of OSPF (traf fic overhead, ta ble size, convergence, and so on). All OSPF areas must be connected to the back bone area. If you have an area that is not connected to the backbone area, yo u can conn ec t it by configuring a virtual link , enabling the backbone area to appear contiguous despite the physical reality . Note If you need to connect two ne tworks that b oth alread y have ba ckbo ne ar ea s and you do no t want to reconfigure one to something othe r than 0.0.0.0, you can co nnect the two backbone areas using a virtual link. Each router records information about its interfaces when it initializes and builds an LSA packet. The LSA contains a list of all recently seen rout ers and their costs. The LSA is forwarded only within the area it originated in and is flooded to all other rout ers in the area. The information is stored in the link-state database, which is identical on all routers in the AS.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 355 Area Border Routers Routers called Ar ea Bor der Routers (ABR) have interfaces to multip le areas. ABRs compact the topological information for an area and transm it it to the backbone ar ea. Nok ia supports the implementation of ABR behavior as outlined in the Internet draft of the Internet Engineering T ask Force (IETF). The definit ion of an ABR in the OSPF specification as outlined in RFC 2026 does not require a router with mu ltiple attached areas to have a backbone connection. However , under this definition, any traffic destined for areas that are not co nnected to an ABR or that are outside the OSPF domain is dropped. According to th e Internet draft, a router is considered to be an ABR if it has more than one area actively attach ed and one o f them is the back bone area. An area is considered actively attached if the router has at leas t one interface in that area that is not down. Rather than redefine an ABR, the Nokia impl ementation includes in its routing calculation summary LSAs from all actively attached areas if th e ABR does not have an active backbone connection, which means th at the backbone is actively attach ed and includes at least one fully adjacent neighbor . Y ou do not need to configur e this feature; it functions automatically under certain topographies. OSPF uses the following types of routes:  Intra-area —Have destinations w ithin the same area.  Interarea —Have destinations in other OSPF areas.  Autonomous system external (ASE) —Have destinations external to the autonomous system (AS). These are the rout es calculated from T ype 5 LSAs .  NSSA ASE Router —Have destinations external to AS . These are the routes calculated from T ype 7 LSAs. All routers on a link must agree on the configura tion parameters of the li nk. All routers in an area must agree on the configuration parameters of the area. A separate copy of the SPF algorithm is run for each area. Misconfiguratio ns prevent adjacencies from forming between neighbors, and routing b lack holes or loops can form. High A vailability Support for OSPF VRRP IPSO supports the advertising of the virtual IP address of the VRRP virtual router . Y ou can configure OSPF to advertis e the virtual IP addres s rather than the ac tual IP address of the interface. Y ou must use monitored-circuit VRRP , not VRRP v2, when configuring virtual IP support for OSPF or any other dynamic routing pr otocol. If you enable this option, OSPF runs only on the master of the virtual router; on a failover , OSPF stops running on the old master and then starts running on the new master . A traffic break might occur during the time it takes both the VRRP and OSPF protocols to learn the routes again. Th e larger the network, the more time it takes OSPF to synchronize its database and install routes again. For more info rmation on enabling the advertising of a virtual IP address when running OSPF , see “C onfiguring OSPF ,” step 14f.
9 356 Nokia Network Voyager for IPSO 4.0 Refe rence Guide IPSO also supports OSPF over VPN tunnels that terminates at a VRRP group. Only active- passive VRRP configurations ar e su pported, active-active configuratio ns are not. Clustering IPSO supports OSPF in a cluster . Each member of a cluster runs OSPF tasks, but only the master changes the state and sends OSPF messages to the ex ternal routers. For more information on IP Clustering, see “IP Clus tering Description.” Note IPSO does not support OSPFv3 in an IP cluster . Nokia strongly recommends that yo u not configure OSPF or any other routin g protocol on the primary or secondary cluster protocol in terfaces of an IP cluster . Configuring OSPF T o configure OSPF on your system , you must complete the following: 1. Specify a Router ID. The Router ID uniquely identifies the router in the autonomous system. By default, the system selects a non-loopback address assigned to the loopback interface, if one is available , or an address from the list of active addresses. Nokia recommends that you configure the router ID rather than accepting the system default value. This prevents the router ID from changi ng if the interface used for the router ID goes down. In a cluster environment, you must sel ect a router ID because there is no default value. Although you do not need to use an IP address as the router ID, you mu st enter a dotted quad value ([0-255].[0-255].[0-2 55].[0-255]. Do not use 0.0.0.0 as a router ID. 2. Define the OSPF areas, an d global settings on each platform, as described in “Configuring OSPF Areas and Global Settings.” 3. Configure each interface that participates in OSPF as described in “Configuring OSPF Interfaces.” Note OSPFv3, which support s IPv6, has essentially the same configuration p arameters as OSPFv2, except that you enter them from t he Network V oyager pag e accessed by clicking Config > IPv6 Conf iguration > OSPFv3.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 357 Configuring OSPF Area s and Global Settings Ta b l e 2 1 lists the parameters for areas and global settings that you use when configuring OSPF on your system. As you add area s, each is displayed with its own configuration parame ters under the Areas section. T able 22 describes the configuration pa rameters for stub areas. These fields appear if you define the area as a stub area . Ta b l e 2 3 de scribe s the configuration parameters for NSSA areas. These fields appear if you define the area as an NSSA (Not So Stubby Area). For more information on NSSA, see RFC 3101. T able 21 OSPF Area Configuratio n Parameters Parameter Description Add New Address Ra nge Y ou can configure any area with any number of address ranges. Use these ranges to reduce the number of routing entries that a given area emits into the backbone and thus all areas. If a given prefix aggreg ates a number of more spec if ic prefixes within an area, you can configure an address that becomes the only prefix advertised into the backbone. Y ou must be careful when c onfig uring an address range that covers parts of a prefix not cont ain ed within the area. By defi nition , an address range consists of a prefix and a mask length. Note: Y ou can prevent a specific prefix from being advertised into th e backbon e, by selecting On in the Restrict field next to the entry for that prefix. Add New S tub Network OSPF can advertise reachabili ty to prefix es that are not running OSPF using a stub network. The advertised prefix appears as an O SPF i nternal route and can be filtered at area borders with the OSPF area ranges. The prefix mu st be directly reachable on the router where the stub netwo rk is configured; that is, on e of the router's interfac e addresses must fall within the prefix to be included in the router-LSA. Y ou configure stub hosts by specifying a mask length of 32. This feature also supports advertising a pref ix and mask that can be activated by the local address of a point-to-point interface. T o advertise reachability to such an address, enter an IP address for the prefix and a cost with a value ot he r th an zero . Area T ype Choose Normal, S tub, or NSSA. For descripti ons of area types, see “T ypes o f Areas” on page 354. T able 22 Stub Ar ea Parameters Parameter Description Cost for Default Route Enter a cost for the defa ult route to the stub area. Range: 1-16777215. There is no default. Import Summary Routes Specifies if summary routes (summary link advertisements) are imported into the stub area or NSSA. Each summary link advertisement descr ibes a route to a destination outside the area, yet still inside the AS (i.e. an inter-area route). These include routes to netw orks and routes to AS boundary routers. Default: On.
9 358 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure OSPF , use the following procedure. T able 23 NSSA (Not So Stubb y Area) Parameters Parameter De scription T ranslator Role Spec ifies whether this NSSA border rout er will unconditionally translate T ype-7 LSAs into T ype-5 LSAs. When role is Always , T ype-7 LSAs are translated into T y pe-5 LSAs regardless of the translator state of other NSSA border routers. When role is Candida te , this router participates in the translator election to determine if it wil l perform the translati ons duties. If this NSSA router is not a border router , then this opti on has no effect. Default: Candidate. T ranslator St ability Interval Specifies how long in seconds this el ected T ype-7 translator will co ntinue to perform its translator duties once it has determined that its translator status has been assumed by anothe r NSSA border router . This field appea rs only if an area is defined as an NSSA with translator role as Candidate. Default: 40 seconds. Import Summary Routes Specifies if summary routes (summary lin k advertisement s) are imported into the stub area or NSSA. Each su mmary link advertisement describes a route to a destin ation outside the area, ye t still inside the AS (i.e. an inter- area route). These in clude routes to networks and routes to AS boundary routers. Default: On. Cost for Default Route Enter a cost asso ciated with the default route to the NSSA. Default Route T ype Specifies the route type as sociated with the T ype-7 default route for an NSSA when routes from other protoc ols are redistribut ed into OSPF as ASEs. If a redistributed route already has a route type, this type is maintained. If summ ary routes are impor ted into an NSSA, only then a T ype- 7 default route is generated (otherwise a T ype-3 default route is generated). This field appears only if an area is defined as an NSSA into which summary routes are im po rted. The route type can be either 1 or 2. A type 1 route is internal and its metric can be used dire ctly by OSPF for comp arision. A type 2 route is externa l and its metric cannot be used for comparision directly . Default: 1 Redistribution Specifies if both T ype-5 and T ype-7 LSAs or only T ype -7 LSAs will be originated by this router . This option wil l have effect only if this router is an NSSA border router and this router is an AS border router . Default: On T ype 7 Address Ranges An NSSA border router that performs translation duties translates T ype-7 LSAs to T ype-5 LSAs. An NSSA border router can be configured with T ype- 7 address ranges. Use these ranges to reduce the n umber of T ype-5 LSAs. Many separate T ype-7 networks may fall into a single T ype-7 address ra nge. These T ype-7 networks are aggregated and a single T ype-5 LSA is advertised. By definition, a T ype-7 a ddress range consists of a prefix and a mask length. Note : T o prevent a specific prefix from being advertised, select On in the Restrict field next to the entry for that prefix.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 359 T o configure OSPF 1. Complete “Ethernet Interfaces” for the interface and assign an IP address to the interface. 2. Click OSPF under Config ur ation > Routing Configuration in the tree view . 3. Enter the router ID in the Router ID text box. 4. If you want to define additional OSPF areas besides the backbone area: a. Enter each name in the Add New OSPF Area text field and click Apply . b. Select an Area T ype—Normal, S tub, or NSSA. For more information, see “T ypes of Areas” on page 354. c. If you select a stub or NSSA area type, conf igure the additional parameters that appear , as described in Ta b l e 2 2 and Ta b l e 2 3 . 5. (Optional) For each area, you can add one or mo re address ranges if you want to reduce the number of routing entri es that the area advertis es into the backbone. Note T o prevent a specific prefix fro m being adver tised into the ba ckbone, click t he On button in the Restrict field next to the entry for that prefix. 6. Configure virtual links for any area that does no t connect directly to the backbone area, as described in “Configuring V irtual Links” on page 35 9. 7. Configure the OSPF interf aces, as described in “T o configure an OSPF interface” on page 363. Configuring V irtual Links Y ou must configure a virtual link fo r any area th at does not conn ect di rectly to the backbone area. Y o u configure the virtual link on both th e ABR for the disconti guous area and another ABR that does connec t to the backbone. The virtual link acts like a point -to-point link. Th e routing protocol traffic that flows along the virtual link uses intra-area routing only . T o configure a virtual link 1. Create an area that does not connect directly to the backbone area and configure an interface to be in that area. 2. In the Add a New V irtual Link te xt field, enter the router ID of the remote endpoint of the virtual link. 3. Select the transit ar ea from the drop-down b ox . This is th e area that connects both to the backbone a nd to the discontiguous area. Additional fields appear . 4. Configure the following para meters for the virtual link:
9 360 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Hello interval —Length of time, in seconds, between hello packets that the router sends on the interface. For a given link, this field must be the same on all routers or adjacencie s do not form. Default: 30.  Dead interval —Number of seconds after the router stops receiving hello packets that it declares the neighbor is down. T ypically , the value of this field should be four times that of the hello interval. For a given link, this value must be the same on all routers, or adjacencies do not form. The value must not be zero. Range: 1-65535. Default: 120.  Retransmit interval —Specifies the number of seconds between LSA retransmissions for adjacencies belonging to th is interface. This value is also used when retransmitting database description and link state request packets. Set this value well above the expected round-trip delay between any tw o routers on the att ached network. Be conservative when setting this value to prevent un necessary retransmissions. Range: 1-65535 in number of seconds. Default: 5.  Auth T ype —T ype of authentication scheme to use for a given link. In general, routers on a given link must agree on the authentication co nfiguration to form neighbor adjacencies. This feature guarant ees that routing informa tion is accepted only from trusted routers. Options: None / Simple / MD5. Default: None. 5. If you selected MD5 for the auth type, you mu st also configure the following parameters:  Add MD5 Key — If the Auth type selected is MD5, the Key ID and MD5 Secret fields appear . Specify the Key ID and its corresp onding MD5 secret to configure a new MD5 key . If you configure mul tiple Key IDs, the Key ID with the highest value is used to authenticate outgoing packets. All keys can be used to authenticat e incoming packets.  Key ID —The Key ID is included in the outgoing OSPF packets to enable the receivers to use the appropriate MD5 secret to authenticate the packet. Range: 0-255. Default: None  MD5 Secret —The MD5 secret is included in encr ypted form in outgoing packets to authenticate the packet. Range: 1-16 alphanumeric characters. Default: None 6. Click Apply . 7. T o make your changes permanent, click Save. 8. Repeat this procedure on both the ABR for the discontiguous area and an ABR that connects to the backbone area. Configuring Global Settings Ta b l e 2 4 shows the global settings that you can sp ecify for OSPF . Configure these settings by clicking OSPF under Configuration > Routing Config uration in the tree vi ew and scrolling down to these fields.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 361 T able 24 Global Settings for OSPF Parameter Description RFC1583 Compatibility This implementation of OSPF is based on RFC2178, which fixed some looping problems in an earlier sp ecification of OSPF . If your i mplementation is running in an environment with OSPF implementations based on RFC158 3 or earlier , enable RFC 1583 compatibility to ensure backwards compatibility . SPF Delay Specifies the time in seconds the system will wait to recalculat e the OSPF routing table after a change in topolog y . Default is 2. Range is 1-6 0. SPF Hold Specifies the minimum time in second s between recalculations of the OSPF routing table. Default is 5. Range is 1-60. Default ASE Route Cos t Specifies a cost for routes redistributed into OSPF as ASEs. Any cost previously assigned to a redistributed routed ov erride s this value. Default ASE Route T ype Specifies a route type for routes redistribut ed into OSPF as ASEs, unless these routes already have a type assigned. There are two types: • T ype 1 external: Used for routes imported into OSPF which are from IGPs whose metrics are directly comparable to OSPF metrics. When a routing decision is being made, OSPF adds the internal cost to t he AS border router to the exte rnal metric. • T ype 2 external: Used for routes whose metrics are not comparable to OSPF internal metrics. In this ca se, only the exte rnal OSPF co st is us ed. In the ev ent of ties, the least cost to an AS border router is used.
9 362 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring OSPF Interfaces Ta b l e 2 5 lists the parameters for interfaces that you use when configuring OSPF o n your platform. T able 25 Configuration Parameters for OSPF Interf ace s Parameter Description Area The drop-down list displays all of the areas configu red and en abled on your platform. An entry fo r the backbone area is d isplayed even if it i s disabled. An OSPF area defines a group of router s running OSPF that have the comple te topology information of the given area. OSPF areas use an area border router (ABR) to exchange information about routes. Routes for a given area are summarized into the b ackbone area for d istribution into oth er non-backbone areas. An ABR must have at least two inte rfaces in at least two different areas. For information on adding an area “Con figuring OSPF Areas and Global Settings” on page 357. Hello interval Speci fies the length of time in seconds between hello packets that the router sends on this interface. For a given link, this value must be the same on all routers, or adjacencies do not form. Range: 1-65535 in seconds Default: For broadcast interfaces, the de fault hello interval is 10 seconds. For point-to-point interfaces, the default hello interval is 30 seconds. Dead interval Specifies the number of seconds afte r the router stops receiving hello packets that it declares the neighbor is down. T ypically , this value should be four times the hello interval. For a given link, this value must be the same on all routers, or adjacencies do not form. The value must not be 0. Range: 1-65535 in seconds. Default: For broadcast interfaces, the default dead interval is 40 second s. Fo r point-to-point interfaces, the default dead interval is 120 seconds. Retransmit interval Specifies the number of seconds between LSA retransmissions for this interface. This value is al so used when re transmitting database description an d link state request packets. Set this value well abov e the expected round-trip delay between any two routers on the attached network. Be conservative when setting this value to prevent necessary retransmissions. Range is 1-65535 in seconds. Default is 5 . OSPF cost Specifies the weight of a given path in a route. The higher the cost you configure, the less preferred the li nk as an OSPF route. For example, you can assign different relative costs to two interfaces to make one more preferred as a routing path. Y ou can explicitly override this value in route redistrib ution. Range is 1-65535. Default is 1.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 363 T o configure an OSPF interface 1. Assign the appropriate area to each interface by selecting the OSPF area that this interface participates in from the Area drop-down lis t for the interface, then click Apply . The OSPF interface configur ation parameters are displayed sh owing the default settings. If you want to accept the defa ult settings for the interface, no further action is necessary . Election priority Specifies the priority for be coming the designated route r (DR) on this link. When two routers attached to a network both attempt to become a designated router , the one with the highest priori ty wins. If there is a current DR on the l ink, it remains the DR regardless of the configur ed priority . This feature prevents the DR from changing too often and app lies only to a shared-media interfa ce, such as ethernet or FDDI. A DR is not elected on point-to-point type inte rfaces. A router with priority 0 is not eligible to become the DR. Range is 0-255. Default is 1. Passive mode Specifies that the interface does not send hello packets, which means that the link does not form any adjacencies. This mode enables the network a ssociated with the interface to be included in the intra-area route calculation rather than redistributing the network into OSPF and having it as an ASE. In passive mode, all interface configura ti on information, wit h the exception of the associate d area and the cost, i s ignored. Options are On or Off. Default is Off. Virtual address Makes OSPF run only on the VRRP Virtual IP address a ssociated with this interface. If this router is not a VRRP master , then OSPF will not run if thi s option is On. It will only run on the VRRP mast er . Y ou must also configure VRRP to accept connections to VRRP IPs. For more information, se e “Configuring Monitored-Circuit VRRP” on page 192. Options are On or Off. Default is Off Authorization type Specifies which ty pe of authentication scheme to use for a given link. In general, routers on a given link must agree on the authe ntication configuration to form neighbor adjacencies. Th is feature g uarantees that routing i nformation is accepted only from trusted routers. Options for authentication are: • Null: Does not authenticate packet s. This is the default option. • Simple: Uses a key o f up to eight characters.Provides little p rotection because the key is sent in the clear , and it is possible to capture packets from the network and learn the auth entication key . • MD5: Uses a key of up to 16 characters . Provides much stronger protection, as it does not include the authenticati on key in the packet. Instead, it provides a cryptographic hash based on the confi gured key . The MD5 algorithm creates a crypto checksum of an OSPF packet and an authentication key of up to 16 characters. The receiving router perfo rms a calcul ation usin g the correct authentication key and discards the pa cket if the key does not match. In addition, a sequence numb er is maintain ed to prevent the replay of older packet s. T able 25 Configuration Parameters for OSPF Interf ace s Parameter Description
9 364 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 2. (Optional) Change any con figuration parame ters for the interface , th en click Apply . Note The hello interval, d ead interval, and authent ication method must be the same for all routers on the link. 3. T o make your changes permanent, click Save. Configuring OSPF Example This example consists of the following:  Enabling OSPF with backbone ar ea (Area 0) on one interface  Enabling OSPF on Area 1 on another interface  Summarizing and aggregating the 192.168.24.0/24 n etwork from Area 0 to Area 1 In the following diagram:  Nokia Platform A and Nokia Platform D are gateways.  Nokia Platform C is an area border router with Interface e1 on the back bone area (Area 0), and Interface e2 on Area 1.  Nokia Platform A and Nokia Platfo rm B are on the backbone area.  Nokia Platform D is on Area 1. The routes in Ar ea 0 are learned by Nokia Platfo rm D when the ABR (Nokia Platform C) injects summary link state advertisem ents (LSAs) into Area 1. 1. Configure the interfaces as in “Ethernet Interfaces.” 2. Initiate a Network V oyager sess ion to Nokia Platform C. 3. Click OSPF under Config ur ation > Routing Configuration in the tree view . 4. Click the backbone area in the drop-do wn list for e1; then click Apply . Nokia Platform A Nokia Platform D Nokia Platform B 24.58/30 Area 0 Area 1 24.57/30 24.46/30 24.49/30 24.50/30 e1 24.53/30 e2 24.54/30 e3 24.45/30 00340 Nokia Platform C
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 365 5. In the Add New OSPF Area text box, enter 1 ; then click Apply . 6. In the Add new ad dress rang e: p ref ix text box for th e backbon e area, enter 192.168.24.0. 7. In the Mask Length text box, enter 24 ; then click Apply . 8. Click 1 area in the drop-down list for e2 ; then click Apply . 9. Click Save. 10. Initiate a Network V oyager sess ion to Nokia Platform D. 11 . Click Config on the ho me page. 12. Click the OSPF link in the Rou ting Configuration section. 13. In the Add New OSPF Area text box, enter 1; then click Apply . 14. Click 1 area in the drop-down list for e3, then click Apply . 15. Click Save. RIP The Routing Information Pr otocol (RIP) is one of the oldest, and still widely used, interior gateway protocols (IGP). RIP uses only the number of hops be tween nodes to de termine the cost of a route to a destination network an d does not consider n etwork congestion or link sp eed. Other shortcomings of RIP are that it can create excessive network traffic if there are a large number of routes and that it has a slow convergence time and is less s ecure than other IGPs, such as OSPF . Routers using RIP broadcast their routing tables on a periodic basis to other routers, whether or not the tables have changed. Each update cont ai ns paired values consisting of an IP network address and a distance to that network. The distance is expressed a s an integer , the hop count metric . Directly connected networks have a metri c of 1. Networks reachable through on e other router are two hops, and so on. The maximum number of h op s in a RIP ne twork is 15 and the protocol treats anything equa l to or greater than 16 as unreachable. RIP 2 The RIP version 2 protocol adds capabilities to RIP . Some of the most notable RIP 2 enhancements follow . Network Mask The RIP 1 protocol assumes that all subnetwork s of a given network have the same network mask. It uses this assumption to calculate th e network masks for all routes received. This assumption prevents subnets with different netw ork masks from being included in RIP packets. RIP 2 adds the ability to explicitly specify th e network mask for each network in a packet.
9 366 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Authentication RIP 2 packets also can contain one of two types of authentication methods that can be used to verify the validity of th e supplied routing data. The first method is a simple pass word in which an auth entication key of up to 16 characters is included in the packet. If this password does not ma tch what is expected, the packet is discarded. This method provides ve ry little security , as it is possible to learn the authentication key by watching RIP packets. The second me thod us es the MD 5 algorit hm to c reate a cr ypto ch ecksu m of a RIP pac ket and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead, it c ontains a crypto-che cksum called the digest . The receiving router performs a calculation using the correct authentication key and discar ds the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides stronger assu rance th at routing data originated from a router with a valid authentication key . RIP 1 Network Mask RIP 1 derives the network mask of received networks and hosts from the network mask of th e interface from which the packet was receive d. If a received network or host is on the same natural network as the interface over which it was received, and that network is subnetted (the specified mask is more specific than the natural network mask), then the subnet mask is applied to the destination. If bits outsid e the mask are set, it is assumed to be a host; otherwise, it is assumed to be a subnet. Auto Summarization The Nokia implemen tation of RIP 1 supports auto summarization; this allows the router to aggregate and redistribute nonclassful routes in RIP 1. V irtual IP Address Support for VRRP Beginning with IPSO 3.8.1, Nokia su pports the advertising of the virtual IP address of the VRRP virtual router . Y ou can configure RIP to advertise the virtual IP address rather than the actual IP address of the interface. If you enable this option, RIP runs only on the master of the virtual router; on a failover , RIP stops running on the old master and then starts running on the new master . A traffic break might occur during the tim e it takes both the VRRP and RI P protocols to learn the routes again. The larger the network, the more time it would take RIP to synchronize its database and install routes again. For more information on enabling the ad vertising of a virtual IP address when running RIP , see “Configuring RIP ,” step 12.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 367 Note Nokia also provides support for BGP , OSPF , and PIM, both Sp arse-Mode an d Dense-Mode, to advertise the virtual IP address of th e VRRP virtual router , beginning with IPSO 3.8. Note Y ou must use Monitored Circuit mode wh en con f iguring virtual IP support for any dynamic routing protocol, including RIP . Do not use VR RPv2 when configuring virtual IP support for any dynami c routin g pr ot ocol. Configuring RIP Using Network V oya ger, you can configure the following op tions: T o configure RIP 1. Complete “Ethernet Interfaces” for the interface. 2. Click RIP under Configuration > Routin g Configuration in the tree view . 3. Click on for each interface to co nfigure; then click Apply . 4. Click either 1 or 2 in the V ersion field to select RIP 1 or RIP 2, respectively , for each interface; then click Apply . T able 26 RIP 1 Conf iguration Opti ons A vailable from Network V oyager Option Description V ersion Y ou an use either RIP 1 or RIP 2. RIP interfaces Y ou can specify the interfaces on which to run RIP . Metric Y ou can adjust the metric to a giv en interface to something other than the number of hops. Y ou can use this adjustme nt to trick the router into taking a better path, for example one that has a faster link speed even though it may have more hops. Accept updates Y ou can configure whether or not to accept updates from other routers speaking RIP . Accepting updates specifies w hether RIP packets received from a specified interface is accepted or ignor ed. Ignoring an upda te can result in suboptimal routing . Theref ore, Nokia recommends that you retain the default setting for accepting upd ates. T ransport Y ou can set this option only for R IP 2. Y ou can set either broadcast or multicast. The RIP 2 option should always be set to multicast unless RIP 1 neighbors exis t on the same link and it is desired th at they hear the rou ting updates. Auto summarization Y ou should se t auto summarization to aggregat e and redistribute nonclassful routes in RIP 1.
9 368 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. (Optional) Enter a new cost in the Metric te xt box for each interface; then click Apply . 6. (Optional) T o configure the interface to not a ccept updates, click on the on radio button in the Accept updates fiel d; then click Apply . 7. (Optional) If you want to co nfigure the interface to not send updates, cli ck on in the Send updates field; then click Apply . 8. (Optional) If you selected RIP 2 for an interface , make sure that Multic ast i s turned on for that interface; then click Apply . Note When you use RIP 2, always select the mu lticast option. Nokia recommends that you not operate RIP 1 and RIP 2 together . 9. (Optional) If you selected RIP 2 for an interface, select the type of authen ticati on scheme to use from the AuthT y pe drop-d own list; then click Apply . For simple authentication, select Simple from the AuthT y pe dr op-down window . Enter the password in the Password ed it box; then click Apply . The password must be from 1 to 16 characters long. For MD5 authentication, select MD5 from the Au thT ype drop-down list. Enter t he password in the MD5 key text box; then click Apply . 10. (Optional) If you selected MD5 as your authentication t ype and want to ensure interoperability with Cisco routers running RIP MD5 authentication, click YES in the Cisco Interoperability field. The default is no, which means that RI P MD5 is set to conform to Nokia platforms. Click Apply . 11 . T o enable RIP on the virtual IP address associ ated with this interface, click On; then click Apply . This option functions only if this router is a VRRP master . Y ou must also configure VRRP to accept connections to VRRP IPs. Note Y ou must use Monitored Circuit mode when co n figuring virtual IP support. Do not use VRRPv2 when configurin g virtual IP support. 12. T o make your change s pe rmanent, click Save. Configuring RIP T imers Configuring RIP timers allows yo u to vary the frequency with which updates are sent as well as when routes are expired. Use care when you set these parameters, as RIP has no protocol mechanism to detect misconfiguration.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 369 Note By default, t he update inter val is set to 3 0 seconds an d the expire interval is set to 180 seconds. 1. Click RIP under Configuration > Routin g Configuration in the tree view . 2. T o modify the update interval, enter the new upda te interval in the Update Interval text box; then click Apply . 3. T o modify the expire interval en ter the new expire inte rval in the Expire Interval text box; then click Apply . 4. T o make your changes permanent, click Save. Configuring Auto-Summarization Auto-summarization allows yo u to aggregate an d redistribute non-classful routes in RIP 1. Note Auto-summarizatio n applies only to RIP 1. 1. Click RIP under Configuration > Routin g Configuration in the tree view . 2. T o enable auto-summarization, click on in the Auto-Summarization field; then click Apply . 3. T o disable auto-summarization cli ck off in th e Auto-Summarization field; then click Apply . 4. T o make your changes permanent, click Save. Note By default, a uto-summariz ation is ena bled. RIP Example Enabling RIP 1 on an Interface RIP 1 is an interior gateway protocol that is most commonly used in small, homoge neous networks. 1. First configure the interface as in “Ethernet Interfaces.” 2. Click RIP under Configuration > Routin g Configuration in the tree view . 3. Click on for the eth-s2p1c0 interface; then click Apply . 4. (Optional) Enter a new cost in the Metric ed it box for the eth-s2p1c0 interface; then click Apply .
9 370 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Enabling RIP 2 on an Interface RIP 2 implements new capabilities to RIP 1: authentication—simple and MD5—and the ability to explicitly specify the network mask for e ach network in a packet. Be cause of these new capabilities, Nokia recommends RIP 2 over RIP 1. 1. First configure the interface as in “Ethernet Interfaces.” 2. Click RIP under Configuration > Routin g Configuration in the tree view . 3. Click on for the eth-s2p1c0 interface; then click Apply . 4. Click on in the V ersion 2 field for the eth-s2p1c0 interface; then click Apply . 5. (Optional) Enter a new cost in the Metric text box for the eth-s2p1c0 interface; then click Apply . 6. (Optional) Select MD5 in the Auth T ype drop-down list; then click Apply . Enter a key in the MD5 key text box; then click Apply . PIM Protocol-Independent Multic ast (PIM) g ets its na me from the fact that it can work with any existing unicast protocol to pe rform multicast forwarding. It su pports two types of multipoint traffic distribution patterns: dense and sparse. Dense mode is most useful when:  Senders and receivers are in close proximity .  There are few senders and many receivers.  The volume of multicast traffic is high.  The stream of multicast traffic is constant. Dense-mode PIM resembles Distance V ector Multicast Routing Protocol (DVMRP). Like DVMRP , dense-mode PIM uses Re ve rse Path Forwarding and the flood-and-prune model. Sparse mode is mos t useful when:  A group has few receivers.  Senders and receivers are separated by W AN links.  The type of traf fic is intermittent. Sparse-mode PIM is based on the explicit join model; the protocol sets up the forwarding state for traffic by sending join messages. This model represents a substanti al departure from flood- and-prune protoc ols, such as dense-mo de PIM, which set up the forwarding state through he arrival of multicast data. The implementation does not support enabling both de nse mode and sparse mode or either mode of PIM and DVMRP on the same appliance. For more information about PIM, read the following Internet Engineerin g T ask Force (IETF) drafts. For Dense-Mode PIM, see Protocol-Independen t Multicast—Dense Mode (PIM-DM): Protocol Specification (Revised).
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 371 For Sparse-Mode PIM, see Protoc ol-Independen t Multicast —Sparse Mod e (PIM-SM) : Protocol Specification (Revised). Configuring V irtual IP Support for VRRP The virtual IP option lets you configure either a PIM sparse-mode or PIM dense-mode interface to advertise the VRRP virtual IP address if the router transitions to become VRRP master after a failover . When you enable virtual IP support for VRRP on a PIM interface, it establishes the neighbor relationship by u sing the virtual IP if the router is a VRRP master . The master in the VRRP pair sends hello messages that include the virtual IP as the source address and processes PIM control messages from routers that neighbor the VRRP pair . For more information on how to configure this option through Network V oyage r , see either “Configuring Dense-Mode PIM” or “Configuring Sp arse-Mode PIM.” Note Y ou must use monitored-circuit VRRP when c onfiguring virtual IP support fo r any dynamic routing protocol, including PIM. Do not use VR RPv2 when configuring virtual IP support for any dynami c routin g pr ot ocol. PIM Support for IP Clustering Beginning with IPSO 3.8.1, No kia supports PIM, both Dense-Mode and Sparse-Mode, in a cluster . Nokia also supports IGMP in a cluster . IPSO clusters have three modes of op eration. T o use PIM, either Dense-Mode or Sparse-Mode, in an IP cluster , you must use either multicast mode or multicast mode with IGMP as the cluster mode. Do not use forwardin g mo de . For mo re information about IP clustering, see “IP Clustering Description” on page 207 Note Nokia strongly recommends that you no t configure PIM or any ot her routing protocol o n the primary or secondary clus ter protocol interfaces of an IP clust er . PIM Dense-Mode In the Nokia implementation of PIM Dens e-Mode (PIM-DM), all the nodes process PIM c ontrol traffic received by the cluster , and only the master processes most of the control traffic sent from the cluster . However, hello messages, for exam ple, are sent by all nodes. Some multicast switches do not forward multicas t traf fic to interfaces from which they have not received any multicast traffic. T o avoid having a multicast switc h fail to forward multicast traffic, all cluster nodes send periodic PIM hello messages. All mess ages from each cluster member have the s ame source IP address, generation ID, holdtime and designated router priority . Therefore, all neighboring routers view the cluster as a sing le neighbor eve n thoug h they receive hello messages from all members of the cluster .
9 372 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note The generation ID included in all PIM hello messages does not change whe n IP clustering is used, regard le ss of wh et he r an d ho w ma n y time s PIM is re-e na b led . W hen IP cluste rin g is implemented, the generat ion ID is base d on the clus ter IP addre ss so that all m embers advertise the same address. The gen eration ID included in PIM hello messages of all cluster nodes does not change un less the cluster IP address is changed. The multicast data traf fic is load-balanced and ca n be processed by any of the cluster members. All cluster members sync the dense-mode forwarding state with each other member; therefore, if any cluster member fails, the new member responsi ble for the corresponding data traffic has the same state as the member that failed. PIM Sp arse-Mode In the Nokia implementation of PIM Sparse-Mo de (PIM-SM), depending on its location, the cluster can function as the designated router , the bootstrap router, the rendezvous point or any location in the source or shortest-path tree (S P T). All the nodes pro cess PIM control traffic received by the cluster , and only the master pr ocesses most of the control traffic sent from the cluster . However , hello messages, for example, are sent by all nodes. Some multicast switches do not forward multicast traffic to interfaces from which they ha ve not received any multicast traffic. T o avoid having a multicast switch fail to fo rward multicast traffic, all cluster nodes send periodic PIM hello messages. All messa ges from each cluster member have the same source IP address, generation ID, holdtime and designated router priority . Therefore, all neighboring routers view the cluster as a single neighbor even though they receive hello messages from all members of the cluster . Note The generation ID included in all PIM hello messages does not change whe n IP clustering is used, regard le ss of wh et he r an d ho w ma n y time s PIM is re-e na b led . W hen IP cluste rin g is implemented, the generat ion ID is base d on the clus ter IP addre ss so that all m embers advertise the same address. The gen eration ID included in PIM hello messages of all cluster nodes does not change un less the cluster IP address is changed. The multicast data traf fic is load-balanced and can be processed by any member of the cluster . However , the cluster is the elected rendezvous point, only the master processes the encapsulated register messages until the SP T is created. Note For both PIM-SM and PIM- DM, the Nokia implem entation of IP cl ustering does not forw ard traffic addre ssed to 244.0.1.144. IP cl ustering uses multicast to communicate synchronization messages and has reserved mul ticast group a ddress 244.0.1.144 for this purpose. When IP clustering is enable d, IG MP membership messages for this grou p ar e sent on all in terfaces th at are part of the c luster . Moreover , since this mult icast group is not a link-local group, the designated route r on the LAN sends PIM (*, g) PIM messages for this group to the rendezvo us point when PIM-SIM is implemented. If the Nokia appliance is the
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 373 designated router , it does not generated such a join message, but it prop agates these join messages when sent by anothe r router . Configuring Check Point VPN-1 Pro/Express T o configure Check Point VPN-1 Pro/Express with IP clustering and either PIM-SM or PIM- DM, make sure you: 1. Use Check Point SmartDashboard to cr eate a nd configure the cluster gateway object. For more information on ho w to configure the cluster gateway object, see “Configuring NGX for Clustering” on page 241. 2. Click the 3rd Party Configuration tab and conf igure as follows only when PIM-SM or PIM- DM is enabled with IP Clustering: a. For the availability mode of the gatewa y cluster object, select load sharing. b. In the third-party drop-down list, select Nokia IP clustering. c. Make sure that the check box ne xt to Forw ard Cluster Members’ IP addresses is not checked. If it is checked, click on th e check box to remove the check. Make sure that all the other available check boxes are checke d. Note All available check boxes should be checked if you are not enablin g PIM-SM or PIM-DM in an IP cluster . d. Click Ok to save your changes. PIM and Check Point SecureXL T o make sure that your PIM connections stay accelerated if you have enabled SecureXL, you need to increase the Check Point firewall stateful inspection timeout. T o do so: 1. In Check Point SmartDashboard, select Policy > Global Properties > S tateful Inspectio n. 2. Increase the Other IP protocols virtual session timeout field to 120 seconds. Configuring Dense-Mode PIM 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the Interfaces section, click On fo r each interface on which to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited. 3. Click Apply , and then click Save to make your changes permanen t.
9 374 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. (Optional) T o configure this interface to use the VRRP virtual IP address, in the V irtual address field, click On. Note Y ou must use Monitored Circuit mode wh en configuring virtual IP support for dense- mode PIM. Do not use V RRPv 2 when conf ig uring virtual IP support for dense-mode PIM. 5. Click Apply . 6. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address text box. PIM uses this addre ss to send advertisements on the interface. Note Y ou cannot configure a local address or a virt ual address wh en IP clustering is enabled. Note If neighboring routers choose advertisement addresses that do not app ear to be on a shared subnet, all messag es fr om the neighbor are rejected. A PIM router on a shared LAN must ha ve at least o ne interface address with a subnet prefix that all neighboring PIM routers share. 7. (Optional) For each interface that is running PIM, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designat ed router . The default is 1, and the range is 0 to 4294 967295 (2^32 - 1). Note Although you can configu re this option, PIM- DM does not use DR Electio n Priority . On a LAN with more th an one router , data forwardi ng is implemented on the b asis of PIM Assert messages. The router with the lowest co st (based on unicast routing) to reach the source of dat a traf fic is e lected as the router that forwards traf fic. In the case of a tie, the router with the highest IP address is elected to forward traffic. 8. Click Apply , and then click Save to make your chan ge permanent. Disabling PIM Y ou can disable PIM on one or more interfaces you configured on each Nokia platform. 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the Interfaces section, click Of f for each interface on whic h to disable PIM. T o disable PIM entirely , click Off next to each in terface t hat is currently running PIM.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 375 3. Click Apply; then click Save to make your change permanent. Setting Advanced Options for Dense-Mode PIM (Optional) 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the Interfaces section, click On fo r each interface on which to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited. 3. Click Apply , and then click Save to make your changes permanen t. 4. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address text box. PIM uses this addre ss to send advertisements on the interface. Note Y ou cannot configure a local address or a vi rtual address when IP clustering is enabled. Note If neighboring routers choose advertisement addresses that do not appea r to be on a shared subnet, all messag es from the neighbor are rejected. A PIM router on a shared LAN must ha ve at least o ne interface address with a subnet prefix that all neighboring PIM routers share. 5. (Optional) For each interface that is running PI M, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designated router . The default is 1, and the range is 0 to 4294 967295 (2^32 - 1). 6. Click Apply , and then click Save to make your changes permanen t. 7. Click the Advanced PIM Options link. In the General T imers section, enter a value for the hello interval (in seconds) in the Hello Interval te xt box. The router uses this interval to send periodic Hello mess ages on the LAN. 8. In the General T imers section, enter a value fo r the data interval (in seconds) in the Data Interval text box. This value represents the interval after which th e multicast (S, G) state for a silent source is deleted. 9. In the General T imers section, enter a value fo r the assert interval (in seconds) in the Assert Interval text box. This value represents the interv al between the last time an assert is received and when the assert is timed out. 10. In the General Timers section, enter a value for the assert rate limit in the Assert Rate Limit text box.
9 376 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The value represents the number of times per se cond at which the designated router sends assert messages. The upper limit is 10,000 assert messages per sec ond. 11 . In the General T imers section, enter a value (in seconds) fo r the interval between sending join or prune messages in the Join/Prune Interval text box. 12. In the General Timers section, enter a value for the random dela y join or prune interval (in seconds) in the Ra ndom Delay Jo in/Prune Interval text box. This value represent s the maximum interval between the time when the Reverse Path Forwarding neighbor changes and when a join/prune message is sent. 13. In the General Timers section, enter a value for the join/pru ne suppression interval (in seconds) in the Join/Prune Suppression Interval text box. This value represents the mean interval between receiving a join/p rune message with a higher hold time and allowing duplicate join/prune messages to be sent again. Note The join/prun e suppression interval shou ld be set at 1.25 times the join/prune interval. 14. In the Asse rt Ranks section, in the appropri ate text box, enter a value for the routing protocol(s) you are using.Assert Rank values ar e used to compare protocols and determine which router forwards multicast packets on a multiaccess LAN. Assert messages include these values when more th an one router can forwar ding the multicast packets. Note Assert rank values must be the same fo r all routers on a multiaccess LAN that are running the same protocol. 15. Click Apply . 16. T o make your change s pe rmanent, click Save. Configuring Sp arse-Mode PIM 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the PIM Instance Mode fi eld, click On for sparse. 3. Click Apply . 4. In the Interfaces section, click On fo r each interface on which to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited. 5. Click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 377 6. (Optional) T o configure this interface to use the VRRP virtual IP address, in the V irtual address field, click On. Note Y ou must use Monitored Circuit mode when co n figuring virtual IP support for spar se- mode PIM. Do not use VRRPv2 when configuring virtua l IP supp ort for sparse-mode PIM. 7. Click Apply . 8. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address text box. PIM uses this address to send advertisements on the interface. This option is useful only when multiple ad dresses are configured on the interface. Note If neighboring routers choose advertisement addresses that do not appea r to be on a shared subnet, then all message s from the neighbor are rejected. A PIM route r on a shared LAN must have at least one interf ace ad dr ess with a subnet prefix that all neighboring PIM rou ters sh ar e. 9. (Optional) For each interface that is running PI M, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designate d router . T o break a tie, the designated router with the highest IP address is chosen. If even one rout er does not advertise a DR elec tion priority value in its hello messages, DR election is based on the IP addresses. The default is 1, and the range is 0 to 4294967295 (2^32 - 1). Note T o verify whether a PIM neighbor supports DR Election Priority , use the following command, which you can executed from iclid and CLI: show pim neighbor <ip_address> For neighbor s that advertise a DR election priority value, the following message appears in the summary: DRPriorityCapable Yes . 10. Click Apply . 11 . T o make your changes permanent, click Save. Configuring High-A vailability Mode Enable the high-availability (HA) mode when two routers are config ured to back each other up to forward multicast traffi c and sp arse-mode PIM is implemented. When this option is enabled, all PIM-enabled interfaces are available only if each interface is up and ha s a va lid address assigned. If any PIM-enabled interface goes down or if all of its valid addresses are deleted, then
9 378 Nokia Network Voyager for IPSO 4.0 Refe rence Guide all PIM-enabled interfaces become unavailable an d remain in that state until all interfaces are back up. Beginning with IPSO 3.8, yo u can configure either a PIM-SM or a PIM-DM interface to advertise the VRRP virtual IP ad dress if the router transitions to become VRRP master after a failover . If you enable this option, you do not need to enable HA mode . For more information about the VRRP virtual IP address option, see “VRRP .” Note The HA mode applies only to sp arse-mode PIM. The HA mode feature does not af fect the functioning of dense-mode PIM . Y ou cannot e nable HA mode if you enable IP clustering. 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the PIM Instance Mode fi eld, click On for sparse. 3. Click Apply . 4. In the HA Mode field, click On to enable the high -availability mode. 5. Click Apply . 6. In the Interfaces section, click On for each interface to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited 7. Click Apply . 8. (Optional) For each interface that is running PIM, enter the specified local address in the Local Address edit box. PIM uses this address to send advertis ements on the interface. This option is useful only when multiple ad dresses are configured on the interface. Note If neighboring routers choose advertisement addresses that do not app ear to be on a shared subnet, then all message s from the neighbor are rejected. A PIM rou ter on a shared LAN must have at least one interf ace addr ess with a subnet prefix that all neighboring PIM rou ters sh ar e. 9. (Optional) For each interface that is running PI M, enter a new designated router priority in the DR Election Priority text box. The router with the highest priority and the highest IP address is elected as the designate d router . T o break a tie, the designated router with the highest IP address is chosen. If even one rout er does not advertise a DR elec tion priority value in its hello message s, DR election is based on the IP addresses. The default is 1, and the range is 0 to 4294967295 (2^32 - 1).
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 379 Note T o verify whether a PIM neighbor supports DR Election Priority , use the following command, which you can executed from iclid and CLI: show pim neighbor <ip_address> For neighbor s that advertise a DR election priority value, the following message appears in the summary: DRPriorityCapable Yes. 10. Click Apply . 11 . T o make your changes permanent, click Save. Configuring this Router as a Candidate Boot strap and Candidate Rendezvous Point 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the PIM Instance Mode fiel d, click On button for sparse. 3. Click Apply . 4. In the Interfaces section, click On fo r each interface on which to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited. 5. Click Apply . 6. In the Sparse Mode Rendezvous Point (RP) Config uration section, to enable this router as a candidate bootstrap router: a. Click On in the Bootstrap Router field. b. (Optional) Enter the address of th e bootstrap router in the Local Address text box. Configure an address for the candidate bootstra p router to help speci fy the local address used as the identifier in the bootstrap messages. By default, the router chooses an a ddress from one of the interfaces on which PIM is enabled. c. (Optional) Enter the bootstrap router prior ity (0 to 255) in the Priority text box. Use the priority option to help specify the pr iority to advertise in bootstrap messages. The default priority value is 0. Note The domain automatically ele cts a bootstra p router , based on the asse rt rank preference values configured. The ca ndidate bootstrap ro uter with the highest preference value is elected the boot strap router . T o break a tie, the boot strap candidate router with the highest IP address is elected the boot strap router .
9 380 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 7. In the Sparse Mode Rendezvou s Point (RP) Configuration section, to enable this router as a Candidate Rendezvous Point: a. Click On in the Candidate RP Router field. b. (Optional) Enter the local address of the Cand idate Rendezvous Point router in the Local Address field. This router sends Candidate Re ndezvous Point messages. Configure an address for the Candidate Rendez vous Point to select the local address used in candidate-RP-advertisements sent to the elect ed bootstrap router . By default, the router chooses an address from one of the interfaces on which PIM is enabled. c. (Optional) Enter the Candidate Re ndezvous Point priority (0 to 255) in the Priority text box. Use the priority option to set the priority fo r this rendezvous point. The lower this value, the higher the priority . The default priority value is 0. 8. (Optional) T o configure a multicast address fo r which this router is designated as the rendezvous point, in the Local RPSET fiel d, enter an IP address in the Multicast address group text box and the address mask le ngth in t he Mask length text box. Note If you do not configure a multicast address for the router , it advertises as able to function as the rendezvous point for all multicast group s (224/4) 9. Click Apply . 10. T o make your change s pe rmanent, click Save. Configuring a PIM-SM S t atic Rendezvous Point 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the PIM Instance Mode fi eld, click On for sparse. 3. Click Apply . 4. In the Interfaces section, click On fo r each interface on which to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited. 5. Click Apply . 6. In the Sparse Mode Rendezvous Point (RP) Configuration section, to enable a Static Rendezvous Point router , click On in the S tatic RP Router field.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 381 Note S tatic Rendezvous Point configuration over ride s rendezvous point (RP) information received from other RP-dissemination mechanisms, such as boot strap routers. 7. Enter the IP address of the router to config ure as the static rendezvous point in the RP Address text box. Click Ap ply . 8. (Optional) Enter the multicast group address and prefix length in the Multicast group address and Mask length tex t boxes. Click Apply . Note If you do not configure a multicast group ad dress and prefix length for this S t atic Rendezvous Point , it functions by default as the rendezvous point for all multicast group s (224.0.0.0/4 ). 9. Click Save to make your changes permanent. Setting Advanced Options for Sp arse-Mode PIM (Optional) 1. Click PIM under Configuration > Routin g Configuration in the tree view . 2. In the PIM Instance Mode fi eld, click On for sparse. 3. Click Apply . 4. In the Interfaces section, click On each interface on which to run PIM. Note The number of interfaces on wh ich you can run PIM is unlimited. 5. Click Apply . 6. Click the Advanced PIM Options link. In the Sparse Mode T imers sec tion, enter a value for the regi ster suppression interval (in seconds) in the Register-Suppr ession Interval text box. This value represents the mean interval between receiving a Register-S top message and allowing Register messages to be sent again. 7. In the Sparse Mode T imers sec tion, enter a value for the boot strap interval for candidate bootstrap routers (in secon ds) in the Bootstrap Interval text box. This value represents the interval between whic h bootstrap advertisement messages are sent. 8. In the Sparse Mode T imers section, enter a value for the candidat e ren dezvous point advertisement interval (in seco nds) in the Candidate RP-Advertisement Interval text box. This value represents the interval between which Candidate Rendezvous Point routers send Candidate-RP-Advertisement messages.
9 382 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 9. In the Sparse Mode T imers sec tion, enter a value for the shortest path tree threshold (in kilobits per second) in the Threshold (kpbs) text box. Enter an IP address for the multicast group to which the SP T threshold applies in the Multicast Group ID text box. En ter the mask length for the group multicast address in the Mask Length edit box. When the data rate fo r a sparse-mode group exceeds the shortest- path-tree threshold at the last-h op router , an (S,G) entry is cr eated and a join/prune message is sent toward the source. Setting this option bu ilds a shortest-path tree from the source S to the last-hop router . 10. Click Apply , and then click Save to make your changes permanent. 11 . (Optional) In the General Timers section, enter a value for the hello interval (in seconds) in the Hello Interval edit box. The router uses this interval to se nd periodic Hello message s on the LAN. 12. (Optional) In the General T imers section, enter a value for the da ta interval (in seconds) in the Data Interval text box. This value represents the interval after which th e multicast (S, G) state for a silent source is deleted. 13. (Optional) In the General Timers section, enter a value for the as sert interval (in seconds) in the Assert Interval text box. This value represents the interval between the last time an assert is received and when the assert is timed out. 14. (Optional) In the Gene ral Timers section, enter a value for the assert rate limit in the Assert Rate Limit text box. The value represents the number of times per se cond at which the designated router sends assert messages. The upper limit is 10,000 assert messages per sec ond. 15. (Optional) In the General T imers section, ente r a value (in seconds) for the interval between sending join/prune messages in the Join/Prune Interval text box. 16. (Optional) In the General T imers section, en ter a value for the random delay join/prune interval (in seconds) in the Random Delay Join/Prune Interval text box. This value represents the ma ximum interval between the time when the reverse path forwarding neighbor changes and when a join/prune message is sent. 17. (Optional) In the Gene ral Timers section, en ter a value for the join/prune suppression interval (in seconds) in the Join/Pr une Supp ression Interval text box. This value represents the mean interval between receiving a join/p rune message with a higher Holdtime and allowing duplicate join/prune messages to be sent again. Note The join/prun e suppression interval shou ld be set at 1.25 times the join/prune interval. 18. (Optional) In the Assert Ranks section, enter a value for the routing protocol(s) you are using in the appropriate text box. Assert Ra nk values are used to compare protocols and determine which router forwards multicast p ackets on a multiaccess L AN. Assert messages include these values when more tha n one router can forwarding the multicast packets.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 383 Note Assert rank values must be the same fo r all routers on a multiaccess LAN that are running the same protocol. 19. Click Apply . 20. (Optional) The checksum of the PIM register messages is calculated without including the multicast payload. Earlier releases of the Cisco IOS calculate the check sum by including the multicast payload. If you experience dif ficultie s having PIM register messages sent by the Nokia appliance being accepted by a Cisco router that is the elected rendezvous point (RP), configure this option. A Nokia appliance that is the elected RP accepts regis ter messages that calculate the checksum with or without the multicast payload, that is, it accepts all register messages. a. T o enable Cisco compatibility for regist er checksums, click On in the Cisco Compatibility Register Checksums field. b. Click Apply , and then click Save to make your change permanent. 21. T o make your change s pe rmanent, click Save. Debugging PIM The following iclid co mmands can assi st you in debugging PIM: The following iclid co mmands can assist you in debugging sparse-mode PIM (PIM-SM): Command Shows show pim interface Which interfaces are running PI M, their status, and the mode they are running. This command also displays the interface and its DR priority and the number of PIM neighbors on the interface. show pim neighbors The IP address of each PIM neighbor and the interface on which the neigh bor is present. This command also displays the nei ghbor ’s DR priority , generation ID, holdtime and the time the neig hbor is set to expire based on the holdtime received in the most recent hello message. show pim statistics The nu mb er of different types of PIM packet s received and transmitted and any associated errors. show mfc cache Multicast source and group forwarding state by prefix. show mfc interfaces Shows multicast source and group forward ing state by interface. Command Shows show pim bootstrap The IP address an d state of the Bootstrap router . show pim candidate-rp The state of the Candidate Rendezvous Point state machine.
9 384 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o log information about errors and events . 1. Click Routing Options under Config uration > Ro uting Configuration in the tree view . 2. In the T race Options section, click on the Ad d Option drop-down window in the PIM field. Select each option for which you wa nt to log information. Y ou must sele ct each option one at a time and click Apply after you select each option. Fo r each option you select, its name and on and off radio buttons appear just above the drop-d own window . T o disable any of the options you have selected, click the of f radio button, and then click Apply . 3. Click Save to make your changes pe rmanent. The following trace options ap ply both to dense-mode and sparse-mode implementations:  Assert —T races PIM assert mes sages.  Hello —Traces PIM router hello messages.  Join —T races PIM join/prune messages  MFC —T races calls to or from the multicast forwarding ca che  MR T —T races PIM multicast routing table events.  Packets —T races all PIM packets.  Tr a p —Trace PIM trap messages.  All —T races all PIM e vents and packe ts. The following trace options apply to sparse-mode implementations only:  Bootstrap —T races bootstrap messages.  CRP —T races candidate-RP-advertisements.  RP —T races RP-specific events, including both RP set-specific and bootstrap-specific events.  Register —T races register and register-stop packets. The following trace option applies to dense-mode implementati ons only: show pim joins PIM’s view of the join-prune (*, G and S, G) state, including RP for the group, incoming, and outgoing interface(s), in teraction with the multicast forwarding cache and the presence of local members. T o view the equ ivale nt information for dense-mode PIM, use the show mfc cache command. show pim rps Th e active RP-set, including the RP addresses, their type (or so urce of information about them) and the groups for which they are configured to act as RP . show pim group-rp- mapping < group- address > The RP selected for a particular group based on informa tio n from the active RP-set. show pim sparse-mode statistics Error statistics for m ulticast forw arding cache (MFC); Bootstrap Router (BSR) messages; Candid ate Rendezvous Point (CRP) advertisements; and the Internet Group Man agement Protocol (IGMP). Command Shows
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 385  Graft —T races graft and graft acknowledgment packets IGRP The Inter-Gateway Routing Pr otocol ( IGRP ) is a widely used interior gateway proto col (IGP). Like RIP , IGRP is an implementation of a distan ce-vector , or Bellman-Ford, routing protocol fo r local networks. As spec ified, IGRP modifies the basic Bellm an-Ford algorithm in three ways:  Uses a vector of metrics.  Allows for multiple paths to a single des tination, thus allowing for load sharing.  Provides stability during topolo gy changes because new features. This document pro vides background informat ion and cites differences with other IGRP implementations. A router running IGRP broadcasts routing updates at periodic intervals, in addition to updates that are sent immediately in response to some type of topology change. An update message includes the follo wing information:  Configured autonomous system number  Current edition number of the routing table  Checksum of the update mes sage  Count of the number of routes included  List of route entries An IGRP update packet contains three types of routine entries.  Interior  System  Exterior Each entry includes three bytes of an IP address. The fourth byte is determined by the type of the route entry . Interior r outes are passed between links that are subnetted from the same class IP address. System r outes are classful IP routes exchanged within an autonomous system. Exterior ro u t e s are like system routes, but also are used for installing a default r oute . In addition, the following metrics are in cluded for each entry:  Delay  Bandwidth  Math MTU  Reliability  Load  Hop count IGRP calculates a single composite metric from th is vector to compare routes. Since the metrics attempt to physically characteri ze the path to a destination, IG RP attempts to provide optimal routing. IGRP has two packet types.
9 386 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Request pack et  Update packet IGRP dynamically builds its routing table from in formation received in IGRP update messages. On startup, IGRP issues a request on all IGRP-e nabled interfaces. If a sy stem is configured to supply IGRP , it hears the request a nd responds w ith an update message based on the current routing database. IGRP processes update messages differently depending on whether or not holddowns are enabled. If all the following conditions are true, the route is deleted and put into a holddown:  Holddowns are enabled.  Route entry comes from the originator of the route.  Calculated composite metric is worse than co mposite metric of the existing route by more than 10 percent. During this holddown period, no other updates for that route are accepted from any source. If all the following are true, the route is delete d (note that it does not enter a holddown period):  Holddowns are disabled.  Route entry comes from the originator of the route.  Hop count has increased.  Calculated composite metric is greater than the composite metric of the existing route. In both cases, if a route is no t in holddown and a route entry in an update message indicates it has a better metric, the new rout e is adopted. In general, rou ting updates are issued every 90 seconds. If a router is not heard from for 270 sec onds, all routes from that router are deleted from the routing database. If holddowns are enabled and a route is deleted, the route remains in the holddown for 280 secon ds. If a router is not he ard from for 630 seconds, all routes from that router are no longer announced (that is, after th e initial 270 seconds, such routes are advertised as unr eachable ). This implementation of IGRP does not support all of the features listed in the specification. The following is a list of non-supported features:  Multiple type of service (TOS) routi ng  V ariance factor set only to a va lue of one  Equal or roughly equal cost path splitting This implementation has interope rated with other vendor ’ s implementations of IGRP , namely Cisco IOS version 10.3(6) and 1 1.0(7). Listed he re for completeness are a few minor observable differences between the Nokia and the Cisco im plementations (no inte roperability problems have occurred to date be cause to these differences):  V alidity Checks— packets that are malformed (that is, t hose that have trailing data on a request packet, have non zero data in a field that must be zero, or have rou te counts in an update packet that do not agree with the actual packet size) are rejected. Other implementations allow such packets. Y ou ca n dis able some of these checks for request packets, but not for the update packets.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 387  V alid Neighbors— packets that have a source address from a non-local network are ignored. Y ou cannot disable this behavior .  Duplicate Entries in an Update— if an update mes sage contains duplicate new paths, holddowns are enabled, and if each of the duplicate composite metrics differ by more than 10 percent, the route is not put in holddown. The path wi th the best metr ic is installed. Other implementations treat each duplicate path as if it arrived in separate update messages. In this case, place the route into holddown.  T r iggered Update on Route Expiration— when a route expires, a triggered update message is generated at the moment of expira tion, marking the route as unreachable. Other implementations wait until the next schedul ed update message to mark the route as unreachable. In this latter case, the route is actually not mark ed as unreachable until the next scheduled update cycle (although th is seems somewhat contradictory).  Specific Split Horizon— does not implement specific split horizon. Split horizon processing means that routes learned from an interface are not advertised back out that same interface. Specific split horizon occurs when a request is made. In this case, only routes that use the requestor as the next hop are omitted from the response.  Poison Reverse— uses simple split horizon; that is, pois on reverse is not performed. Other implementations use a form of poison reverse in which at least a single update a dvertises an expired route as being unreachable on the interface from which the route was learned.  Forwarding to Unre achable Routes— when a route expires or is ma rked as unrea chable from the originator , the route is removed from the forwarding table. In the absence of a default or more general route, packets des tined for this address are dropped. Other implementations continue to fo rward packets to routes marked as unreachable until a route is flushed from the table. Generation of Exterior Routes IGRP has three defined types of routes that an update packet can carry:  Interior  System  Exterior Note For a det aile d explanation of the diffe ren t route types, see the IGRP specification An exterior route is conceptually the same as a system route, with the a dded feature that an exterior route can be used as a default route. Exterior routes are always propagated as exterior . When it is necessary to locally generate an exteri or default route, redistribute the default route into IGRP . The next -hop network of the default ro ute, determined from the next-hop interface, is advertised in the appropriate IGRP update me s sages as e xterior . A direct interface route is advertised only once. Therefore, a direct interf ace route that is marked exterior is not also advertised as interior or as system.
9 388 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Aliased Interfaces When an interface has multiple addresses config ured, e ach address is treated as a distinct interface since it represents a logical subnet. Such a configuration implies that an update is sent for each IGRP-configured address . In the configuration syntax, you can specify a particular address of an interface on which to run IGRP as opposed to the complete interface (all addresses of the interface). IGRP Aggregation Most routing aggregation occurs only if explicitly configured; th erefore, it is worth noting some of the implicit aggregation that occurs in IGRP . By definition, no mask in formation is included in the IGRP route entry . System and exte rior routes have an impl ied mask of the natural classful mask. Interior routes are propagated from one inte rface to another only if the two interfaces are subnetted from the same IP class address and have the sa me subnet mask. Otherwise, an interior route is converted (an aggregation occurs) to a system route. Any supernetted routes redistributed into IGRP are ignored. In sum, any ro ute redistributed into IG RP that is marked as a system or exterior route has the natural class ma sk applied to the route to determine what route should be advertis ed in an u pdate. Configuring IGRP Note IGRP configuration of an interface is available only if you are licen sed for IGRP on your IP router . (See the Licenses link on the Configu ration page.) 1. Complete “Ethernet Interfaces” for the interface. 2. Click IGRP under Configuration > Routing Configuration in the tree view . 3. Enter the AS number in the Auto nomous System Number text box. 4. Click on for each interface to co nfigure; then click Apply . 5. (Optional) Enter a new delay metric in the De lay text box for each interface (for example, 100 for 10 Mbps Ethern et); then click Apply . The delay is measured in units of 10 microseconds. 6. (Optional) Enter a new bandwidth metric in the Bandwidth text box for each interface (for example, 1000 for 10Mbps Ethe rne t); then click Apply . The bandwidth is entered in bits per second scaled by a factor of 1 0,000,000 (10,000,000/ x Kbps), where x is the actual bandwidth of the interface. 7. (Optional) In the Pr otocol section, enter a new bandwidth multiplier in t he K1 (bandwidth multiplier) text box; then click Apply . K1 is used to globally influence bandwidth over delay .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 389 8. (Optional) In the Protocol section, enter a new delay multiplier in th e K2 (delay multiplier) text box; then click Apply . K2 is used to globally influence delay over bandwidth. 9. (Optional) In the Proto col section, click No in the Holddown field; then click Apply . This action disables the global route holddown p arameter . 10. (Optional) In the Protocol section, enter the new maximum hop count metric in the Maximum hop coun t text box; then click Apply . This option is used to prevent infinite looping. 11 . (Optional) In the Protocol sect ion, enter the new update interval metric in the Update interval text box; then click Apply . This number determines how often route u pdates are sent out on all of the interfaces. 12. (Optional) In the Protocol section, enter the new invalid interval metric in the Invalid interval text box; then click Apply . 13. (Optional) In the Protocol section, enter the ne w hold interval metric in the Hold interval text box; then click Apply . 14. (Optional) In the Protocol section, enter the ne w flush interval metric in the Flush interval text box; then click Apply . 15. (Optional) In the Protocol section, click Y es in the No Check Zero field; then click Apply . Leave this field set to No to in teroperate with Cisco equipment. 16. T o make your change s pe rmanent, click Save. IGRP Example Note Y ou must have an IGRP license and the option se lected on the Licenses page to use this feature. T o enable IGRP on an interface: 1. Configure the interfaces as in “Ethernet Interfaces.” 2. Click IGRP under Configuration > Routing Configuration in the tree view . 3. Enter the AS number in the Auto nomous System Num ber text box. 4. (Required) Enter a delay metric in the Delay text box for e ach interface; then click Apply . 5. (Required) Enter a bandwidth metric in the Band width text box for each interface; then click Apply . 6. (Required) Enter a reliability metr ic in the Reliability text box for each interface; then click Apply . 7. (Required) Enter the load metric in the load text box for each interf ace; then click Apply .
9 390 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The load metric is a fraction of 255. 8. (Required) Enter the MTU metric in the metric text box for each inte rfa ce; then click Apply . A lar ger MTU reduces the IG RP cost. 9. Click on for eth-s1p1 c0; then click Apply . DVMRP The Distance V ector Multicast Routing Protocol (DVMRP) is a distance vector protocol that calculates a source-rooted multic ast distribution tree and provid es routing of IP multicast datagrams over an IP internetwork. DVMRP uses the Bellman-Ford routing protocol to maintain topological knowledge. DVMRP uses this inform ation to implement Reverse Pat h Forwarding (RPF) a multicast forwarding algorithm. RPF forwards a multicast datagram to members of the destinatio n g roup along a shortest (reverse) path tree that is rooted at the subn et on which the datagram originates. T runcated Reverse Path Broadcasting (TRPB) uses the IGMP -collected group membership state to avoid forwarding on leaf network s that do not contain group members. TRPB calculates a distribution tree across al l multicast routers and only saves packet transmissions on the leaf networks that do not contain group members. Reverse Path Multicast (RPM) allows the leaf routers to prune th e distribution tree to the minimum multicast distribution tree. RPM minimizes packet transm issions by no t forwa rding datagrams along branches that do not lead to any group members. Multicast capabilities are not always present in current Internet-based networks. Multicast packets must sometimes pass through a router that does not support IP multicasting to reach their destination. This behavior is allowed because DVMRP defines a virtual tunnel interface between two multicast-capable routers that might be co nnected by multiple no n-multicast capable IP hops. DVMRP encapsulates IP multicast packets for transmission throug h tunnels so that they look like normal unicast datagrams to interven ing routers and su bnets. DVMRP adds the encapsulation when a packet enters a tunnel and removes it when the packet exits from a tunnel. The packets are encapsu lated with the IP-in-IP protocol (IP protocol n umber 4). This tunneling mechanism allows you to establish a virtual internet that is independent from the physical internet. The IPSO implementation of DVMRP supports the following featu res.  DVMRP v .3  Prune and graft messages  Generation ID  Capability flags  Interface metric and threshold configuration  Interface administrative scoping on the 239.X.X.X addresses  Interfaces with secondary addre sses  iclid wizards
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 391  Monitoring template  T racks the number of subordinate routers per route. Using Network V oya ger , you can configure the fo llo wing options:  DVMRP interfaces  New minimum time to live (TTL) threshold for each interface  New cost metric for sending mul ticast packe ts for each interface Configuring DVMRP 1. Complete “Ethernet Interfaces” for the interface. 2. Click DVMRP under Configuration > Routi ng Configuration in the tree view . 3. For each interface you want to configure for DVMRP , Click on for the interface; then click Apply . 4. (Optional) Enter a new minimum IP time to liv e ( TTL) threshold in the Threshold text box for each interface; then click Apply . 5. (Optional) Enter a new cost metric for sending multicast packets in the Metric text box for each interface; th en c lick Apply . 6. T o make your changes permanent, click Save. Configuring DVMRP T imers Y ou can configure values for DVMRP timers. Nokia recommends that if you have a core multicast network, you configure the timer values so that they are uniform throughout a network. Otherwise, you can rely on th e default timer values. Y ou can configure two neighbor-sp ecific timers, three routing specific-tim ers and a cache-specific timer . 1. Click DVMRP under Configuration > Routi ng Configuration in the tree view . 2. Click the Advanced DVMRP options link. This action takes you to Adva nced Options for DVMRP page. 3. (Optional) Enter a value between 5 and 30 in th e Neighbor probe i nterval text box to set the interval, in seconds, at which DVMRP ne ighbor probe messages are sent from each interface. The default is 10 seconds 4. (Optional) Enter a value between 35 and 8000 in the Neighb or time-out interval text box to set the interval, in seconds, after whic h a silent neighbor is timed out. The default for DVMRPv3 neigh bors is 35, and for non-DVMRPv3 neighb ors the default is 140. 5. (Optional) Enter a value between 10 and 2000 in the Route report interval text box to set the interval, in seconds, at wh ich routing updates are sent on each DVMRP interface. The default is 60 seconds.
9 392 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 6. (Optional) Enter a value betwee n 20 and 4000 in t he Route expiration time text box to set the interval, in seconds, after wh ich a route that has not been re freshed is placed in the route hold-down queue. The default is 140 seconds. 7. (Optional) Enter a value between 0 and 8000 in the Route hold-down p eriod text box to set the interval, in seconds, for whic h an expired route is kept in the hold -down queue before it is deleted from the route database. Set this interval to twice the value of the route report interval. The default is 120 seconds. 8. (Optional) Enter a value betwee n 60 and 86400 in the Cache lifetime t ext box to set the interval, in seconds that a ca ched multicast forwarding entry is maintained in t he kernel forwarding table before it is tim ed out because of inactivity . The default is 300 seconds. 9. Click Apply , and then click Save to make your changes permanen t. IGMP Internet Group Management Protocol (IGMP) allo ws hosts on multiaccess networks to inform locally attached routers of their group membership information. Hosts share their group membership information by mu lticasting I GMP host membership reports. Multicast routers listen for these host membership reports, and then exchange this information with other multicast routers. The group membership reporting protocol includes two types of messages: host membership query and host membership report. IGMP message s ar e encapsulated in IP datagra ms, with an IP protocol number of 2. Pro tocol operation requires tha t a designated querier rout er be elected on each subnet and that it periodic ally multicast a host membership query to the all-hosts group. Hosts respond to a query by generating host membership reports for each multicast group to which they belong. These reports are sent to the group being reported, which allows other activ e members on the subnet to cancel their reports. This behavior limits the number of reports generated to one for each active group on the su bnet. This exchange allows the multicast routers to maintain a database of all activ e ho st groups on each of their attached subnets. A group is declared inactive (expired) when no report is received for several query intervals. The IGMPv2 protocol adds a leave group message and uses an unused field in the IGMPv .1 host membership query message to specify a maximum response time. The leave group message allows a host to report when its membership in a multicast group terminates. Then, the IGMP querier router can send a gro up - dire cted query with a very small maximum response time to probe for any remaining active group members. Th is accelerated leave ex tension can reduce the time required to expire a group and prune the mu lticast distribution tree fro m minutes, down to several seconds The unicast traceroute program allo ws the tracing of a path from one device to another, using mechanisms that already exist in IP . Unfortunately , you cannot apply such mechanisms to IP multicast packets. The key mechanism for uni cast traceroute is the ICMP TTL exceeded message that is specifically pr ecluded as a response to multicas t packets. The traceroute facility
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 393 implemented within IP SRD conforms to the traceroute facility for IP multicast draft specification. The IPSO implementation of IGMP supports the following features.  Complete IGMPv2 functionality  Multicast traceroute  Complete configurability of protocol timers  Administratively-bl ocked grou ps  Support for interfaces with secondary addre sses  iclid wizards  Monitoring template Using Network V oya ger , you can configure the fo llo wing options:  Ve r s i o n n u m b e r  Loss robustness  Query interval  Query response interval  Last-member query interval Additionally , you can enable and disable router alert. Nokia supports IG MP in an IP cluster as part of the new support fo r PIM, both de nse-mode and sparse-mode, in an IP cluster . The support for IG MP in an IP cluster ensures synchronization of IGMP state from master to members when a new node running PIM joins the cluster . For more information about PIM and IP Clustering, see “PIM” on page 370 and “IP Clustering Description” on page 207. Configuring IGMP 1. Complete “Ethernet Interfaces” for the interface. 2. Configure a multicast routing protocol, such as PIM or DVMRP . The IGMP feature sup ports IP multicast groups on a network and functions only in conjunction wi th a multicast routing protocol to calculate a multicast distribution tree. For more information on mu lticast routing protocols supported by IPSO, see “P IM” on page 370 or “DVMRP” on page 390 3. Click IGMP under Configuration > Rou ting Configuration in the tree view . 4. Complete the following steps for each interfa ce on which you enabled a multicast routing protocol. 5. Click the appropriate V ersion button to enable either version 1 or 2; then click Apply . The default is version 2
9 394 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note A router configured for IGMP ver s ion 2 can in te rope rate with host s running either IGMP version 1 or version 2. Nokia recommends that you use version 1 only on networks that include multicast routers that ar e not upgraded to IGMP version 2. 6. (Optional) Enter the loss robustness value in th e Los s robustness text bo x; then click Apply . The range is 1 to 25 5, and the default is 2. 7. (Optional) Enter the query interval in t he Quer y interval text box; then click Apply . This value specifies the interval, in seconds, that the querier rout er sends IGMP general queries. The default is 125, and the range is 1 to 3600. 8. (Optional) Enter the query respon se interval in the Query respon se interval text box; then click Apply . This value specifies the maximum response ti me, in seconds, inserte d into the periodic IGMP general queries. The higher th e value th e longer the interval between host IGMP reports, which reduces burstiness. This value must be lower than that of the query interval. The default is 10, and the range is 1 to 25. 9. (Optional) Enter the last member query interval in the Last member query interval text box,; then click Apply . This value specifies the maximum response ti me, in seconds, inserted into IGMP group- specific queries. A lower value results in less tim e to detect the loss of the last member of a multicast group. This value must be lo wer than that of the query interval. The default is 1, and the range is 1 to 25. 10. (Optional) Click On in the Disable router alert field to actively disable the insertion of the IP router alert typically included in IGMP messages. Disabling this option is useful when interope rating with broken IP implementations that might otherwise discard packets from the specif ied interface. The default is Off, meaning that the IGMP messages include the IP router alert. Click Apply . 11 . T o make your changes permanent, click Save. S t atic Routes Static routes are routes that you manually conf igure in the routing tabl e. Static routes do no t change and are not dynamic (hence the name). Static routes cause pa ckets addresses to the destination to take a spec ified next hop. S tatic routes allow yo u to add routes to destinations that are not known by dynami c routing protocols. S ta tics can also be used in providing a default route. Stat ic routes consist of the following parameters:  Destination  Ty p e  Next-hop gateway Stat ic routes can be one of the following types:
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 395  Normal —A normal static route is one used to fo rward packets for a given destination in the direction indicated by the configured router .  Black hole —A black hole static route is a route that uses the loopback address as the next hop. This rout e discards packets that match the route for a gi ven destination.  Reject —A reject static route is a route that uses the loopback address as the next hop. This route discards packets that match the route for a given destination and sends an ICMP unreachable message back to the sender of the packet. T o configure a default or static route 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 2. T o enable a default route, a. Click On in the Default field b. Click Apply . 3. T o configure a new static route: a. Enter the network prefix in th e New St atic Route text box. b. Enter the mask length (number of b its) in the Mask Length text box. 4. Select the type of next hop the static route will take from the Next Hop T ype drop-down list. 5. Select the gateway type of the next hop router from the Gatewa y T ype drop-down lis t. Gateway Address specifies the IP address of th e gate way to which fo rwarding packets for each static route are sent. This must be the address of a route r that is direc t ly connecte d to the system you are configuring. Note Gateway Logical Name is valid only if th e next-hop gateway is an un numbered inte rface and you do not know the IP addr ess of the gateway . 6. Click Apply . 7. Enter the IP address of the defau lt router in the Gateway text box 8. Click Apply . 9. T o make your changes permanent, click Save. T o setting the rank for static rou tes 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 2. Click Advanced Options. 3. T o set the rank for each static route you have configured, enter a value in the Rank text box. The system uses the rank value to determine which route to use when routes are present from different protocols to the same destination. For each route, the system uses the route from the protocol with the lowest rank number . The default for static routes is 60. The range you can enter is 0 to 255.
9 396 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. Click Apply , and then click Save to make your changes permanen t. T o add and configure many static routes at the same time 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 2. In the Quick-add static routes field, click the Quick-add next hop type drop- down list, and select Normal, Reject, or Black hole. The default is Normal. For more info rmation on static route types, see “Static Routes” on page 394 . 3. In the Quick-add static routes edit box, enter an IP address, its mask length, and add one or more next-hop IP addresses for each static route you want to add. Us e the following format: IP address/mask length next hop IP address The IP addresses must be specified in a dotted- quad format ([0 to 25 5]).[0 to 255].[0 to 255].[0 to 2 55]) The range for the mask length is 1 to 32. For example, to add a static route to 205.226. 10.0 with a mask length of 24 and next hops of 10.1.1.1 and 10.1.1.2, enter: 205.226.10.0 /24 10 .1.1.1 10.1.1.2 4. Press Enter after each entry you make for a static route. Note Y ou cannot configure a logical interface through the quick-add static routes op tio n. 5. Click Apply . The newly configured additional static routes ap pear in the Static Route field at the top of the Static Routes page. Note The text box displays any entrie s tha t contain errors. Error messag es appear at the top of the page. 6. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 397 Adding and Managing S t atic Routes Example The figure below shows the networ k configuration for the example. In this example, Nokia Platform A is connected to the Internet, with no routing occurring on the interface connected to the Internet (no OSPF or BGP). A corporate W AN is between Nokia platform B and Nokia p latform C, and no routing occu rs on this link. Use static rout es so that the remote PC LAN can have Internet access. Static routes apply in many areas, such as conn ections to the Internet, across corporate W ANs, and creating routing bou ndaries between two routing do ma ins. Creating/Removing S tatic Routes For the precedi ng example, one static defau lt route to the Internet is created t hrough 192.168.22.1/22, and a static route is created across the corporate W A N to the remote PC LAN across 192.168.26.68/30 . T o create a static default route 1. Use Network V oyager to connect to Nokia Platform A. 2. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 3. Click on in the Default field; then click Apply . 4. In the gateway text box enter: 192.168.22.1; then click App ly . Y ou should now hav e one static default route in your routing tables o n Nokia Platform A. For the rest of the network to know about th is route, you must redistribute the static route to OSPF . After you complete this task, any gateway connected t o Nokia Platform B has the default route with 192.168.22.1 as the next ho p in the routing tables. Any packet not de stined for the 192.168.22.0/ 22 net is directed towards 192. 168.22.1. T o create a static route (non-default) 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 2. In the New Static Route text box enter: 192.168.24.0 . 00345 Nokia Platform B Nokia Platform A Nokia Platform D 26.66/30 26.73/30 26.70/30 26.69/30 22.1/22 Network Prefix: 192.168.0.0 Nokia Platform C 24.45/30 26.74/30 24.0/24 26.2/24 Corporate W AN Internet Static Routes Default Static Routes OSPF OSPF Remote PCs
9 398 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 3. In the Mask Length text box enter 24. 4. In the Gateway text box enter 192.168 .26.70. 5. Click Apply . If you have configured OSPF o r RIP on your remote office network, you now have connectivity to the Internet. T o disable a static route 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 2. Click of f for the route you want to disabl e 3. Click Apply . Backup S t atic Routes S tatic ro utes can beco me u navaila ble if the interface related to th e currently configured gateway is down. In this scenario , you can use a back up static route instead . T o implement backup static routes, you need to prioritize them. The priority values range from 1 to 8, with 1 having the highest priority . If more than one gateway belongs to the same priority , a multipath static route is installed. If a directly attached interface is down, all t he gateways that belong to the interface are deleted from the list of next-hop selections. Backup static routes are useful for default rout es, but you cannot use them for any static route. T o create a backup static route 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . Note This example assu mes that a st atic route has alre ady been configured and the t ask is to add backup gateways. 2. Enter the IP address of the gateway in the Additional gateway text box. 3. Enter the priority value in the Priority text box; then click Apply . The IP address of the additional gateway that you entered appears in the Gateway column, and new Additional gateway and Pr iority edit boxes are displayed. T o add more backup static routes, repeat steps 2 and 3. 4. T o make your changes permanent, click Save. Route Aggregation Route aggregation allows you to take numerous specific routes and aggregate them into one encompassing route. Route aggregation can reduce the number of routes that a given protocol
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 399 advertises. The aggregates are activate d by cont ributing routes. For e xample, if a router has many interface routes subnetted from a class C an d is running RIP 2 on another interface, the interface routes can be used to create an aggr egate route (of the class C) that can then be redistributed into RIP . Creating a n aggregate rout e reduces the n umber of routes advertise d using RIP . Y ou must take care must be taken when aggr ega ting if the route that is aggregated contains holes. An aggregate route is created by first specifying the network address and mask length. Second , a set of contributing rou tes must be provided. A contributing route is define d when a source (for example, a routing protocol, a static route, an interface route) and a route filter (a prefix) are specified. An aggregate route can have many cont ributing routes, but at least one of the routes must be present to generate an aggregate. Aggregate routes are not used for packet forwardi ng by the originator of the aggregate route , only by the receiver . A router rece iving a pack et that does not match one of the component routes that led to the generation of an aggr egate route responds with an ICMP network unreachable message. This me s sage prevents packets for unknown component routes from following a default route into another network wh ere they would be continually forwarded back to the border router until their TTL expires. T o create aggregate routes 1. Click Route Aggregation under Co nfiguratio n > Routing Configuration in the tree view . 2. Enter the prefix for the new contributing rout e in the Prefix for new aggregate text box. 3. Enter the mask length (number of bits) in the Mask Length fiel d; then click Apply . The mask length is the prefix length that matc hes the IP address to form an aggregate to a single routing table entry . 4. Scroll through the New Contrib uting Protocol list and click the protocol to use for the new aggregate rou te; then click Apply . 5. Click on in the Contribute All Routes f rom <protocol> field. 6. (Optional) If you want to specify a prefix , fill in the address and mask in the New Contributing Route from <protoco l> field; then click Apply . 7. T o make your changes permanent, click Save. T o remove aggregate routes 1. Click Route Aggregation under Co nfiguratio n > Routing Configuration in the tree view . 2. Click off for the aggregate route disable; then click Apply . 3. T o make your changes permanent, click Save.
9 400 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Route Aggregation Example The figure below shows the n etwor k configuration for the example. In the preceding figure Nokia Platform B, Noki a Platform C, and Nokia Platform D are running OSPF with the backbone area. Nokia Platform A is running OSPF on one interface and RIP 1 on the backbone side interface. Assume that all the interfaces are configured with the addresses and the routing protocol as shown in the figu re. Configure route aggregation of 192.1 68.24.0/24 from the OSPF side to the RIP side. 1. Initiate a Network V oyager session to Nokia Platform A. 2. Click Route Aggregation under Config uratio n > Routing Configuration in the tree view . 3. Enter 192.168.24.0 in the Prefix for New A ggregate text box and enter 24 in the Mask Length edit box; then click Apply . 4. Click OSPF2 in the New Contributing Pr otocol drop-down list; then click Apply . 5. Click on in the Contribute all matching r outes from OSPF2 field; th en click Apply . 6. Click direct in the New Contributing Pr otoc ol drop-down list; then click Apply . 7. Click on in the Contribute All Matching Ro utes from direct field; then click Apply . 8. Click T op. 9. Click the Route Redistribution link in the Routing Co nfiguration section. 10. Click the Aggregates Routes link in the Redistribute to RIP section. 11 . Click on radio button in the Export all aggregates in to RIP field; then click Apply . 00344 Nokia Platform B Nokia Platform D Nokia Platform A Advertise 192.168.24.0 24.49/30 24.46/30 26.1/24 Network Prefix: 192.168.0.0 Nokia Platform C 24.53/30 24.50/30 24.45/30 24.54/30 26.2/24 Backbone running RIPv1 Backbone Area all routers are running OSPF
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 401 Note If the backbone is running OSPF as well, yo u can enable aggregation only by co nfigu ring the 192.168.24.0 network in a d ifferent OSPF Area. Route Rank The r oute rank is the value that the ro uting subsystem uses to o rder routes from different protocols to the same destination. Y ou cannot use rank to control the selection of routes within a dynamic interior gateway protocol (IGP); this is accomplished automa tically by the protocol and is based on the pro t oc ol metric. Y ou can use rank to select routes from the same external gateway protocol (EGP) learned from different peers or autonomous systems. The rank value is an arbitrarily assigned value used to determine the order of routes to the same destination in a single routing database. Each r oute has only one rank asso ciated with it, even though rank can be set at many places in t he co nfiguration. The rou te derives its rank from the most specific route match among all configurations. The active r oute is the route installed into the kernel forwarding table by the routing subsystem. In the case where the same route is contributed by more than one protocol, the one with the lowest rank becomes the active route. Some protocols—BGP and aggregates—allow for routes with the same rank. T o choose the active route in these cases, a separate tie breaker is used. This tie breaker is called LocalPr ef for BGP and weight for aggregates. Rank Assignment s A default rank is assigned to each protocol. Rank valu es range from 0 to 255, with the lowest number indicating the most preferred route. The table below s ummarizes the default rank values. Preference of Default Interfac e rou t es 0 OSPF routes 10 S tatic routes 60 IGRP routes 80 RIP routes 100 Aggregate routes 130
9 402 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o set route rank 1. Click Routing Options under Config uration > Ro uting Configuration in the tree view . 2. Enter the route rank for each proto col; then click Apply . These numbers do not generally need to be changed from their defau lts. Be careful when you modify these numbers; strange routing beha vior might occ ur as a result of a rbitrary changes to these numbers. 3. T o make your changes permanent, click Save. Routing Protocol Rank Example When a destination network is learned from two different routing protocols, (for example , RIP and OSPF) a router must choose one protocol over another . The figure below shows the n etwor k configuration for the example: In the preceding figure, the top part of the ne twork is running OSPF and the bottom part of the network is running RIP . Nokia Plat form D learns network 192.168.2 2.0 from two routing protocols: RIP from the bottom of th e network, and OSPF from the top of the network. When other hosts want to go to 19 2.168.22.0 through Nokia Platform D, Nokia Platform D can select one protocol route, such as an OSPF route first, to reach the destination. If that route is broken, then Nokia Platform D uses another ava ilable route to reach the destination. OSPF AS external routes 150 BGP routes 170 Preference of Default 00337 Nokia Platform B Nokia Platform A Nokia Platform D 26.69/30 26.66/30 Nokia Platform C 26.73/30 26.70/30 26.65/30 26.74/30 26.61/24 26.77/28 26.79/28 26.80/28 26.78/28 26.1/24 0.0.0.0/0 24.0/24 22.0/24 Nokia OSPF Backbone RIP to OSPF Border RIP Network UNIX Hosts with Routed Enabled Hub Corporate Net
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 403 T o configure the routing preferences 1. Click Routing Options under Configuration > Routing Conf iguration in the tree view . 2. Enter 10 in the OSPF edit box. 3. Enter 40 in the RIP edit box; then click Apply . This configuration makes the OSPF rou te the preferred route. T o make the RIP route be the preferred route, enter 40 for OSPF and 10 for RIP . BGP Border Gateway Prot ocol (BGP) is an inter-AS protocol, meaning that it can be deployed within and between auto nomous systems (AS). An autonomous system is a set of routers under a single technical administration. An AS uses an interior gateway protocol and common metrics to route packets within an AS; it uses an exterior r outing protocol to route packets to o ther ASes. Note This implement ation support s BGP version 4 and 4 . BGP sends update messages that consist of ne twork number-AS path pairs. The AS path contains the string of ASes through which the sp ecified network can be re ached. An AS path has some structure in order to represent the results of aggregating dissimilar routes. These update messages are sent over TCP transpor t mechanism to ensure reliable delivery . BGP contrasts with IGPs, which build their own reliability on top of a datagram service. As a path-vector routing protocol, BGP limits the distribution of router reachability information to its peer or neighbor routers. Support for BGP-4 IPSO implements BGP-4 to su pport multiprotocol exte nsions and exchange IPv6 pr efixes as described in RFCs 2545, 285 8, and 3392. Y ou must use an IPv4 address for the router ID (BGP identifier). After the BGP session is up, prefixes can be advertised a nd withdrawn by sending normal UPDA TE messages that include either or both of the new multiprotocol a ttributes MP_REACH_NLRI (used to advertise reachability of routes) and MP_UNREA CH_NLRI (used to withdraw routes). The new attributes are backward compatible. If two routers have a BGP session and only one supports the multiprotocol attributes, they can still exchange un icast IPv4 routes even though they cannot exchange IPv6 routes. On each peer you config ure the type of routes (capability) that should be exchanged between peers. Choose from the following selections:  IPv4 unicast (the default)  IPv6 unicast
9 404 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  IPv4 unicast and IPv6 unicast For peering to be established, th e routers must share a capability . If your system is exchanging IPv4 routes over IP v6 or vice versa, use route map commands to set nexthop to match the family o f the routes bein g exchanged. If they do not match , the routes will not be active. Note Do not use the route redistributi on and inbound fi lter p ages of Ne twork V oyager to configure routing policies for BGP-4 . Instead use th e route map commands in the CLI. BGP Sessions (Internal and External) BGP supports two basic types of sessions between neighbors: internal (s ometimes referred to as IBGP) and external (EBGP). Internal sessions run between routers in the same autonomous systems, while external sessions run between routers in differ ent autonom ous systems. When sending routes to an external peer , the local AS number is pr epended to the AS path. Routes received from an internal neighbor have, in gene ral, the same AS path that the route had when the originating internal ne ighbor received the route from an external peer . BGP sessions might include a single metric (M ulti-Exit Discriminator or MED) in the path attributes. Smaller values of the metric are prefe rred. These values are used to break ties between routes with equal preference from the same neighbor AS. Internal BGP sessions carry at least one metric in the path attributes that BGP calls the local preference. The size of the metric is identical to the MED. Use of these metrics is dependent on the type of internal pro tocol processing. BGP implementations expect external peers to be di rectly attached to a shared subnet and expect those peers to advertise next hops that are host addresses on that subnet. This constraint is relaxed when the multihop option is enabled in the BGP peer template during configuration. T ype internal groups determine the immediate next hops for routes by using th e next hop received with a route from a peer as a forwarding address and uses this to look up an immediate next hop in IGP routes. Such groups support distan t peers, but they need to be informed of t he IGP whose routes they are using to determine immediat e next hops. Where possible, for internal BGP group types, a single outgoing message is built for all group peers based on the common policy . A copy of the message is sent to every peer in the group, with appropriate adjustments to the next hop field to each peer . This minimizes the computational load of runn ing large numbers of peers in these types of groups. BGP Path Attributes A path attribute is a list of AS numbers that a route has traversed to reach a destination. BGP uses path attributes to provide more information about each route and to help prevent routing
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 405 loops in an arbitrary topology . Y ou can also us e path attributes to determine administrative preferences. BGP collapses routes with similar path attributes into a single update for advertise ment. Routes that are received in a single update are readve r tised in a single update . The churn caused by the loss of a neighbor is minimized, and the initial advertisement sent during peer establishment is maximally compressed. BGP does not read information th at the kernel forms message by message. Instead, it fills the input buffer . BGP processes a ll complete messages in the buffer before reading again. BGP also performs multiple reads to clear all incoming data queued on the socket. Note This feature might cause a bu sy peer connec tion to block other protocol s for prolonged intervals. The following table displays the pa th attributes and their definitions All unreachable messages are collected into a si ngle message and are se nt before reachable routes during a flash update. For these unreachabl e a nnouncements, the next hop is set to the local address on the connection, no metric is sent , and the path origin is set to incomplete. On external connections, the AS pa th in unreachable an nouncements is set to the local AS. On internal connections, the AS path length is set to zero. Routing information shared be tween peers in BGP has two formats: announcements and withdrawals. A route announcement indicates that a router either learned of a new network Path Attribute Definition AS_P A TH Identifies the autonomous systems thr oug h which routin g information carried in an UPDA TE message passed. Components of this list can be AS_SET s or AS_SEQUENCES. NEXT_HOP Defines the IP address of the borde r router that should be used as the next hop to the destinations listed in the UPDA TE message. MUL TI_EXIT_DISC Discriminates amo ng multiple exit or entry points to the same neighboring autonomous system. Used onl y on external links. LOCAL_PREF Determines which external route should b e taken and is included in a ll IBGP UPDA TE messages. The assigned BGP speaker sends this message to BGP speakers within its own autonomous system but not to neighboring autonomous systems. Higher values of a LOCAL_PREF are preferred. A TOMIC_AGGREGA TE Specifie s to a BGP speaker that a less specific rou te was chosen over a more specific route. The BGP speaker attaches the A TOMIC_AGGREGA TE attribute to the rou te when it reproduce s it to other BGP speakers. The BGP speaker that receives this route cannot remove the A TOMIC_AGGREGA TE attribute or make any Network Layer Re achability Information (NLRI) of t he route more specific. This attribute is used only for debugging purposes.
9 406 Nokia Network Voyager for IPSO 4.0 Refe rence Guide attachment or made a policy decisio n to prefer another route to a network d estination. Route withdrawals are sent when a router makes a new local decision that a network is no longer reachable. BGP Multi-Exit Discriminator Multi-exit Discriminator (MED) values are used to help ext ernal neighbors decide which of the available entry points into an AS are preferred. A lower MED value is preferred over a higher MED value and breaks the tie between two or more preferred paths. Note A BGP session does not accept MEDs from an external peer unless the Accept MED field is set for an external peer . BGP Interactions with IGPs All transit ASes must be able to carry traf fic that originates from locations outside of that AS, is destined to locations outside of that AS, or both . This requires a certain de gree of interaction and coordination betwee n BGP and the Interio r Gatewa y Protocol (IGP) that the particular AS uses. In general, traffic that originates outside of a given AS passes through bo th inte rior gateways (gateways that support the IGP only) and border gateways (gateways that support both the IGP and BGP). All interior gateways receive information about external routes from one or more of the border gateways of the AS that uses the IGP . Depending on the mechanism used to propagat e BGP information within a given AS, take special care to ensure consistency between BGP a nd the IGP , since changes in state are likely to propagate at different rates across the AS. A time window might occur between the moment when some border gateway (A) receives new BG P routing information (which was originated from another border gateway (B) within the same AS) and the moment the IGP within this AS can route transit traffic to the border gateway (B). During that time window , either incorrect routing or black holes can occur . T o minimize such routing p roblems, border ga teway (A) should not advertise to any of its external peers a route to some set of exterior destinations associated with a given a ddress prefix using border gateway (B) until all the interior gate ways withi n the AS are ready to route traffic destined to these destinations by using the co rrect exit border gateway (B). Interior routing should conver ge on the proper exit gateway before advertising routes that use the exit gateway to external peers. If all routers in an AS are BGP speakers, no interaction is necessary between BGP and an IGP . In such cases, all routers in the AS already have fu ll knowledge of all BGP routes. The IGP is then only used for routing within th e AS, and no BGP routes are imported into the IGP . The user can perform a recursive lookup in th e routing table. The first lookup uses a BGP route to establish the exit router , while the second lookup determines the IGP path to the exit router .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 407 Inbound BGP Route Filters BGP routes can be filtered, or redistributed by AS number or AS path regular expression, or both. BGP stores rejected routes in the routing table w ith a negative pref erence. A negative preference prevents a route from becomin g active and prevents it from being installed in the forwarding table or being redistribu ted to other protocols. This behavio r eliminates the need to break an d re-establish a session upon reconfigurat ion if importation policy is changed. The only attrib ute that can add or modify when you import from BGP is the local preference. The local preference parameter assigns a BGP local pre ference to the imported route. The local preference is a 32-bit unsigned value, with lar ger values preferred. This is the preferred way to bias a routing subsystem preference for BGP routes. Redistributing Routes to BGP When redistributing rout es to BGP , you can mo dify the community , local preference, and MED attributes. Redistribution to BGP is cont rolled on an AS or AS path basis. BGP 4 metrics (MED) are 32-bit unsigned qu antities; they range fro m 0 to 4 294967295 inclusive, with 0 being the most desirable. If th e metric is specified as IGP , any existing metric on the route is sent as the MED. For example, th is allows OSPF costs to be redistributed as BGP MEDs. If this capability is used, any change in the metric causes the route to be redistributed with the new MED, or to flap, so use it with care. The BGP local preference is s ignificant only wh en used with internal BGP . It is a 32-bit unsigned quantity and larger values are preferre d. The local preference should normally be specified within the redistribution list unless no BGP sources are present in the redistribution list. Note If BGP routes are being redistributed into IBGP , the loc al pr ef er en ce can no t be ove rr idd en , and this parameter is ignored for IBGP sources. The same is true for confedera tion peers (CBGP). Communities BGP communities allow you to group a set of IP addresses and apply routing decisions based on the identity of the group or community . T o implement this feature, map a set of comm unities to certain BGP local preference values. Then you can apply a uniform BGP configuratio n to the community as a whole as opposed to each router within the community . The routers in the community can capture routes that match their community values. Use community attributes to ca n configure your BGP speaker to set, append, or modify the community of a route that controls whic h rou ting information is accepted, preferred, or
9 408 Nokia Network Voyager for IPSO 4.0 Refe rence Guide distributed to other neighbors. The following ta ble displays some spec ial community attributes that a BGP speaker ca n apply . For further details, refer to the commun ities documents, RFCs 1997 and 1998. Route Reflection Generally , all border routers in a s ingle AS need to be internal pee rs of each other; all nonborder routers frequently need to be internal peers of all border routers. While this configuration is usually acceptable in small networks, it can lead to unacceptably lar ge internal peer groups in large networks. T o help address this problem, BGP supports route reflection for internal and routing peer grou ps (BGP version 4). When using route reflection, the ru le that specifies th at a router can no t readvertise routes f rom internal peers to other internal peers is relaxed for some routers called ro ute reflectors. A typical use of route reflection might involve a core backbo ne of fully meshed routers. This means that all the routers in the fully meshed group peer direc tly with all other routers in the group. Some of these routers act as route reflectors for ro uters that are not part of the core group. T wo types of route reflection are supported. By de fault, all routes received by the route reflector that originate from a client are sent to all intern al peers (including the client group but not the client). If the no-client reflect option is enabled, routes received from a route reflection client are sent only to internal peers that ar e not members of the client group. In this case, the client group must be fully meshed. In either case, all routes received from a non-client interna l peer are sent to all route reflection clients. T ypically , a single router acts a s the reflector for a set, or cluster , of c lients; for redundancy , two or more routers can also be configured to be refl ectors for the same cluster . In this case, a cluster ID should be selected to identify all reflectors ser ving the cluster , using the cluster ID keyword. Note Nokia recommends that you not use multiple redundant re flectors unnecessarily as it increases the memory required to store rout es on the pee rs of redundant reflectors. Community a ttribute Descriptio n NO_EXPORT (0xFFFFFF0 1) Not advertised outside a BG P confederati on boundary . A stand-alone autonom ous system that is not part of a confederation should b e considered a confede ration itself. NO_ADVERTISE (0xFFFFFF02) Not advertised to other BGP peers. NO_EXPORT_SUBCONFED(0xFFF FFF03) Not advertised to external BGP peers. This includes peers in other members’ autonomou s systems inside a BGP confederation.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 409 No special configuration is requir ed on the route reflection clients. From a client perspective, a route reflector is a normal IBGP peer . Any BG P version 4 speaker should be able to be a reflector client. for further details, refer to the route reflection specification document (RFC 2796 as of this writing). AS1 has five BGP-speaking routers. W ith Router B working as a route reflecto r , there is no need to have all the routers connected in a full mesh. Confederations An alternative to route reflec tion is BGP confederations. As with route reflec tors, you can partition BGP speakers into clusters where each cluster is typically a topologically close set of routers. W ith confederations, th is is accomplished by subdividin g the autonomous system into multiple, smaller ASes that communicate among themselves. The internal topology is hidden from the outside world, which perceives the confederation to be one lar ge AS. Each distinct sub-AS within a confederation is referred to as a routing domain (RD). Routing domains are identified by using a routing domain identifier (RD I). The RDI has the same syntax as an AS number , but as it is not visible outside of the confederation, it does not need to be globally unique, although it d oes need to be unique within the confederation. Many confederations find it convenient to select th eir RDIs from the reserved AS space (ASes 64512 through 65535 (see RFC 1930)). RDIs are used as the ASes in BGP sessions betw een peers within the confederation. The confederation as a whole, is referred to by a co nfederation identifier . Th is identifier is used as the AS in external BGP sessions. As far as the outside world is concerned, the confederation ID is the AS number of the single, large AS. Fo r this reason, the confederation ID must be a globally unique, norma lly assigned AS number . Note Do not nest confederations. Nokia Platform A Nokia Platform D Nokia Platform F Nokia Platform G Nokia Platform C Nokia Platform E Nokia Platform B Non-client Client route reflector Client Non-client Cluster AS676 IBGP IBGP IBGP IBGP EBGP 00328 AS1
9 410 Nokia Network Voyager for IPSO 4.0 Refe rence Guide For further details, refer to the confederations specification do cument (RFC 1965 as of this writing). AS1 has seven BGP-speaking routers grouped unde r different routing domains: RDI A, RDI B, and RDI C. Instead of having a full-mesh connection among all seven routers, you can have a full-meshed connection within just one routing domain. EBGP Multihop Support Connections between BGP speakers of differen t ASes are referred to as EBGP connections. BGP enforces the rule th at peer routers for EBGP connections need to be on a directly attached network. If the peer routers are multiple hops away from each other or if multiple links are between them, you can override this restric tion by enabling the EBGP multihop feature. TCP connections between EBGP peers a re tied to the ad dresses of the outgoing interfac es. Therefore, a single interface failure severs the session ev en if a viable path exists between the peers. EBGP multihop support can provide redundancy so that an EBGP peer session persists even in the event of an interface failure . Using an address assigned to the loopback interface for the EBGP peering session ensures that the TCP connection stays up even if one of the links between them is down, provided the peer loopback address is reachable. In additio n, you can use EBGP multihop support to balance the traf fic among all links. RDI A RDI C EBGP CBGP CBGP RDI B AS2 AS1 00329
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 411 Caution Enabling multihop BGP connections is dangerous because BGP speakers might establish a BGP co nnection through a third-p arty AS. This can violate policy considerations and introduce forward ing loops. Router A and Router B ar e connected by two parallel serial lin ks. T o provide fault tolerance and enable load-balance, enable EB GP multihop and using addr esses on the loopback interface for the EBGP peering sessions. Route Dampening Route dampening lessens the propagation of flapping routes. A flapping route is a route that repeatedly becomes available then unavailable. W ithout route dampening, autonomous systems continually send advertisement a nd withdrawal messages each time the flapping route becomes available or unavailable. As the Internet has grown, the number of annou ncements per second has grown as well and cause d perform ance problems within the routers. Route dampening enables routers to keep a histor y of the routes that are flapping and prevent them from consuming significant network bandwidt h. This is achieved by measuring how often a given route becomes available and then unavailable. Whe n a set threshold is reached, that route is no longer considered valid, a nd is no longer prop agated for a given period of time, usually about 30 minutes. If a route con tinues to flap even after the th reshol d is reached, the time out period for that rou te grows in proportion to each ad ditional flap. Once the threshold is reached, the route is dampened or suppressed. Suppressed routes are added back into the routing table once the penalty value is decreased and falls below the reuse thre shold. Route dampening can cause co nnectivity to appear to be lost to t he outside world but maintained on your own network because route dampening is only applied to BGP routes. Because of increasing load on the backbone network routers, most NSPs (MCI, Sprint, UUNet etc.) have set up route suppression. TCP MD5 Authentication The Internet is vulnerable to attack through its routing protocols and BGP is no exception. External sources can disr up t communications between BGP pee rs by breaking their TCP connection with spoofed RST pa cket s. Internal sources, s uch as BGP spea kers, can inject bogus routing information from any other legitimate BGP speaker . Bogus in formation from either external or internal sources can affect routin g behavior over a wide area in the Inte rnet. AS1 EBGP 00330 Nokia Platform A AS2 Nokia Platform B Loopback Address Loopback Address
9 412 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The TCP MD5 option allows BGP to protect its elf against the intro duction of spoofed TCP segments into the connection stream. T o spoo f a connection using MD5 signed sessions, the attacker not only has to guess TCP sequence numb ers, but also the passw ord included in the MD5 digest. Note TCP MD5 authentication is not ava ilable for BGP session ov er IPv6. BGP Support for V irtual IP for VRRP The Nokia IPSO implementation of BGP supports advertising the virtual IP address of the VRRP virtual router . Y ou can forc e a route to use the virtual IP address as the local endpoint for TCP connections for a specified internal or ex ternal peer autonomous system. Y o u must als o configure a local address for that autonomous system for the VRRP virtual IP option to function. Only the VRRP master e stablishes BGP sess ions. For more information on VRRP , see “VRRP Overview” on page 183. Note Y ou must use monitored-circuit VRRP when c onfiguring virtual IP support for BGP or any other dyna mic routing pr otocol. Do n ot use VRRPv2 when configur ing virtual IP support for BGP . Note BGP support for advertising th e virtual IP add ress of the VRRP virtual router is only available for IPv4 BGP sessions, not f or IPv6. In a VRRPv2 pair , if yo u select the Virtual Address option on the Adv an ce d BGP page, it affect only IPv4 BGP peers. In a VRRPv3 pair , this option is not available for IPv6 BGP peers. Perform the following procedure to configure an a peer auton omous system, correspon ding local address, and to enable suppo rt for virtual IP for VRRP . 1. Click BGPs under Configuration > Routin g Configuration in the t ree view . 2. Enter a value between 1 and 65 535 in the Peer Autonomous System Number edit box. 3. Click the Select the peer group ty pe drop-dow n list and click either Internal or External. If the peer autonomous system number is differ ent from the local autonomous system of this router , click Externa l. If the peer autonomous system number is the same as that of the local autonomous system of this router , click Internal. Y ou must also select Internal if the local autonomous system is part of a confederation. For more information on confederations, see “Confederations” on page 409 . 4. Click Apply . 5. Click the Advanced BGP Options link on the BGP page.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 413 6. For the specific external or ro uting group, enter an IP address in the Local address text box. Note Y ou must configure a local IP address for the sp ecific e xternal or routing group for virtual IP for VRRP support to function. 7. Click On in the V irtual Address field to enable virtual IP for VRRP support. 8. Click Apply . 9. Click Save to make your changes permanent. BGP Support for IP Clustering Nokia IPSO supports BGP in IP clusters. W ith previous versions of IPSO, clusters did not support dynamic routing . On a failover , BGP stops runn ing on the previous master and establishes its peering relati onship on a n ew master . Y ou must configure a cluster IP a ddress as a local address when you run BGP in clustered mode. For more info rmation on IP Clustering, see “IP Clustering Description” on page 207. Note Nokia recommends that you configure BGP in an IP cluster so that peer traf fic does not run on the prima ry and second ary cluster protocol interf aces. Note BGP support for IP clustering is only available fo r IPv4 BGP sessions, not for IPv6. On an IP cluster , you are not allowed to conf igure IP v6 peer . BGP Memory Requirement s Ta b l e s BGP stores its routing information in routing information bases (RIBs). RIB Name Description Adjacency RIB In S tores routes received fro m each peer. Local RIB Forms the core routing table of the router . Adjacency RIB Out S tores rout es advertised to ea ch peer .
9 414 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Memory Size  Base IPSRD is approximately 2 MB  Route entry in the local route table is 76 bytes  Inbound route entry in the BGP table is 20 bytes  Outbound route entry in the BGP table is 24 bytes T o calculate the amount of memory overhead on the routing daemon because of BGP peers, calculate the memory required for all of the RIBs according to the following procedures. Add the result to the base IPSRD size. Inbound RIB: Multiply th e number of peers by the number of routes accepted. Mul tiply the result by the size of each inbound route entry . Local RIB: Multiply the number of routes accepted by a local policy by the size of each local route entry . Outbound RIB: Multiply the number of peers by the number of routes advertised. Multiply the result by the size of each BGP outbound route entry . Example Assume that a customer is peering with two IS Ps that are dual homed and is accepting full routing tables from these two ISPs . Each routing table contains 50 ,000 routes. The customer is only advertising its local routes (2,000) to each ISP . W ith these figures, you can compute the total memory requirements: The base IPSRD memory is 2 MB. Add this value to the following values to calculate the total memory requirements. 1. T o calculate the inbound memory requir ements , multiply the number of peers (two ISPs) by the number of ro utes accepted (50,000). Multiply the resulting value by the size of each inbound route entry in the BGP table (20 bytes). The answer is 2,00 0,000 or 2 MB. 2. T o calculate the local memory r e quir ements , multiply the number of routes accepted (50,000) by the size of each route entr y in the local route table (76 bytes). The answer is 4,00 0,000 or 4MB. 3. T o calculate the outbound memory requiremen ts, multiply the number of peers (only one customer) by the number routes advertised (2,000). Multiply the result by the size of each outbound route entry in the BGP table (24 bytes). The answer is 48,000 or 50 K. 4. Add all of the results together (2MB 2MB 4MB 50K). The answer is 8.05MB, which means that I PSRD requires 8.05 MB of memory for this example.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 415 Note Make sure th at IPSRD is not swapping mem ory . Look a t the memory size s occupied by user-level daem on s like Ch ec k Poin t, ifm , xpand , et c. T o find out how much memory IP SRD occupies, run the following command: ps -auxww | grep ipsrd The fourth column labeled, %M EM, displays the percentage of memory that IPSRD occupies. BGP Neighbors Example BGP has two types: internal and external. Routers in the same au tonomous system that exchange BGP updates run internal BGP; routers in diff erent autonomous systems that exchange BGP updates run external BGP . In the diagram below , AS100 is running IBGP , and AS200 and AS300 are runni ng external BGP . T o configure IBGP on Nokia Platform A 1. Configure the interface as in “Ethernet Interfaces” on pa ge 34. 2. Configure an internal routing pro t oc ol such as OSPF or configure a static route to connect the platforms within AS100 to each other . For more information see “Configuring OSPF” o n page 356 or “T o config ure a default or static route” on page 395. 3. Click BGP under Configuration > Routi ng Configuration in the tree view . 4. Enter a route r ID in the Route r ID text box. The default router ID is the address of the firs t interface. An address on a loopback interface that is not the l oopback address (127.0.0.1) is preferred. 5. Enter 100 in the AS number tex t box. 6. Enter 100 in th e Peer autonomous system number text box. 7. Click Internal in the Peer group ty pe drop-down list; then click Apply . Nokia Platform A Nokia Platform D Nokia Platform B AS100 IBGP EBGP 00331 10.50.10 129.10.21 IBGP 170.20.1 .1 .1 .2 .2 .2 Nokia Platform C .1 .1 AS200 Nokia Platform E EBGP 172.17.10 .2 AS300
9 416 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 8. Enter 10.50.10.2 in the Add remote peer IP address edit box; then click Apply . 9. Configure an inbound route f ilter for AS 100 according to “BGP Route Inboun d Policy Example” on page 446 T o configure IBGP on Nokia Platform B 1. Configure the interface as in “Con figuring an Ethernet Interface”. 2. Configure an internal routing pro t oc ol such as OSPF or configure a static route to connect the platforms in AS100 to each other . For more information see “Configuring OSPF” o n page 356or “T o configure a default or static route” on page 395 3. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 4. Enter a router ID in th e ROUTER ID te xt box. The default router ID is the address of the fi rst interface. An address on a loopback interface that is not the l oopback address (127.0.0.1) is preferred. 5. Enter 100 in the AS nu mber edit box. 6. Enter 100 in the Peer aut onomous system number tex t box. 7. Enter 10.50.10.1 in the Add remote peer IP address text box; th en click Apply . 8. Enter 170.20.1.1 in the Add remote peer IP address text box; th en click Apply . 9. Configure an inbound route f ilter for AS100 according to “BGP Route In bound Policy Example.” T o configure IBGP on Nokia Platform C 1. Configure the interface as in “Con figuring an Ethernet Interface”. 2. Configure an internal routing pro t oc ol such as OSPF or configure a static route to connect the platforms in AS100 to each other . For more information, see “Configuring OSPF” on page 356 or “T o configure a default or static route.” 3. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 4. Enter a router ID in the ROUTER ID e dit box. The default router ID is the address of the fi rst interface. An address on a loopback interface that is not the l oopback address (127.0.0.1) is preferred. 5. Enter 100 in the AS number text box. 6. Enter 100 in the Peer aut onomous system number tex t box. 7. Click Internal in the Peer group ty pe drop-down list; then click Apply . 8. Enter 170.20.1.2 in the Add remote peer IP address text box; th en click Apply . 9. Configure an inbound rout e po licy for AS100 according in “BGP Route Inbound Policy Example.” T o configure Nokia Platform C as an IBGP peer to Nokia Platform A 10. Click BGP under Configuration > Routi ng Confi guration in the tree view .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 417 11 . Enter 10.50.10.1 in the Add remote peer IP address text box 12. Click Apply . T o configure Nokia Platform A as an IBGP peer to Nokia Platform C 1. Click Config on the home page. 2. Click the BGP link in the Ro uting Configuration section. 3. Enter 170.20.1.1 in the Add remote peer IP address text box 4. Click Apply . T o configure EBGP on Nokia Platform A 1. Configure the interface on Nokia Platform A as in “Ethernet Interfaces.” 2. Click BGP under Configuration > Routi ng Configuration in the tree view . 3. Enter 200 in th e Peer autonomous system number text box. 4. Click External in the Peer group t ype drop-down list; then click Apply . 5. Enter 129.10.21. 2 in the Add Remote Peer IP Address text box; t hen click Apply . 6. Configure route redistribution policy according to “Redistributing Routes to BGP” on page 439. 7. Configure an inbound route filter according to “BGP Route Inbound Policy Examp l e.” T o configure EBGP on Nokia Platform C 1. Click BGP under Configuration > Routing Confi guration in the tree view of Platform C. 2. Enter 300 in the AS number tex t box. 3. Click External in the Peer group t ype drop-down list; then click Apply . 4. Enter 172.17.10.2 in the Add remote peer IP a ddress text box; then click Apply . 5. Configure route redistribution policy according to “Redistributing Routes to BGP” on page 407. 6. Configure an inbound route filter according to “BGP Route Inbound Policy Examp l e” on page 446 to allow Nokia Platform C to accept routes from its EBGP peer . T o configure EBGP on Nokia Platform D 1. Configure the interface as in “Ethernet Interfaces.” 2. Click BGP under Configuration > Routi ng Configuration in the tree view . 3. Enter a route r ID in the Route r ID text box. The default router ID is the address of the firs t interface. An address on a loopback interface that is not the l oopback address (127.0.0.1) is preferred. 4. Enter 200 in the AS Number text box. 5. Enter 100 in the Peer Autonomous System Number text box
9 418 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 6. Click External in the Peer g roup type drop-do wn window; then click Apply . 7. Enter 129.10.21.1 in the Add remote peer IP a ddress text box; then click Apply . 8. Configure route inboun d p olicy according to “BGP Route Inbound Policy Example.” 9. Configure route redistribu tion policy according to “Redistributing Routes to BGP” on page 407 10. Configure an inbound route filter according to “BGP Route In bo und Policy Example.” T o configuring EBGP on Nokia Platform E 1. Configure the interface as in “Ethernet Interfaces.” 2. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 3. Enter 300 in the AS nu mber edit box. 4. Enter 100 in the Peer aut onomous system number tex t box. 5. Click External in the Peer group t ype drop-down list; then click Apply . 6. Enter 172.17.10.1 in the Add remote peer IP a ddress edit box; then click Apply . 7. Configure route inboun d p olicy according the “BGP Route Inbound Policy Example” on page 446 . 8. Configure route redistribu tion policy according to “Redistributing Routes to BGP” on page 407. 9. Configure an inbound route filter according to “BGP Route Inbound Policy Examp l e” on page 446 . V erification T o verify that you configured BGP neighbors correctly , run the followi ng command in iclid: show bgp neighbor For more information abou t this command, see to “V iewing Routing Protocol Information.” Path Filtering Based on Communities Example Note T o filter BGP updates based on peer AS numbers, see “T o configure route inbou nd policy on Nokia Platform D based on an autonom ous system number .” T o filter BGP updates based on community ID or special community , specify an AS number along with the community ID or the name of one of the following possible special community attributes: no export, no ad vertise, no subconfed, or none. 1. Click the Advanced BGP options link. 2. Click on in the Enable Communities field, then click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 419 3. Follow the steps described in the “T o configure rou t e inb ound policy on Nokia Platform D based on an autonomous system number” example. 4. Enter the community ID or the name of one of the specia l a ttributes in the Community ID/ Special community text box, then click Apply . 5. Click on button in the Redistribute All Rout es field or enter specific IP prefixes to redistribute as described in the “T o configure route inboun d policy on Nokia Platform D based on an autonomous system number” example, then click Apply . BGP Multi Exit Discriminator Example Multi Exit Discriminator (MED) values are used to help external neighbor s decide which of the available entry points into an AS is preferred. A lower MED value is preferred over a hig her MED value. In the above diagram, MED values are being prop agated with BGP updates. This diagram shows four different configurations.  T o configure Default MED for Nokia Platform D  T o configure MED V alues for all peers of AS200  T o configure MED V alues for each exte rnal BGP peer for Nokia Platform D  T o configure MED V alues and a route redistri bution policy on Nokia Platform D T o configure Default MED for Nokia Platform D 1. Click BGP under Configuration > Routi ng Configuration in the tree view . 2. Configure EBGP peers in AS10 0 and AS200 accord ing to the “BGP Neighbors Example.” 3. Click the Advanced BGP Options link on the main BGP page. This action takes you to the Ad vanced Options for BGP page. 4. In the Miscellaneous settings field, enter a MED value in the Default MED edit box; then click Apply . 5. Click Save to make your changes permanent. This MED value is propagated with all of th e BGP upd ates that are prop agated by Noki a Platform D to all of its EBGP peers in AS100 and AS200. Nokia Platform B Nokia Platform A Nokia Platform C Nokia Platform D EBGP EBGP 00339 AS100 AS200 AS4
9 420 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure MED V alues for all peers of AS200 1. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 2. Configure EBGP peers in AS10 0 and AS200 according to the “BGP Neighbors Example.” 3. Click Advanced BGP Options link on the main BGP page. This action takes yo u to th e Advanced Options for BGP pa ge. 4. Go to the configuration section fo r the AS4 routing group. Enter 100 in the MED text box for the AS4 routing group. Setting a MED value here propagates updates from all peers of AS4 with this MED val ue. Note Setting an MED value for all peers under the local AS overwrites the defa ult MED setting of the respective internal pee rs. T o configure MED V alues for each external BGP peer for Nokia Platform D 1. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 2. Configure EBGP peers in AS10 0 and AS200 according to the “BGP Neighbors Example.” 3. Click the link for the peer IP addre ss for Nokia Platfo rm A un der AS100. 4. Enter 100 in the MED sent out text box. 5. Click on in the Accept MED from extern al peer field; then click Apply . 6. Click the link for the peer IP addre ss for Nokia Platfo rm B un der AS100. 7. Enter 200 in the MED sent out text box. 8. Click on in the Accept MED from extern al peer field; then click Apply . 9. Click the link for the peer IP addre ss for Nokia Platfo rm C un der AS200. 10. Enter 50 in the MED sent out text box. 11 . Click on in the Accept MED from extern al peer field; then click Apply . 12. Click Save to make your changes perman en t. This configuration allows Nokia Platform D to prefer Nokia Platform A ( with the lower MED value of 100) over Nokia Platform B (with the higher MED valu e of 200) as the en try point to AS100 while it propagat es routes to AS100. Simila rly , this config uration propagates routes with an MED value of 50 to AS200, alth ough no multiple entry points exist to AS200. T o configure MED V alues and a route redistribu tion policy on Nokia Platform D 1. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 2. Configure EBGP peers in AS10 0 and AS200 according to the “BGP Neighbors Example.” 3. Click the Route Redistribution link the Routing Configuration section. 4. Click the BGP link in the Re distribute to BGP section.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 421 5. Enter 100 in MED edit bo x next to the Enable redistribut e bgp routes to AS100 field. 6. Enter necessary information for rout e redistribution according to the “BGP Multi Exit Discriminato r Example” ; then click Apply . 7. Click Save to make your changes permanent. Setting an MED value along with route redist ribution policy allows Nokia Platform D to redistribute all routes to AS100 with an MED value set to 100. Note Setting an MED value along with route redistr ibution overwrites the MED value for the external BGP peer for Nokia Platfo rm D. V erification T o verify that you configured BGP MED values correctly , run the followi ng commands in iclid. show route show bgp neighbor <peerid> advertised show route bgp metrics For more information on these commands, see “V iewing Routing Protocol Information.” Changing the Local Pref erence V alue Example This example shows how to set up two IBGP peer s, and how to configure routes learned using Nokia Platform A to have a higher local prefer ence value over Nokia Platform B (which has a default local preference value of 100). 1. Configure the interface as in “Ethernet Interfaces.” 2. Click IGBP under Configuration > Routing Configuration in the tree view . 3. Enter 100 in the AS number text box; then click Apply . Nokia Platform A Nokia Platform C Nokia Platform B IBGP EBGP EBGP 00332 20.10.10.2/24 20.10.10.1/24 20.10.5.1/24 20.10.5.2/24 Nokia Platform D 20.10.15.2/24 20.10.5.1/24 AS100 AS676 AS342
9 422 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure an IBGP peer for Nokia Platform B 1. Enter 100 in the Peer Autonomous Syst em Number text box. 2. Click Internal in the Peer Group ty pe drop-down list; then click Apply . 3. Enter 20.10.10.2 in the Add Remote Peer IP Address text box; then click Apply . T o set the local preference value for an IBGP peer 1. Click Up to take you back to the main Config page for Network V oyager . Click the Inbound Route Filters link in the Routing Co nfiguration section. 2. Click Based on Autonomous System Number . 3. Enter 512 (or any unique number in th e range of 512 to 1024) in the Import ID text box. 4. Enter 100 in the AS text box. 5. Enter 200 in the LocalPref text box. 6. Click Apply . 7. Click Accept in the All Routes from BG P AS 100 field; then click Ap ply . T o configure the static routes required for an IBGP session 1. Click Static Routes under Configuration > Routing Config uratio n in the tree view . 2. Enter 10.10.10.0 in the New static route text box. 3. Enter 24 in the Mask length text box. 4. Enter 20.10.10.2 in the Gateway text box; then click Ap ply . T o configure the static routes required for Nokia Platform B 1. Configure the interface as in “Ethernet Interfaces.” 1. Click BGP under Configuration > Routi ng Configuratio n in the tree view . 2. Enter 20.10.10.2 in the Router I D text box. 3. Enter 100 in the AS number text box. 4. Enter 20.10.10.1 in the Add remote peer ip address text box, then click Apply . 5. Click T op button at the top of the configuration page. 6. Click the S tatic Routes link in th e Routing Configuratio n section. 7. Enter 10.10.10.0 in the New S tatic Route text box. 8. Enter 24 in the Mask Length text box. 9. Enter 20.10.10.1 in the Gateway text box; then click Ap ply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 423 BGP Confederation Example In the above diagram, all the routers belong t o the same Confederation 65525. No kia platform A and Nokia platform B belong to routing domain ID 65527, No kia platform C and Nokia platform D belong to routing do main ID 65528, and Nokia platfo rm E belongs to routing domain ID 65524. In this example, y ou configure Nokia platform B an d Nokia platform C as members of Confederation 65525 and as members of separa te routing domains within the confederation. Y ou also configure each platform as confederation pe ers to Nokia platform E, which has a direct route to the external AS. Configuring Nokia Platform C 1. Set up the confederation an d th e routing domain identifier . a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Enter 65525 in the Confederation text box. d. Enter 65528 in the Routing domain identifie r text box; t hen click Apply . 2. Create confederation group 6552 4. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Enter 65524 in the Peer Autonomous System Number text box. d. Click Confederation in the Peer Group T ype drop-down list; then click Apply . Define properties for the above group. e. Click On in the All field. Nokia Platform A Nokia Platform B Nokia Platform E 00333 192.168.35 192.168.30 T o external AS AS65524 Confed 65525 AS65527 Confed 65525 AS65528 Confed 65525 AS65525 .1 .1 .1 .2 .2 Nokia Platform D Nokia Platform C 192.168.45 .1 .2 .2 192.168.40
9 424 Nokia Network Voyager for IPSO 4.0 Refe rence Guide f. Click On in the All Interfaces field; then click Apply . g. Enter 192.168.40.1 in the Add a new peer text box; then c lick Apply . 3. Create confederation group 6552 8. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Enter 65528 in the Peer Autonomous System Number text box. c. Click Confederation in the Peer Group T ype drop-down list; then click Apply . Define properties for the above group. d. Click on in the all field. e. Click on in the All Interface field; then click Apply . f. Enter 192.168.45.1 in the Add a new peer text box; then click Apply . 4. Define BGP route inbound po licy by using regular expressions for any AS path and from any origin. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click the Based on ASPath Regular Expres sions link. c. Enter 1 in the Import ID text box and enter .* in the ASP A TH Regular Expression text box; then clic k Ap ply . d. Click On in the Import All Routes From AS Path field; then click Apply . 5. Define route redistribution. a. Click Route Redistribution under Configurat ion > Routing Confi guration in the tree view . b. Click the BGP link in the Re distribute to BGP section. c. Click 65528 in the Redistribute to Peer AS drop-down list. d. Click 65524 in the From AS dr op-down list; then click Apply . e. Click On in the Enable Redistribution of Routes F rom AS 65524 into AS 65528 field ; then click Apply . f. Click On in the all BGP AS 65524 routes into AS 655 28; then click Apply . g. Click Save. Configuring Platform B 1. Set up the confederation and th e routing domain identifier . a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Enter 65525 in the Confederation text box. d. Enter 65527 in the Routing domain identifie r text box; then click Apply .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 425 2. Create confederation group 6552 4. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click the Advanced BGP Options link. c. Enter 65524 in the Peer Autonomous S ystem Number text box. d. Click Confederation in the Peer Group T ype drop-down list; then click Apply . Define properties for the above group. e. Click On in the All field. f. Click On in the All Interfaces field; then click Apply . g. Enter 192.168.30.1 in the Add a new peer text box; then click Ap ply . 3. Create confederation group 6552 7. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Enter 65528 in the Peer Autonomous System Number text box. c. Click Confederation in the Peer Group T ype drop-down list; then click Apply . Define properties for the above group. d. Click On in the All field. e. Click On in the All Interface field; then click Apply . f. Enter 192.168.35.1 in the Add a new peer text box; then c lick Apply . 4. Define BGP route inbound po licy by using regular expressions for any AS path and from any origin. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click the Based on ASPath Regular Expres sions link. c. Enter 1 in the Import ID text box and enter .* in the ASP A TH Re gular Expression text box; then clic k Ap ply . d. Click On in the Import All Routes fro m AS path field; then click Ap ply . 5. Define route redistribution. a. Click Route Redistribution under Configurat ion > Routing Co nfiguration in the tree view . b. Click the BGP link in the Re distribute to BGP section. c. Click 65528 in the Redistribute to Peer AS drop-down list. d. Click 65524 in the From AS dr op-down list; then click Apply . e. Click On in the Enable Redistribution of Routes F rom AS 65524 Into AS 65527 field ; then click Apply . f. Click On in the All BGP AS 65524 Routes Into AS 65528 field ; then click Apply . g. Click Save to make your changes p ermanent.
9 426 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Route Reflector Example This example shows configuration for setting up route reflection for BGP . Route reflection is used with IBGP speaking routers that are not fully meshed. In the above diagram, route r Nokia platform A is on AS 65525, and route rs Nokia platform B, Nokia platform C, and Nokia platform D are in AS 65526. This example shows how to c onfigure Nokia platform B to act as a ro ute reflector for clients Nokia pl atform C and Nokia platform D: Y ou then configure platforms C and D and IBGP peers to platform D, as the example shows. Y ou configure inbound route and redistribution policies for AS 65526. Configuring Platform B as Route Reflector 1. Assign an AS number for this router . a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Enter 65526 in the AS number text box; then click Apply . 2. Create an external peer group. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Enter 65525 in the Peer Autonomo us System Number text box. d. Click External in the Peer Group T y pe drop-down list; then click Apply . 3. Enter the peer information. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Enter 192.168.10.2 in the Add Remote Peer IP Ad dress text box under the AS 65525 External Group; then click Apply . 4. Create an internal group. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Enter 65526 in the Peer auto autonomous system number text box. Nokia Platform A 00334 AS65525 AS65526 Nokia Platform B 192.168.10 192.168.20 192.168.30 .2 .2 .2 .1 .1 .1 Nokia Platform D Nokia Platform C Route reflector Client Client IBGP EBGP
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 427 d. Select Internal in the Peer group type drop-down list; then click Apply . 5. Configure parameters for the group. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click Advanced BGP Options. c. Click On in the All field. This option covers all IGP and static routes. d. Click On in the All Interfaces field; then click Apply . 6. Enter the peer information. a. Click BGP under Configuration > Routi ng Configuration i n the tree view . b. Click the Advanced BGP Options link. c. Enter 192.168.20.2 in the Add remote peer ip address text box under the AS65 526 routing group. d. Select Reflector Client from the Peer type drop-down list; then click Apply . e. Click BGP under Configuration > Routi ng Configuration i n the tree view . f. Click the Advanced BGP Options link. g. Enter 192.168.30.2 in the Add remote p eer ip address text box under the AS6552 6 routing group. h. Select Reflector Client from the Peer type drop-down list ; then click Apply . Configuring Platform C as IB GP Peer of Platform B 1. Click BGP under Configuration > Routing Confi guration in the tree view on Platform C. 2. Enter a route r ID in the Route r ID text box. The default router ID is the address of the firs t interface. An address on a loopback interface that is not the l oopback address (127.0.0.1) is preferred. 3. Enter 65526 in the AS Number text box. 4. Enter 65526 in the Peer Autonomous System Number text box. 5. Click Internal in the Peer group ty pe drop-down list; then click Apply . 6. Enter 192.168.20.1 in the Add remote peer IP address text box; then click Apply . 7. Click Save to make your changes permanent. Configuring Platform D as IB GP Peer of Platform B 1. Click BGP under Configuration > Routing Confi guration in the tree view on Platform D. 2. Enter a route r ID in the Route r ID text box. The default router ID is the address of the firs t interface. An address on a loopback interface that is not the l oopback address (127.0.0.1) is preferred. 3. Enter 65526 in the AS Number text box.
9 428 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. Enter 65526 in the Peer Autonomous System Number text box. 5. Click Internal in the Peer Group T y pe drop-down list; then click Apply . 6. Enter 192.168.30.1 in the Add remote peer IP address text box; then click Apply . 7. Click Save to make your changes pe rmanent. Configuring BGP Route Inbo und Policy on Platform B 1. Click Inbound Route Fi lters under Configuration > Routing in the tree view . 2. Click the Based on Autonomous Sy stem Number link. 3. Enter 512 in the Import ID text box and enter 65526 in the AS edit box; then click Apply . 4. Click Accept in the All BGP Routes Fr om AS 65526 field; then click Apply . 5. Enter 513 in the Import ID edit box and enter 65525 in the AS edit box; then click Apply . 6. Click Accept in the All BGP Routes Fr om AS 65525 field; then click Apply . 7. Click Save to make your changes pe rmanent. Configuring Redistribution of BGP Routes on Platform B Complete this procedure to redistribute BGP rout es to BGP that section a different AS. This is equivalent to configuring an export policy . In th is example, as the diagram shows, platform B, which is part of AS 65526, is an EB GP peer to platform A, which belongs to AS 6552 5. 1. Click Route Redistribution und er Configuration > Routing in the tree view . 2. Click the BGP Routes Based on AS link in the Redistribute to BGP section. 3. Select 65526 in the Redistribute to Peer AS drop-down list an d select 65525 in the From AS drop-down list. 4. Click On in the Enable Redist ribute BGP Routes From AS 65525 Into AS 65526 fie ld; then click Apply . 5. Click Accept in the All BGP ASP A TH 65525 Routes Into AS 65526 field; then click Apply . 6. Select 65525 in the Redistribute to Peer AS drop-down list an d select 65526 in the From AS drop-down list. 7. Click On in the Enable Redist ribute BGP Routes From AS 65526 Into AS 65525 fie ld; then click Apply . 8. Click Accept in the All BGP ASP A TH 65526 Routes Into AS 65525 field; then click Apply . 9. Click Save to make your changes pe rmanent. BGP Community Example A BGP community is a group of destinations that share the same property . However , a community is not restricted to one network or AS.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 429 Communities are used to simplify the BGP inbound and route redistri bution policies. Each community is identified by either an ID or one of the following special community names: no export, no advertise, no subconfed , or none. Note Specify the community ID and the AS number in order to generate a unique AS number- community ID combination. T o restrict incoming routes based on their community values, see “Path Filtering Based on Communities Example.” T o redistribute routes that match a specified co mmunity attribute, append a community attribute value to an existing community attribute value, or both. Note The examples that follows is valid on ly for redistributing routes from any of the specified routing protocols to BGP . For example, conf iguring community-based r oute redistribution policy from OSPF to BGP auto matically enables the same community-based redistribution policies for all of the other configured policies. In such an example, if you configure a route redistribution policy for OSPF to BGP , these changes also prop agate to the redistributio n policy for the inte r fac e routes into BGP . 1. Follow the steps in the “Redistributing OSPF to BGP Example.” 2. Match the following ASes with the following community IDs—AS 4 with community ID 1 (4:1), AS 5 with community ID 2 (5:2), AS w ith no export—by entering the AS values in the AS text box and the community IDs in the Co mmunity ID/Special community text box; then click Apply . Note Matching an AS with the no export option only matches those ro utes that have all of the preceding AS number and commu nity ID values. 3. T o append an AS number and co mmunity ID co mbination to the matched routes, click on in the Community field; then click Apply . 4. Match AS 6 with community ID 23 (6 :23) by entering 6 in the AS edit box and 23 in the Community ID/Special community text bo x; then click Apply . 5. Match AS with no advertise; then cli ck Apply . Note Matching an AS with the no advertise optio n appends the community attribute with the values described in step 2. Thus, all of the rout es with the community attr ibutes set to 4:1, 5:2, and no export are r edistributed with the appended communi ty attributes 4:1, 5:2, no export, 6:23, and no advertise.
9 430 Nokia Network Voyager for IPSO 4.0 Refe rence Guide EBGP Load Balancing Example: Scenario #1 Loopback interfaces are used to configure load balancing for EB GP between two ASes over two parallel links. This example consists of the following:  Enabling BGP function  Configuring loopback addresses  Adding static routes  Configuring peers  Configuring inbound and ro ute red istribution policies In the following diagram:  Nokia Platform A is in autonomous system AS100, and Nokia Platform B is in autonomous system AS200.  Nokia Platform A has a loopback address of 1. 2.3.4, and Nokia Platfo rm B has a loopback address of 5.6.7.8. Configuring a Loopback Address on Platform A 1. Configure the interface as in “Ethernet Interfaces.” 2. Click Interface Configuration unde r Configuration in the tree view . 3. Click the Logical Address Loopback link. 4. Enter 1.2.3.4 in the New IP Address text box; then click Apply . Configuring a Loopback Address on Platform B 1. Configure the interface as in “Ethernet Interfaces.” 2. Click Interface Configuration unde r Configuration in the tree view . 3. Click the Logical Address Loopback link. 4. Enter the 5.6.7.8 in the New IP address text box; th en c lick Apply . Configuring a S t atic Ro ute on Platform A 1. Click Static Routes under Configur ation > Routing in the tree view . 2. Enter 5.6.7.8 in the New static route text box to r each the loopback address of Platform B. 3. Enter 32 in the Mask length ed it box; then click Apply . AS100 00335 Nokia Platform A AS200 Nokia Platform B Loopback 1.2.3.4 Loopback 5.6.7.8 129.10.1.1 129.10.2.1 129.10.1.2 129.10.2.2
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 431 4. Enter 129.10.2.2 in the Additional Gateway ed it box; then click Apply . 5. Enter 129.10.1.2 in the Additional Gateway edit box; then click Apply . Configuring a S t atic Ro ute on Platform B 1. Click Static Routes under Configur ation > Routing in the tree view . 2. Enter 1.2.3.4 in the New static route text box to r each the loopback address of Platform A. 3. Enter 32 in the Mask length text box; then click Apply . 4. Enter 129.10.2.1 in the Ad d itiona l Gatewa y edit box; then click Apply . 5. Enter 129.10.1.1 in the Add itiona l Gateway text box; then click Apply . Configuring an EBGP Peer on Platform A 1. Configure an EBGP peer on Platform A as in “Ethernet Interface s.” 2. Enter 1.2.3.4 as the local address on the main BG P configuration page. Click Ap ply . 3. Configure the inbound and ro ute redistribution policies. 4. Click the link for specific peer you config ured in Step 1. This action takes you the page that lets you configur e options for that peer . 5. In the Nexthop field, click on next to EBGP Multihop to enable th e multihop option; then click Apply . 6. (Optional) Enter a value in the TTL text box to set the number of hops over which the EBGP multihop session is established. The default value is 64 and the range is 1 to 255. Click Apply . Configuring an EBGP Peer on Platform B 1. Configure an EBGP peer on Platform B as in “Ethernet Interface s.” 2. Enter 5.6.7.8 as the local address on the main BGP configuration page. 3. Configure the inbound and ro ute redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action take s you the page th at lets you configure op tions for that peer . 5. In the Nexthop field, click on next to EBGP Multihop to enable th e multihop option; then click Apply . 6. (Optional) Enter a value in the TTL text box to set the number of hops over which the EBGP multihop session is established. The default value is 64 and the range is 1 to 255. Click Apply .
9 432 Nokia Network Voyager for IPSO 4.0 Refe rence Guide EBGP Load Balancing Example: Scenario #2 Configuring a Loopback Address on Platform A 1. Configure the interface as in “Ethernet Interfaces.” 2. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 3. Click the Logical Address Loopback link. 4. Enter 1.2.3.4 in the New IP Address text box; then click Apply . Configuring a Loopback Address on Platform B 1. Configure the interface as in “Ethernet Interfaces.” 2. Click Interfaces under Configuration > Inte rface Configuration in the tree view . 3. Click the Logical Address Loopback link. 4. Enter the 5.6.7.8 in the New IP Address text box; then click Apply . Configuring OSPF on Platform A 1. Click OSPF under Configuratio n > Routing in the tree view . 2. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.1.1; th en click Apply . 3. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.2.1; th en click Apply 4. Enter 1.2.3.4 in the Add a new stub host column, then click Apply . Configuring OSPF on Platform B 1. Click OSPF under Configuratio n > Routing in the tree view . 2. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.1.2; th en click Apply . 3. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.2.2; th en click Apply . 4. Enter 5.6.7.8 in the Add a New Stub Host column and then click Apply . Configuring an EBGP Peer on Platform A 1. Configure an EBGP peer on Platform A as in “Ethernet Interface s.” 2. Ente r 1.2.3.4 as the local address on the main BGP configuration page. 3. Configure the inbound and ro ute redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action takes you the pa ge that lets you configure op tions for that peer .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 433 5. In the Nexthop field, click on next to EBGP Multihop to enable th e multihop option; then click Apply . 6. (Optional) Enter a value in the TTL text box to set the number of hops over which the EBGP multihop session is established. The default value is 64 and the range is 1 to 255. Click Apply . Configuring an EBGP Peer on Platform B 1. Configure an EBGP peer on Noki a Pla tform B as in “Ethernet Interfaces.” 2. Enter 5.6.7.8 as the local address on the main BGP configuration page. 3. Configure the inbound and ro ute redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action take s you the page th at lets you configure op tions for that peer . 5. In the Nexthop field, click on next to EB GP Multihop to enable the multihop option, and then click Apply . 6. (Optional) Enter a value in the TTL text box to set the number of hops over which the EBGP multihop session is established. The default value is 64 an d the range is 1 to 255. 7. Click Apply . V erification T o verify that you have configured load ba lancing correctly , run th e following commands in iclid: show bgp neighbor show route bgp For more information on these commands, see “V iewing Routing Protocol Information.” . Adjusting BGP T imers Example 1. Configure a BGP neighbor as in the “BGP Neighbors Example.” 2. Click the link for the peer IP address to confi gure peer-specific parameters. 3. Enter a value in seconds in the Holdtime text box. Holdtime indicates the maximum number of secon ds that can elapse between the receipt of successive keepalive or update messages by the sender be fore the peer is declared dead. It must be either zero (0) or at least 3 seconds. The default value is 180 seconds. 4. Enter a value in seconds in the Keep alive text box; then click Apply . BGP does not use any transport- protocol-based keepalive mech anism to determine whether peers are reachable. Instead, keepalive messag es are exchanged between peers to determine whether the peer is still reachable.
9 434 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The default value is 60 sec onds. 5. T o make your changes permanent, click Save. TCP MD5 Authentication Example Configuring TCP MD5 Authentica tion on Nokia Platform A 1. Configure the interface as in “Ethernet Interfaces.” 2. Click BGP under Configuration > Routing in the tree view . The following two steps enable BGP function on Nokia Platform A. 3. Enter 10.10.10.1 (default is the lowest IP address on the appliance) in the Router ID text box. 4. Enter 100 in the AS number text box, then click Apply . The following 2 steps configure the EBGP peer for Nokia Platform B. 5. Enter 200 in the Peer autonomous system number text box. 6. Select External in the Pee r group type drop-d own list; then clic k Apply . The following steps configure an EBGP peer with MD5 authentication 7. Enter 10.10.10.2 in the Add remote peer ip addr ess text box; th en click Apply . 8. Click the 10.10.10.2 link to access the BGP peer configuration page 9. Select MD5 as the authentica tion type from the AuthT ype dr op-down list; then click Apply . 10. Enter the MD5 shared ke y (test123 for example) in the Key text box; then click Apply . Configuring BGP Route Redistr ibution on Nokia Platform B 1. Configure the interface as in “Ethernet Interfaces.” 2. Click BGP under Configuration > Routing in the tree view . The following three steps enable BG P function on Nokia Platform B. 3. Enter 10.10.10.2 (default is the lowest IP address on the appliance) in the Router ID text box. 4. Enter 200 in the AS number edit box; then click Apply . The following 2 steps configure the EBGP peer for Nokia Platform B. 5. Enter 100 in the Peer autonomous system number text box. AS100 00336 Nokia Platform A AS200 Nokia Platform B 10.10.10.1/24 10.10.10.2/24 EBGP
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 435 6. Click External in the Peer group t ype drop-down list; then click Apply . The following steps co nfig ure an EB GP peer with MD5 authentication 7. Enter 10.10.10.1 in the Add remote peer ip address text box; then click Apply . 8. Click the 10.10.10.1 link to access the BGP peer configuration page. 9. Select MD5 as the authentica tion type from the AuthT ype dr op-down list; then click Apply . 10. Ente r the MD5 shared key (test123 for exampl e) in the Key edit box; then click Apply . BGP Route Dampening Example BGP route dampening maintains a stable history of flapping routes and prevents advertising these routes. A stability matrix is used to measure the stabilit y of flapping routes. The value of this matrix increases as routes become more unsta ble and decreases a s they become more stable. Suppressed routes that are stable for long period of time are re-advertised again. This example consists of the following:  Enabling BGP function  Enabling weighted route dampening 1. Click BGP under Configuration > Routing in the tree view . 2. Click the Advanced BGP Options link. 3. Enable weighted route dampenin g by clicking on in the Enable W eighted Route Dampenin g field; then click Apply . The following fields are displayed: 4. Enter any changes in the text boxes that corr espond to the appropriate fields, then click Apply . Field Default value Units of measurement Suppress above 3 Number of route flaps or approximate value of the instability metric Reuse be low 2 Same as above Max flaps 16 Same as above Reachable decay 300 Seconds Unreachable decay 900 Seconds Keep history 1800 Seconds
9 436 Nokia Network Voyager for IPSO 4.0 Refe rence Guide V erification T o verify that you have configured rou te da mpening correctly , run the following command in iclid.: s how route bgp suppressed For more information on this command, see “V iewing Routing Protocol Information.” BGP Path Selection The following rules will help you understand how BGP selects paths:  If the path specifies a next hop that is inaccessible, drop the update.  Prefer the path with the lowest weight. A route whose weig ht value is no t specified is always less preferred than the path with the highest set weight value. Normally , the route with the highest set weight value is the least preferred. Note The Nokia implement ation of weight value differs from th at of other vendors.  If the weights are the same, prefer the pa th with the largest local preference.  If the local preferences are the same, prefer the route that has the shortest AS_path.  If all paths have the same AS_path length, prefer the path with the lowest origin type (Origin IGP < EGP < Incomplete).  If the origin codes are the same, prefer the pa th with the lowest MED attribute (if MED is not ignored).  If the paths have the same M ED, prefer th e external pa th over the internal path.  If the paths are still the same, prefer the path through the closest IGP neighbor .  Prefer the path with the lowest IP addr ess, as specified by the BGP router ID. BGP-4 Example This example describes how to configure a BGP4 se ssi on over IPv6 transport . In this example, a connection is established between 2 routers (Rou ter 1 and Router 2) in dif ferent autonomous systems over an IPv6 network to ex change both IPv4 an d IPv6 routes. The following procedure describes the process, which consis ts of configuring the connection on each router , and then advertising the routes to Router 2.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 437 T o configure configure a BGP4 session over IPv6 transport 1. Determine whether Route r 1 and Router 2 are directly conn ected. a. If Router 1 and Router 2 are directly connected, use IPv6 addresses of the interface through which they are connected. If they are directly connected, you can use th eir link-local addresses for BGP peering. T o do this, on BGP configuration page, specif y the link-local address in the Add Remote Peer's Address (IPv6) text box, and then selec t the name of the interface by which this router is connected to the BGP peer in Outgoing Interface drop -down list. b. If Router 1 and Router 2 are not directly connec ted, then verify that bo th routers have an IPv6 route to the IPv6 address tha t is used by the other router for BGP peer ing . Y o u can verify this by going to the IPv6 Route Monitor page or usin g the show IPv6 route command . 2. Log in to Router 1 u sing Network V oyager and configure th e connection as follows. a. Click BGP under Configuration > Routing in the tree view . b. Enter AS number of the oth er router . c. In the Peer Group T ype drop-down list, select External. d. Click Apply . e. Under AS2 External Group, in the Add Remote Peer Address (IPv6) text box, enter the IPv6 address of Router 2 . f. Click Ap ply . g. Under Peer , click on the IP address link for Router 2. The BGP Peer < ipv6_addr> in AS2 page appears. h. Under Multicast Capabilities, select On fo r IPv6 Unicast. IPv4 unicast capability is already selected by default—retain this setting. i. Click Apply . j. If Router 1 and Router 2 are not directly connected, select On for EBGP Multihop. k. Click Apply . l. T o make your changes permanent, click Save. m. Repeat these steps on Router 2. 3. On Router 1, create a route map named adve rtise_to_as2 to advertise the routes from Router 1 to Router 2. Note For information on creating and u sing route maps, see the CLI Reference Guide for Nokia IPSO .
9 438 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. On Router 1, use this route map by executing the following CLI comman d to send both IPv4 and IPv6 unicast route s to AS 2. set bgp external remote-as 2 export- routemap advertise_to_as2 preference 1 family inet-and -inet6 Note The actual routes sent w ill be based on the match cond itions of the route map. 5. On Router 2, configure a routemap called accept_fr om_as2 to accept incomming IPv4 and IPv6 routes advertised by router 1. (BGP by default does not accept incomming routes.) 6. On Router 2, execute the following CLI co mmand to use this route map to accept the incoming routes . set bgp external remote-as 1 import-routemap accept_from_as2 preference 1 family inet-and -inet6 Route Redistribution Route redistribution allows routes learned from one routing protocol to be propagated to another routing protocol. This is necessary when routes fro m one protocol such as RIP , IGRP , OSPF , or BGP need to be advertised into anoth er prot ocol (when two or more routing protocols are configured on the same route r). Route redistribution is also useful for a dvertising static routes, such as the default route, or aggregates into a protocol. Note Route metrics are not translated between dif ferent routing protocols. Note Y ou can also us e route maps to r edistribute routes from one protocol to another . Y ou can define route maps only using CLI commands. For information on route ma ps, see “Route Maps” on page 353 and the CLI R eference Guide . When you leak rou tes between protocols, you specify routes that are to be injected and routes that are to be excluded. In the case where the prefix is redistributed, you can specify the metric to advertise. The metr ic is sent to the peer by certain protoc ols and may be used by the peer to choose a better route to a given destination. Some routing protocols ca n associate a metric with a route when announcing the route. For each prefix that is to be re distributed or excluded, the prefix is matched against a filter . The filter is composed of a single IP pref ix and one of the fo llowing modifiers:  Normal —Matches any route that is equal to or more specific than the given prefix. This is the default modifier .  Exact —Matches a route only if it equals the IP address and mask length of the given prefix.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 439  Refines —Matches a route only if it is more specific than the given prefix.  Range —Matches any route whose IP address equals the given prefix’ s IP address and whose mask length falls within the specified mask length range. A sample route re distribu tion examples follow . Note The Route Redistribution link cont ains over th irty possible route redistribution options. The r edistribute_list specifies the source of a set of routes based on parameters such as the protocol from which the source has been learned. The r edistribute_list indirectly controls the redistribution of routes between pr otocols. The syntax varies slightly per source protocol . BGP routes may be specified by source AS. RIP and IGRP routes may be redistrib uted by protocol, source in terface, and/or source gateway . Both OSPF and OSPF ASE routes may be redistributed into other protocols. All routes may be redistributed by AS path. When BGP is configured, all rout es are assigned an AS path when they are added to the routing table. For all interior routes, this AS path specifies IGP as the orig in and no ASes in the AS path. The current AS is added when the route is redistri buted. For BGP routes, the AS path is stored as learned from BGP . Redistributing Routes to BGP Redistributing to BGP is controlled by an AS. Th e same policy is applied to all firewalls in the AS. BGP metrics are 16-bit, unsigned quantities; that is, they range from 0 to 65535 inclusive, with zero being th e most attractive. Whi le BGP version 4 supports 32-bit unsigned quantities, IPSRD does not. Note If you do not specify a redis trib u tio n po licy , only routes to attach ed interfaces are redistribute d. If you sp ecify any policy , the defaults are overridden. Y ou mu st explicitly specify everything that should be redistrib uted.
9 440 Nokia Network Voyager for IPSO 4.0 Refe rence Guide BGP Route Redistribution Example Route redistribu tion allows you to redistribute routes fro m one autonomous system into anothe r autonomous system. T o configure BGP route redistribution on Nokia Platform D 1. Click Route Redistribution und er Configuration > Routing in the tree view . 2. Click BGP Routes Based on AS under the Redistribute to BGP section. 3. Select 100 from the Redistribute to Peer AS drop-down list. 4. Select 4 from the From AS drop-down list; then click Apply . This procedure enables route redistribution from AS 4 to AS 100. By default, all routes that are excluded from being redistributed from AS 4 are redistributed to AS 100. T o redistribute a single route 1. T o restrict route redistribut ion to route 100.2. 1.0/24, enter 100.2.1.0 in the New IP prefix to redistribute text box. 2. Enter 24 in the Mask length text box; then click Apply . 3. Select Exact from the Match T ype drop-down list; then click Apply . This procedure enables redistribution of route 10 0.2.1.0/24 from AS 4 to AS 100. No oth er routes are redistributed. T o redistribute all routes 1. T o allow all routes to redistributed, click Ac cept next to All BGP AS 4 routes into AS 100 field. 2. Click Apply . Redistributing Routes to RIP and IGRP Redistributing to RIP and IGRP is controlled by any o ne of three parameters: Nokia Platform B Nokia Platform A Nokia Platform C Nokia Platform D EBGP EBGP 00339 AS100 AS200 AS4
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 441  Protocol  Interface  Gateway If more than one parameter is specified, they are processed from most general (protocol) to most specific (gateway). It is not possible to set metrics for redistributin g RIP routes into RIP or for redistributing IGRP routes into IGRP . Attempts to do this are silently ignored. It is also not possible to set the metrics for redistributing routes into IGRP . Note If no redistribution policy is specified, RIP and inte rface routes are re distributed into RIP an d IGRP , and interface routes are re distribu ted into IGRP . If any policy is specified, the defa ult s are overridden. Y ou must explicitly specif y everything that should be redistributed. RIP version 1 assumes that all subnets of the shar ed network have the same subnet mask, so they are able to propagate only subnets of that networ k. RIP version 2 removes that restriction and is capable of propagating all routes when no t sending v ersion 1-compatible updates. Redistributing RIP to OSPF Example In this example, Nok ia Platform A is connected to a RIP ne twork and is redistributing RIP routes to and from OSPF for the Nokia OSPF Backbone. Nokia Platform D is connected to a subnet of Unix workstations that is runni ng ro u t e d . Note routed is a utility that runs by default on most Unix work stations. This utility listens to RIP network updates and chooses a default route bas ed on what is advertised. This process eliminates the need for st atic routes and provides route redun dancy . Because routed does not send route updates, it is called a passive RI P listener . T his subnet (1 92.168.26.64 /28) is
9 442 Nokia Network Voyager for IPSO 4.0 Refe rence Guide categorized as a stub network, mea ning that a particular subnet do es not send RIP routing updates. T o redistribute routes from the corporate RIP network to the Nokia OSPF network through Nokia Platform A Note Make sure th at the Corporate net RIP router is advertising RIP on the interface co nnected to the Nokia networ k. It mu st be rec eiv ing and transmitting RIP updates. Nokia does not currently support the notion of trusted hosts for auth entication of RIP routes. 1. Connect to Nokia Platform A using Network V oyager . 2. Click Route Redistribution und er Configuration > Routing in the tree view . 3. Click the RIP link under the Redist ribute to OSPF External section. 4. T o redistribute all routes, click Accept in the All RIP routes into OSPF External field. (Optional) T o change the cost metric for RIP Routes into OSPF Externals, enter the new cost metric in the Metric text box, then click Apply . 00337 Nokia Platform B Nokia Platform A Nokia Platform D 26.69/30 26.66/30 Nokia Platform C 26.73/30 26.70/30 26.65/30 26.74/30 26.61/24 26.77/28 26.79/28 26.80/28 26.78/28 26.1/24 0.0.0.0/0 24.0/24 22.0/24 Nokia OSPF Backbone RIP to OSPF Border RIP Network UNIX Hosts with Routed Enabled Hub Corporate Net
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 443 5. T o prevent 192.168.22 .0/24 and other more specific routes from being red istributed into OSPF External, define a route filter to restrict only this route as follows: a. T o configure this filter , enter 192.168.22.0 in the New IP prefix to redistribute text box, and 24 in Mask length text box. Click Apply . b. Select Normal in the Match T ype drop-down lis t. This specifies to prefer routes that are equal to or more specifi c than 192.168.22.0/24. c. Click Apply . The filter is fully configured. T o redistribute routes from the Nokia OSPF network to the Corporate RIP Network. 1. Use the Network V oyager connection to No kia Platform A you previously created. 2. Click Route Redistribution und er Configuration > Routing in the tree view . 3. Click the OSPF link in the Redistribute to RIP section. 4. T o export all OSPF routes into RIP , click Accept in the All OSPF routes into RIP field; t hen click Apply . (Optional) T o change the cost metric for RIP Routes into OSPF Externals, enter the new cost metric in the Metric text box; then click Apply . 5. If you do not want to ex port all OSPF routes into RIP , click Restrict and define a route filter to advertise only certain OSPF routes into RIP . 6. Assume that Nokia Platform B has another inte rface not shown in the diagram and that it has two additional OSPF ro utes: 10.0.0.0/8 and 10.1.0.0/16 . T o exclude all routes that are strictly more specif ic than 10.0.0.0/8 ; that is, you want to propagate 10.0.0.0/ 8 itself, but you do not want to propagate the more specific ro ute. a. T o configure this filter , enter 10.0.0.0 in New IP Prefix to Import text box, and 8 in Mask length text box; Click Apply . b. Select Refines in the Match T ype drop-down list. This specifies that you want routes that are strictly more specific than 10.0.0.0/8 . c. Finally , click Restrict in the Action field. This specifies that we want to discard the routes that match this prefix. d. Click Apply . The filter is fully configured. Redistributing OSPF to BGP Example In the following example, Nokia Platform A is running OSPF and BGP and its local AS is 4.
9 444 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Nokia Platform E of AS 100 and Noki a Platform A of AS 4 are participating in an EBGP session. Nokia Platform F of AS 200 and Nokia Plat form D of AS 4 are also participating in an EBGP session. T o redistribute OSPF to BGP through Nokia Platform A 1. Click Route Redistribution und er Configuration > Routing in the tree view . 2. Click the OSPF link in the Redistribute to BGP section. 3. T o redistribute OSPF routes into peer AS 100, select 100 from the Redi stribute to Peer AS drop-down list, then click Apply . 4. (Optional) Enter the MED in the MED text b ox; then click Apply . 5. (Optional) Enter the local preference in the LocalPref text box, then click Apply . 6. T o redistribute OSPF routes, enter the IP prefix in the New IP Prefix to Redistribute text box and the mask length in Mask Leng th text box; then click Apply . Redistributing Routes with OSPF It is not possible to create OSPF intra-area or inter-area routes by redistributing routes from the IPSRD routing table into OSPF . It is possible to redistribute from the IPSRD routing table only into OSPF ASE routes. In addition, it is not po ssible to control the pr opagation of OSPF routes within the OSPF protocol. There are two types of OSPF ASE routes:  Ty p e 1  Ty p e 2 See the OSPF protocol configuration for a detailed explanatio n of the two types. 00338 Nokia Platform B Nokia Platform A Nokia Platform D Nokia Platform E 26.69/30 26.66/30 Nokia Platform C 26.73/30 26.70/30 26.65/30 26.74/30 26.61/24 26.1/24 26.77/28 Nokia OSPF Backbone AS4 AS100 Nokia Platform F 26.77/28 AS200 EBGP EBGP
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 445 Inbound Route Filters Inbound route filters allow a network administrato r to restrict or constrain the set of routes accepted by a given routing protocol. The filters let an operator include or exclude ranges of prefixes from the routes that ar e accepted into RIP , IGRP , OS PF and BGP . These filters are configured in the same way as the filters for route redistributi on. Note Y ou can also use route map s to specify inbound ro ute filters. Y ou can define route map s only using CLI commands. For informatio n on route maps, see “Route Maps” on pag e 353 and the CLI Reference Guide . An administrator can specify two possible actio ns for each prefix—accept the address into the routing protocol (with a specified rank) or exclude the prefix . Y ou can specify the type of prefix matching done for filter entries in the following ways:  Routes that exactly match the given prefix; that is, have the same network portion and prefix length.  Routes that match more specific pre fixes but do not include the given prefix. For example, if the filter is 10/8, then any netw ork 10 route with a prefix length greater than 8 matches, but those with a prefix leng th of 8 do not match.  Routes that match more specif ic prefixes and include the given prefix. For example, if the filter is 10/8, then any network 10 route with a prefix length greate r than or equal to 8 matches.  Routes that match a gi ven prefix with a pref ix length between a gi ven range of prefix lengths. For example, the filter could specify that it match any route in network 10 with a prefix length between 8 and 16. T o configure IGP inbound filters 1. Click Inbound Route Fi lters under Configuration > Routing in the tree view . 2. Click Filter Inbound RIP Routes. Note All other IGPs are configured in exactly the same way . 3. In the All Routes Action field, click either Accept or Restrict. If you select accept, routes can be rejec t ed in dividually by entering their IP address and mask length in the appropriate fields. Similarly , if you select RESTRICT , routes can be accepted individually by entering their IP address and mask le ngth in the appropriate fields. 4. If you set All Routes to acc ept and click Apply , the Rank field is displayed . In the Rank field you can specify the rank to a value that all routes sh ould have. The range of values is 1 to 255.
9 446 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. Enter the appropriate IP addre ss and mask length in the Ne w Route to Fil ter and Mask Length fields; then click Apply . A new set of fields is displayed adjacent to the newly entered IP address and mask length. 6. Click On or Of f to enable or disable filtering of this route. 7. From the Match T ype field drop-down list, select Normal, Exact, Refines, or Range . 8. In the Action field, click Accept or Restrict to determine what to do with the routes that match the given filter . 9. In the Rank field, enter the approp riate value, and then click Apply . 10. If this completes your actions for this route filtering option, click Save. 11 . If this does not complete your actions for this route filtering option, begin again at step 3. BGP Route Inbound Policy Example Y ou can selectively accept routes from different BG P peers based on a peer auto nomous system or an AS path regular expression. T o configure route inbound policy on Nokia Platform D based on an autonomous system number 1. Click Inbound Route Fi lters under Configuration > Routing in the tree view . 2. Click the Based on Autonomous Sy stem Number link. 3. Enter 512 in the Import ID edit box. Import ID specifies the order in which the impo rt lists are applied to each route. The range for filters based on AS nu mbers is from 512 to 1024. 4. Enter 100 in the AS text box; then click Apply . This is the AS number from wh ich routes are to be filtered. 5. (Optional) Enter more values in the Import ID and AS text boxes to configure more inboun d policies based on autonomous syst em numbers; then click Apply . Nokia Platform B Nokia Platform A Nokia Platform C Nokia Platform D EBGP EBGP 00339 AS100 AS200 AS4
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 447 Note By default, all routes originating from the configur es ASes are accepted. Y ou can accept or reject all routes from a particul ar AS by enabling the accept or restrict option next to the All BGP routes from AS field. 1. Y ou also can accept or reject particular routes from AS 100 by specifying a route filter . Route filters are specified as shown in the Route Redistribution section. Assume that you want to filter all routes that ar e strictly more specific than 10.0.0.0/8 . In other words, allow all routes whose prefix is not 10.0.0.0/8 except for 10.0.0.0/8 itself, but exclude all routes that are more specific, such as 10.0.0.0/9 and 10.128.0.0/9 . 2. T o configure this filter , enter 10.0.0.0 in New IP prefix to import te xt box, and 8 in Mask Length text box; click Apply . 3. Select Refines in the Match type dr op-down list. This specifies routes that are strictly more specific than 10.0.0.0/8 . 4. Finally , click Restrict in the Action field. This specifies discard the routes that match this prefix. 5. Click Apply . The filter is fully configured. T o configure route inbound policy on Nokia Platform D based on ASP A TH regular expressions 1. Click Inbound Route Fi lters under Configuration > Routing in the tree view . 2. Click the Based on ASP A TH Regular Expressions link. 3. Enter 500 in the Import ID edit box. The import ID specifies the order in which the import lists are applied to each route. For route filters based on AS path regular expressions, the range of values is from 1 to 51 1. 4. Enter a regular expression that identifies a se t of ASes that should be matched with the SP A TH sequence of the route: 100|200 This sequence accepts all routes whose ASP A TH sequence contains 100 or 200 or both. 5. Select one of the origin options from th e Origin drop-down list; then click Apply . These options detail the completeness of AS pa th information. An origin of IGP indicates that an interi or routing protocol-learned route was learned from an interior routing protocol and is most likely complete. An origin of EGP indicates the route was learne d from an exterior routing protocol tha t does not suppo rt AS paths, and the path is most likely incomplete. When the path info rmation is incomplete, an orig in of incomplete is used. 6. Enter a new route filter . In th is example assume that you want to filter all routes that are strictly more specific than 10.0.0.0/8 . In other words, allow all routes whose prefix is not 10.0.0.0/8 except for 10.0.0.0/8 itself, but exclude all routes that are more specific, such as 10.0.0.0/9 and 10.128.0.0/9 .
9 448 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 7. T o configure this filter , enter 10.0.0.0 in New IP prefix to impo rt edit box, and 8 in Mask length edit box; then click Apply . 8. Select Refines in the Match type drop-down list. This specifies routes that are stric tly more specific than 10.0.0.0/8. 9. Finally , click Restrict in the Action field. This specifies to discard the ro utes that match this prefix. 10. Click Apply . The filter is fully configured. BGP AS Path Filtering Example BGP updates restrict the routes a router learns or advertises. Y ou can filter these updates based on ASP A TH regular expression s, ne ig hbors (AS numbers), or community IDs. T o filter BGP updates based on AS P A TH regular ex pressions, see “T o configure route inbound policy on Nokia Platf orm D based on ASP A TH regular expressions.” The following examples, however , give a more detailed description of how to create ASP A TH regular expressions. ASP A TH Regular Expressions 1. T o accept routes that transit through AS 3662, enter the following ASP A TH regular expression in the ASP A TH Regular Exp r ess ion text box: (.* 3662 .*) Select Any from the Origin drop-down list; then click Apply . 2. T o accept routes whose last autonomous syst em is 3662, enter th is ASP A TH regular expression in the ASP A TH Regular Express ion text box: (.* 3662) Select Any from the Origin drop-down list; then click Apply . 3. T o accept routes that originated from 2041 and wh ose last autonomous system is 701, enter the following ASP A TH regular expression in the ASP A TH Regular Expression text box: 2041 701 Select Any from the Origin drop-down list; then click Apply . 4. T o accept SPRINT (AS number 1239) routes th at transit through A T&T (AS number 7018) or InternetMCI (AS number 35 61 ), enter the following ASP A TH regular expression in the ASP A TH Regular Expression text box: (1239 .* 7018 .*) | (1239 .* 3561 .*) Select Any from the Origin drop-down wind ow . 5. Apply . 6. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Guide 449 10 Configuring T raf fic Management This chapter describes traffic management fu nctionality , including a ccess control lists and aggregation classes. T raffic Management Overview T raf fic management functionality allows packet st reams to be filtered, sh aped, or prioritized. The prioritization mechan isms conform to RFC 2598, th e Expedited Forwarding specification of the IETF Diff Serv W orking Group. T raffic is separated into discrete streams, or cl assified, through an Access Control List (ACL). T raf fic is metered to conform to throughput goals with an Aggregation Class (AGC). The combination of these control bloc ks form the basis of the filteri ng, shaping, and prioritization tools. A queue class is used to implement an output scheduling discipline to prioritize traf fic. Logically , the ACLs and the AGCs are placed inlin e to the forwarding path. Y ou can con f ig ure ACLs and AGCs to process all incoming traffic from one or more interfaces, or to process all outgoing traffic from one or more interfaces. IPSO supports Access Control Lists for both IPv4 and IPv6 traffic. Packet Filtering Description T raffic that is classified can be filtered immediately . The actions for filtering are:  Accept—The accept action forwards the traffic.  Drop—The drop action drop s the traffic without any notification.  Reject—The reject action drops the traffic and sends an ICMP error message to the source. For information on ho w to configure a packet filter , see “Configuring ACL Rules” on page 452 . T raffic Shaping Description T raffic that is classified can be shaped to a m ean rate. The shaper is implemented using a token bucket algorithm; this means that you can conf igure a burstsize from whic h bursts can "borrow ." Measured over longer time intervals, the traffic will be coerced to the configured mean rate. Over shorter intervals, traffic is allowed to burs t to higher rates. This coercion is accomplished
10 450 Nokia Network Voyager for IPSO 4.0 Refe rence Guide by adding delay to packe ts th at must wait for more tokens to arrive in th e bucket. When more bursts arrive than can b e accommodate d by the shap ing queue, then that traff ic i s dropped. Both outgoing and inc oming traf fic streams can be shaped. T o configure a shaper , see “Configuring ACL Rules” on page 452 . Select shape as the action for one or more rules. See “T o create an Aggregation Class” on page 456 for information about creating AGC mete rs. Y ou should associate th e AGC with the shaping rule(s) of the ACL. T raffic Queuing Description T raffic that is classified by an Access Contro l List (ACL) rule can be given preferential treatment according to RFC 2598 . Higher-priority tr af fic must be policed to prevent starvation of lower-priority service t r affic. T raf fic that conforms to the configured policing rate is marked with the Differentiated Services Codepoint (D SCP). When such traffic is processed by the output queue scheduler , it receiv es favorable priority treatment. Some traffi c is generated by networking protocols. This traf fic should be given the hi ghest queuing priority; otherwise, th e link may become unstable. For this reason, the Queue Class (QC) configuration provides an internetwork control queue by default; some locally sourced traffic is prioritized to use that queue. Prioritization is only relevant for outgoing tr af fic. Incoming traffic is never prioritized. Use the DSfield in the Access Control List (ACL ) to set the value for marking traf fic that matches a given ACL rule. The QueueSpec is us ed to map a flow with the output queue. T o configure EF , see “Configuring ACL Rules” on page 452 for information about creating ACL rules. Choose prioritize as the ac tion for one or more rules. Enter the appropriate values in the DSfield and QueueSpe c edit boxe s. See “T o create an Aggregation Class ” for information about creating Aggregation Class meters. Y ou should associate the AGC w ith the prioritize rule(s) of the ACL. Configuring Access Control List s T o set up an Access Control List (ACL), you must configure the interface(s) with which you want to associate the ACL and the Bypass option. T o configure an interface, see “T o app ly or remove an ACL to or from an interface” . The Bypass option denotes that th e entire packet stream flowing out of the selected interface s should not be classified, policed, or marked. Instead, the output queue scheduler should use the supplied IP TOS as an output queue lookup. Use the Bypass option to circumvent the classifier and policer for selected interfaces.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 451 T o create or delete an ACL 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, c lick Access List under Conf iguration > T raf fic Management in the tree view . b. For IPv6 ACLs, click IPv6 Access List under Configuration > IPv6 Configuration > Traf fic Management in the tree view . 2. T o create an ACL, enter a name for the ACL in the Create a New Access List edit box and click Apply . The Access Control List name, Delete check box, and Bypass this Access List field appear . 3. T o delete an ACL, select Delete next to the Access Control List you want to delete and click Apply . The Access Control List name disappears from the Ac ces s List Configuration page. 4. Click Save to make your changes permanent. T o apply or remove an ACL to or from an interface 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, c lick Access List under Conf iguration > T raf fic Management in the tree view . b. For IPv6 ACLs, click IPv6 Access List under Configuration > IPv6 Configuration > Traf fic Management in the tree view . 2. Click the link for the appropriate ACL in the ACL Name field. The page for that ACL appears. 3. T o apply an interface to the ACL: a. Select the appropriate interface from the Add Interfaces dro p-down window . b. Select either Input or Output from the Di rection drop-down window . Y ou can apply to an interface the same dire ction to both an IPv4 and an IPv6 ACL. However , you cannot apply to an interface th e same direction to more than one IPv4 ACL, or to more than one IPv6 ACL. Selecting the "input" direction for a ACL with a rule whose action is set to "prioritize" is equivalent to setting the action to "skip." Note Only the default rule appears in the Access Control List until you create your own rule. c. Click Apply . The new interface appears in the Selected Interfaces section.
10 452 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 4. T o remove an ACL from an interface: a. Select Delete for the appropriate inte rface in the Selected Interfaces table b. Click Apply . The interface disappears from th e Selected Interfaces section. 5. T o make your changes permanent, click Save. Configuring ACL Rules An Access Control List (ACL) is a container for a set of rules, and traffic is separated in to packet streams by the ACL. The content and ordering of th e rules is critical. As packets are passed to an ACL, the packet headers are compared against data in the rule in a top-down fashion. When a match is found, the action associated with that ru le is taken, with no further scanning done for that packet. The following actions can be associa ted with a rule that is configured to perform packet filtering:  Accept  Drop  Reject The following addit i on al ac tio ns can also be associated with a rule:  Skip—skip this rule and proceed to the next rule  Prioritize—give this traffic stream preferential scheduling on output  Shape—coerc e this traf fic’ s th roughput accordin g to the set of parameters given by an aggregation class Y ou can configure an access list to control the traffic from one or more interfaces and each access list can be associated with incoming or outg oing traffic from each interface. However , the prioritize action is only exec uted on outgoing traf fic. Rules can be set up to ma tch any of these properties:  IP source address  IP destination address  IP protocol  UDP/TCP source port  UDP/TCP destination port  TCP establishment flags—When selected, traffic matches this rule when it is part of the initial TCP handshake.  T ype of Service (T OS) for IPv4; T raffic Class for IPv6 The following values can be used to mark traffic:  DiffServ codepoint (DSfield)  Queue Specifier (QueueSpec)
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 453 Note The DSfield and QueueSpec field are used to mar k and select the priority level. Masks can be applied to most of these prop erties to allow wildca rding. The so urce and destination po rt properties can be edite d only when the IP pro tocol is UDP , TCP , or th e keyword "any ." All of these properties are used to match traf fic. The packets that match a rule whose action is set to "prioritize" are marked with the correspon ding DSfield and sent to the queu e set by QueueSpec field. The DSfield an d QueueSpec field can only be ed ited when the Action field is set to "prioritize." T o add a new rule to an ACL 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, c lick Access List under Conf iguration > T raf fic Management in the tree view . b. For IPv6 ACLs, click IPv6 Access List under Configuration > IPv6 Configuration > Traf fic Management in the tree view . 2. Click the link for the appropriate Access Control List in the ACL Name field. The page for that ACL appears. 3. Click the Add New Rule Before check box. 4. Click Apply . This rule appears above the default rule. As you create more rules, you can add rules be fore other rules. If you have four rules—rules 1,2,3, and 4—you ca n place a new rule betw een rules 2 and 3 by checking the Add Rule Before check box on rule 3. 5. T o make your changes permanent, click Save. Modifying a Rule Rules provide filtering criteria fo r an access list. Y ou can add a new rule, modify a rule, or delete an existing rule in this list. When a packet matches a rule, the rule is execute d immediately and no fu rther rule scanning is done thus rule ordering is very important. If th e packet matches no user -defined rule, then the action specified by the final default rule will be taken. T o modify a rule, navigate to the page for th e ACL that co ntains the rule, as described in “T o add a new rule to an ACL.” Ta b l e 2 7 de scribes the attributes of an ACL rule that you can modify . T o delete a rule, select the delete check box for that rule and click Apply .
10 454 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T able 27 ACL Rule Attributes Attribute Description Action A rule action can be one of the follo wing six actions: • Accept—Forward this traffic stream. • Drop—Silently drop all traffic belonging to this stream. • Reject—Drop all traffic in this stream and atte mpt to deliver an ICMP error to the so urce. • Skip—Skip thi s rule proceed to ne xt. • Shape—Coerce th e throughput of this traffic according to a set of p arameters given by an aggregation class. • Prioritize—Give this traffic stream preferent ial schedu ling on output. When you configure an ACL rule to use the prioritize action , you must configure an Aggregation Class (AGC). Aggregation Class T his link takes you to the T raffic Condition Configuration page, where you can view and modify existing rate shaping aggregation class con fig uration s on the system. It also allows you to add new aggregation classes or to delete existing aggreg ation classes from the system. Source IP Address Specifies the source IP address to be used for matching this rule. Source Mask Length Specifies the source filter mask length to be used for matching this rule. Destination IP Address Sp ecifies the destination IP address to be used for matching this rule. Destination Mask Length Specifies the destination filter mask length to be used for matching this rule. Source Port Range Specifies th e so urce port range to be used for matching this rule. Y o u can specify the Source Port Range only if t he selected protocol is either “any ,” 6, TCP , 17, or UDP . Destination Port Range Specifies the destination port range t o be used for matching this rule. Y ou can specify the Destination Port Range only if the selected protocol is ei th er "any ," 6, TCP , 17, or UDP . Protocol Specifies the IP protocol to be used for matching this rule. Range: 0-255 or any Default: Any TCP-Establishment flag When it is selected, tra ffic matches this rule w hen it is part of the i nitial TCP handshake. This option applies only to IPv4 ACLs. Y ou can specify the TCP Establishment flag only if the selected protocol is TCP , 6, or "any ." T ype of Service (TOS) for IPv4 T raffic Class for IPv6 Specifies the type of service to be used for matching this rule. Range: any or 0x0-0xff Default: Any
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 455 Configuring Aggregation Classes An Aggregation Class (AGC) is used to determ ine whether the traffic stream meets certain throughput goals. T raffic that meets these goals is conformant; traf fic that does not meet these goals is non-conformant. Depending on the config uration of the classifier rules, non-conformant traffic may be delayed, policed, that is dropped, or marked. An Aggreg ation Class groups traf fic from distinct rules and measure s its th roughput. Y ou can configure an Aggregation Class with two parameters: Mean Rate —The rate, in kilobi ts per second (kbps), to which the traf fic rate should be coerced when measured over a long interval. Burst Size —The maximum number of bytes that can be transmitted over a short interval. When you initially create an AGC, a burst of traf fic is conformant—regardless of how quickly it arrives—until the size of the burst (in bytes) is equal to or larger than the burstsize you configured for the AGC. When the burst reaches the configured burstsize, traffic is non- conformant, but the AGC increa ses the rate at which traffic is transmitted based on the configured meanrate. T raffic that arrives consis tently at a rate less than or equal to the configured meanrate will always be marked conformant and will not be delayed or dropped in the respective shaper or policer stages. DSfield Specifies the DiffServ codepoint with which to mark traffic which matches this rule. RFC 791 states that the l east significant two bi ts of the DiffServ codepoint are unused. Thus, the least significant two bits for any value of the DSfield that you en ter in the ACL rule will be reset to 0. For example, if you enter 0xA3, it will be reset to 0xA0 and the corresponding packets will be marked as 0xA0 and not 0xA3. The DSfield and QueueSpec field can be configure d only whe n the rule’s action is set to "prioritize." Logical Queue Specifier (QueueSpec) Specifies the logical queue specifie r value to be used by the output scheduler fo r traffic matching this rule. Range: None or 0-7 Default: None The DSfield and QueueSpec field can be configure d only whe n the rule’s action is set to "prioritize." When the DSfield is set to one of the pre defin ed code points, for ex ample, Internetwork Control, EF , or best effort, then the QueueSpec field is not used. Aggregation Class See “T o associate an aggregation class with a rule” on page 456 . T able 27 ACL Rule Attributes Attribute Description
10 456 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o create an Aggregation Class 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, click Aggregation Class unde r Configuration > Traf fic Management in the tree view . b. For IPv6 ACLs, click IPv6 Aggregation Class under Configuration > IPv6 Configuration > Traf fic Management in the tree view . 2. Enter the following in the Create a New Aggregation Class section:  A name for the aggregation class in the Name edit box.  Bandwidth in the Mean Rate (kbps) edit box.  Burst size in the Burst Size (bytes) edit box. 3. Click Apply . The aggregation class you have just created appears in the Existing Aggregation Classes table. 4. Click Save to make your changes pe rmanent. T o delete an aggregation class, select the Delete check box next to the aggregation c lass that you want to delete and click Apply . This aggregation class disappears from the Existing Aggregation Classes section. T o associate an aggregation class with a rule 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, c lick Access List under Conf iguration > T raf fic Management in the tree view . b. For IPv6 ACLs, click IPv6 Access List under Configuration > IPv6 Configuration > Traf fic Management in the tree view . 2. Click the link for the appropriate Access Control List in the ACL Name field. The page for that Access Control List appears. 3. Select Shape or Prioritize from the Actio n drop-down window . 4. Click Apply . A drop-down list appears in the Aggregation Class field. 5. Select an existing aggregation class fro m the Aggregation Class drop-down list. Note If there is no aggregation class listed, you need to create an aggregation class. Go to “T o create an Aggr egation Class.”
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 457 Note A rule treats traffic as if it were configur ed for "skip, " if the traffic matches a rule whose action has been set to "prioritize" or "sh ape " and no Aggregation Class is configured. 6. Click Apply . 7. Click Save to make your changes permanent. Configuring Queue Classes Queue classes are used to instan tiate a framework, or template, fo r output queue schedulers. Like Access Control Lists (ACLs) they are created an d configured and then assoc iated with an interface. There are a maximum of 8 priority-level queues for a que ue class. Y ou can configure the size (in packets) of each queue level as well as the queue sp ecifier . The queue specifier is a tag assigned by the classifier and is used as a key to look up the proper queue level. Three queue levels are pre-defined: the Internetwork Control (IC), Expedited Forwarding (EF), and Best Ef fort (BE) queues. Y ou can assign the remaining queues any name and QueueSpec you want. The table below shows the values that correspond to these queue value s: When you configure an ACL rule to use the priority action, you must co nfigure an aggregation class. This aggregation class functions as a policer , that is, non-conforming traf fic will be dropped. Y ou should configure the aggregation classes so that the aggregate of the NC and EF flows consumes no mo re than 50% of the output link bandwidth. This action pr events lower- priority traffic from being starved. See RFC 25 98 for more information. The other policers should also be configured to prevent th e lower -priority queue from being starved. Internetwork control traffic, such as routing m essages and keepalives, shou ld be configured to use the internetwork control queue so th at it receives precede nce over regular IP traffic. Note that locally originated internetwork control traf fic is automatically sent through this queue. See RFC 791 for more info rmation about Internetwork Control traf fic. A queue class can be configured to maximize device throughput or to minimize p rioritized traffic latency . The QoS functionality is not ac hieved w ithout a cost. The choice of QoS with minimal latency is the most costly in terms of forwarding performance, bu t it allows the least amount of head-of-line blockin g for high priority traf fic. Name of Queue Level Priority IET F DiffServ Codep oint Queue Specifier V alue Internetwork Control 0 0xc0 7 Expedited Forwarding 1 0xb8 6 Best Effort 7 0 0
10 458 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o create or delete a queue class 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, click Queue Class unde r Configuration > T raffic Management in the tree view . b. For IPv6 ACLs, click IPv6 Queue Class under Configurati on > IPv6 Configuration > Traf fic Management in the tree view . 2. T o create a new queue class, enter its name in the Create a New Queue Class edit box and click Apply . The new queue class appears in the Existing Queue Classes field. 3. T o delete an existing queue class, select the Delete c heck box in the Existing Queue Classes table for the Queue class you wa nt to delete and click Apply . The queue class disappears from the Existing Queue Classes field. 4. Click Save to make your change perman en t. T o set or modify queue class configuration values 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, click Queue Class unde r Configuration > T raffic Management in the tree view . b. For IPv6 ACLs, click IPv6 Queue Class under Configurati on > IPv6 Configuration > Traf fic Management in the tree view . 2. In the Existing Queue Class table, click the na me of queue class yo u want to configure. The configuration page for that queue class ap pears, listing the queues in the queue class. Each queue class can have up to eight queu es. Three queues are reser ved for Internetwork Control, Expedited Forwarding, and Best Ef fort traffic. 3. For each queue you want to co nfigure, enter the following: a. Logical Name —This name appears on the queue monitoring page. Choose a name (with no spa ces) that will allow you to identify the queue’ s purpose. b. Queue Specifier —An integer used to address each queue you configure within a queue class. c. Max Queue Length —V alue for the maximum number of packets that can be queued before packets are dropped. Enter a value of zero (0) to disable a queue. Neither the Internetwork Control nor the Best Effort qu eu e can be disabled. 4. Click Apply 5. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 459 T o associate a queue class with an interface 1. Depending on whether you are usin g IPv4 or IPv6, click the following link. a. For IPv4 ACLs, click Queue Class under Co nfiguration > T raffic Management in the tree view . b. For IPv6 ACLs, click IPv6 Queue Class under Configuration > IPv6 Configuration > Traf fic Management in the tree view . 2. In the List of A vailable Physical Interfaces ta ble, click the name physical interface wi th which you wish to associate a queue class. The physical interface page for the interface you selected appears. 3. T o enable QoS queuing, select either Max Throug hput or Min QoS Latency from the Queu e Mode drop-down list. 4. Click Apply . A drop-down list appears in the Queue Class field. 5. Select the queue class you want to associate with the interfa ce from the Queue Clas s drop- down list. If you do not select a queue class , the default class is use d. The default queue class has two queues, Internetwork Control and Best Ef fort. 6. Click Apply . 7. Click Save to make your changes permanent. Configuring A TM QoS A TM networks can provide dif ferent quality of se rvice for network applications with different requirements. Unspecified Bit Rate (UBR) service does not make any traffic related guarante es. It does not make any commitment regarding cell loss rate or cell transfer delay . Constant Bit Rate (CBR) service provides continuo usly available bandwidth with guaranteed QoS. The IPSO implementati on supports CBR channels through a mechanism on an A TM network interface card (NIC) that limits the cell rate for each virtua l channel you configure. The CBR feature limits the peak cell rate for each CBR ch annel in the output direction only . Each A TM port supports up to 100 CBR channels w ith 64 kbits/sec of bandwidth resolution. Create a QoS descriptor 1. Click A TM QoS Descriptor under Configuration > Traf fic Management in the tree view . 2. T o create an A TM QoS Descriptor , enter its name in the Create a New A TM QoS Descriptor edit box. The category for any new A TM QoS Descriptor that you configure is set to constant bit rate (CBR). CBR limits the maximum cell output ra te to adhere to the requirements on CBR traffic imposed by the network.
10 460 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note The default A TM QoS Descriptor is set to unspecified bit rate (UBR) and cannot be modified. 3. Enter a value for the maximum ce ll rate to be used in the output direction on a CBR channel in the Peak Cell Rate edit box. The Peak Cell Rate is rounde d down to a multiple of 64 k ilobits/sec. One cell per second corresponds to 424 bits/sec. Note Y ou can configure no more than 100 CBR chann els per inter face. The sum of the Peak Cell Rate of all the CBR channels on an interface ca nnot exceed 146Mbs. 4. Click Apply . The new A TM QoS Descriptor appea r s in the Existing A TM QoS Descriptors table. 5. Click Save to make your changes pe rmanent. T o delete an A TM QoS descriptor 1. Click A TM QoS Descriptor under Configuration > Traf fic Management in the tre e view . 2. Select the Delete check box next to the name of the A TM QoS Descriptor that you want to delete. Note Y ou can delete an existing A TM QoS Descripto r only after you diss ociate it from an existing permanent virtual chan ne l (PVC). See the steps below . 3. Click Apply . The A TM QoS Descriptor disa ppears from the Existing QoS Descriptors field. 4. Click Save to make your changes pe rmanent. T o dissociate an A TM QoS Descriptor from an existing P VC 1. Click Interfaces under Configuration > In terface Configuration in the tree view . 2. Click the appropriate A TM interface link in the Physical field. The physical interface page for the interface you selected appears. 3. Click the A TM QoS Configuration link. Y ou ar e now in the A TM QoS Configuration page for the physical interface you selecte d. In th e Qo S Configured PVCs field, click th e QoS Descriptor drop-down window an d select Default (UBR). 4. Click Apply . 5. Click Save to make your changes pe rmanent.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 461 6. Click the A TM QoS Descriptors link. 7. In the Existing A TM QoS Descriptors field, clic k the Delete check box next to the name of the A TM QoS Descriptor that you want to delete. 8. Click Apply . The A TM QoS Descriptor disa ppears from the Existing QoS Descriptors field. 9. Click Save to make your changes permanent. T o associate an A TM QoS Descriptor with an interfa ce and a virtual channel 1. Click Interfaces under Configuration > In terface Configuration in the tree view . 2. Click the appropriate interfa ce link in Physical field. The physical interface page for the interface you selected appears. 3. Click the A TM QoS Configuration link. The A TM QoS Configuration page for the physical interfa ce you selec ted appears. 4. Under Configure a New PVC in the VPI/VCI ed it box, enter the virtual path identifier/ virtual channel identifier (VPI/VCI) of the pe rmanent virtual channel (PVC) you wa nt to configure. 5. Under Configure a New PVC field, click the QoS Descriptor drop-down list and sele ct the QoS descriptor with which you want to associate the PVC you configured. Note Y ou cannot delete or mo dify a QoS Descriptor that ha s been associated with a permanent virtual chan nel (PVC). Y ou must first disassociate the PVC from the QoS descriptor . See “T o delete an A TM QoS descriptor” for more information. Note Y ou can change the QoS configuration of a PV C while it is being used. However , doing so results in a short br eak in traffic because the PVC is closed while QoS configuration values change . Afte rw ar d, the system reopens the PVC. 6. Click Apply . The name of the new PVC and A TM QoS Descr iptor with which you associated the PVC appear in QoS Configure d PVCs field. 7. Click Save to make your changes permanent. Configuring Common Open Policy Server The Common Open Poli cy Server (COPS) provides a standard for exchanging po licy information in order to support dy namic Quality of Service (QoS) in an IP (Internet Protocol) network. This information is exchanged between PDPs (Po licy Decision Poi nts) and PEPs
10 462 Nokia Network Voyager for IPSO 4.0 Refe rence Guide (Policy Enforcement Points). Th e PDPs are network-based servers that decide which types of traffic (such as voice or video) receive priority treatment. The PEPs are routers that implement the decisions made by the PDPs. In the Nokia im plementation, the Nokia platform functions as a PEP . Configuring a COPS Client ID and Policy Decision Point Y ou must configure at least one COPS Client ID and a corresponding policy dec ision point, that is, policy server , fo r the COPS Policy Module to function. 1. Click COPS under Configuration > T r affic Management in the tree view . 2. In the Configured COPS Modules section click the Diffserv PIB link. The COPS Diffserv specific configuration page appears. 3. In Diffserv PIB specific configuration section, enter the name of the new client ID. Click Apply . T o view the new client ID, click on the Client ID drop-down window . The name of the new COPS client appears in a Client ID list in the COPS Security configuration section. Note Y ou can configure multiple clie nt IDs. Only one client ID can be active at a time. 4. T o configure a COPS client, click on the Client ID drop-down list and select a client name. Click Apply . 5. Enter either the IP address or domain name th e server to act as the Policy Decision Point (PDP) in the Primary PDP edit box. 6. (Optional) Enter the IP address or domain name of the server to act as the se condary Polic y Decision Point (PDP) in th e Secondary PDP edit box. 7. Click Apply . 8. Click Save to make your changes pe rmanent. Configuring Security Parameters for a COPS Client ID The Nokia implementation lets yo u configure send and receive key IDs for eac h COPS Client ID to authenticate sessions with the PDP , or policy server . 1. Click COPS under Configuration > T r affic Management in the tree view . 2. In the Configured COPS Modules section click the Diffserv PIB link. The COPS Diffserv specific configuration page appears. 3. In the COPS security configuration section, click on the link for the name of the COPS Client ID for which you want to configur e security . This action takes you to the COPS Security Configuration page for that client.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 463 4. In the Sequence Number edit box, enter a valu e between 1 and 21474 83647 to define the sequence number us ed for the COPS protocol. Click Appl y . 5. In the Key ID field, enter a va lue between 1 and 2147483647 in the Send edit box to define the send key ID used for the CO PS protocol. 6. In the Key field, enter a string value of up to 64 characters in the edit box next to the Send Key ID value. This value defin es th e key used for the COPS protoc ol. Use alphanumeric characters only . Click Apply . 7. In Key ID field, enter a value between 1 and 2 147483647 in t he Recv edit box to define the receive key ID used for the COPS protocol. 8. In the Key field, enter a string value of up to 64 characters in the edit box next to the Recv Key ID value. This value defin es th e key used for the COPS protoc ol. Use alphanumeric characters only . Note Y ou can configure up to 5 receive key IDs. 9. Click Apply . 10. Click Save to make your changes permanent. Assigning Roles to Specific Interfaces The Nokia COPS implementatio n lets you assign roles to specific interfaces. A role refers to a logical name assigned to a gro up of objects within a network. The role name lets you g roup objects to which you want to assign a particular policy . Y ou can also assign a combination of roles to a particular logical interface. Y ou then apply policies to role(s) and not just to a si ngle object. 1. Click COPS under Configuration > T r affic Management in the tree view . 2. In the Interface Role Combinations section, enter the name for a role in the edit box next to the appropriate logical interface name. The role name can be up to 31 ch arac ters long. Use alphanumeric characters, the period, hyphen or undersco re symbols only . Do not be gin a role name with the underscore symbol. 3. Click Apply . Note Y ou can assign multiple roles to each interfac e. Y ou can also assign different roles to diff erent interfaces on the same system. 4. Click Save to make your changes permanent.
10 464 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Activating and Deactivating the COPS Client Y ou must activate the COPS client to impl ement the COPS module yo u configure. Y ou can deactivate the COPS client to ha lt the COPS module implementation. 1. Click COPS under Configuration > T r affic Management in the tree view . 2. Click the S tart button in the COPS client field to activate the COPS client; click the S top button to deactivate the COPS client. 3. Click Apply . 4. Click Save make your chan ge permanent. When you deactivate the COPS client, you can maintain any existin g modu le and role configuration. This configur ation remains available if yo u reactivate the COPS client. Changing the Client ID Associated with Specific Diffserv Configuration Y ou can change a client ID on a running system. T ypically , each client ID refers to a specific policy or set of policies. 1. Click COPS under Configuration > T r affic Management in the tree view . 2. Click the Diffserv P IB link in the Configured COPS Module section. This action takes you to the COPS Diffserv specific configuration page. 3. In the Diffserv PIB specific configuration sec tion, click the Client ID drop-down window and select the cl ie nt ID name you now want to run. Click Apply . The name of the clie nt ID you selected now appears in the Client ID field. Note A list of all existing Client IDs appears in the COPS Security configuration section. 4. Click Save to make your change perman en t. Deleting a Client ID Before you delete a Client ID, make sure that it is not active. Perform the following steps to deactivate a client ID before you delete it. T o disable and delete a Client ID 1. Click COPS under Configuration > T r affic Management in the tree view . 2. Click the Diffserv P IB link in the Configured COPS Module section. The COPS Diffserv specific configuration page appears. 3. T o disable the Client ID, click the Client ID drop-down list in the DiffServ PIB specific configuration section and select either an other existing client ID name or none.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 465 4. In the COPS security configuration section, clic k the Delete check box next to the name o f the client ID you want to delet e. 5. Click Apply . 6. Click Save to make your change permanent. Example: Rate Shaping The following example shows you ho w to limit ftp data traffic to 100 kilobits per second (kbps) with a 5000 by te burstsize on output interface eth-s2p 1c0. First , you create an Access Control List. 1. Click Access List under Configuration > T raffic Management in the tree view . 2. T o create the Access Control List, enter its name in the Create a New Access List edit box. 3. Click Apply . 4. Click the Add Rule Before check box next to the last rule. 5. Click Apply . 6. Enter tcp in the Protocol edit box and enter 20 in both the Source or Destination Port Range edit box. 7. Click Apply . 8. Select Shape from the Action drop-down wind ow . 9. Click Apply . Second , you crea te an Aggregation Class. 1. Click on the Aggregation Class Configuration link on the Access Control List Configuration page. 2. Enter the name of the new Aggregation Class in the Name edit box in the Create a New Aggregation Class section. 3. Click Apply , and then click Save to make your chan ge permanent. 4. Enter 100 in the Mean rate (Kbps) edit box. 5. Enter 5000 in t he Burs tsize (bytes) edit box. 6. Click Apply , and then click Save to make your changes permanen t. Third , you associate the Aggregation Class with th e rule you set when you created the Access Control List. 1. Click on the Access List Configuration link on the Aggregation Class Configuration page. 2. For the rule you set u p when you created th e Access Control List, selec t the aggregation class you created from the Aggreg ation Class drop-d own window . 3. Click Apply . 4. Select eth-s2p1c0 from the Add Interfaces dr op-down window , and select Output from the Direction drop-down window .
10 466 Nokia Network Voyager for IPSO 4.0 Refe rence Guide 5. Click Apply . 6. Click Save to make your changes pe rmanent. Example: Expedited Forwarding This example illustrates the combined use of the Access Control List, T raffic Conditioning, and Queuing features. This example demonstrates how to improve the response time to T elnet s essions between client and server systems over a private W AN connec ti on within a corporate intranet as shown in the diagram below . The W A N interfaces for Network Application Platform (Nokia Platform) A and for Network Application Platform (Nokia Platform) B are ser-s3p1. The followin g configuration is done both on Nokia Platfo rm A and Nokia Platform B. 1. Save the current configuration o n each Nokia Platform before you set up QoS. Doin g so allows you to compare the relative perform ance of the QoS and non-QoS configurations. a. Click Configuration Sets unde r Configuration > System Management in the tree view . b. Enter pre-QoS in the Save Current S tate to New Configuratio n Da tabase edit box. c. Click Apply , and then click Save to make your change permanent. 2. Create an Aggregati on Class a. Click Aggregation Class under Configuration > T ra ffic Management in the tree view . b. Enter wan_1_ef in the Name edit box in the Create a New Aggregation Class section. c. Enter 100 in the Mean Rate (Kbps) edit box. d. Enter 5000 in the Burs tsize (bytes) edit box. e. Click Apply , and then click Save to make your Ch anges permanent. 3. Create a Queu e Class a. Click Queue Class link under Configuration > T raffic Management in the tree view . b. Enter wan_1_ef in the Create a New Queue Class edit box. c. Click on the link to wan_1_ef in the Existing Queue Class es section to view existing queue class values. 00045 Client Server LAN LAN W AN Link Nokia Platform A Nokia Platform B
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 467 Note The queue specifier associated with expe dited forwarding queue is 6. 4. Associate the wan_1_ef queue clas s with the appropriate interface. a. Click Interfaces under Configuration > Inte rface Configuration in the tree view . b. Click on ser -s3p1 in the Physical column. c. In the Queue Configuration field, select Max Throughput from the Queue Mode drop- down window . d. Click Apply . e. In the Queue Configuration field, select wan_1_ ef from the Queue Class drop-d own window . f. Click Ap ply . g. Click Save to make your changes p ermanent. 5. Create a new Access Cont rol List rule to classify , condition, and prioritize telnet traffic. a. Click Access List under Configura tion > Traf fic Management in the tree view . b. Enter wan_1_telnet in the Create a New Access List edit box. c. Click Apply . d. Select ser-s3p1 from the Add Interfaces drop-down window . e. Select Output from Direction drop-down window . f. Click Ap ply . g. In the Existing Rules for wan_1_telnet section, click on the Add New Rule Before check box. h. Click Apply . i. Select prioritize from the Action drop -down window , and then click Apply . j. Select wan_1_ef from the Aggregation Cla ss drop-down window , and then click Apply . k. For Nokia Platform A, enter 23 in the De stination Port Range edit box, and for Nokia Platform B, enter 23 in the So urce Port Range edit box. Note The telnet port number is 23. l. Enter tcp in the Protocol edit box; enter 0xB8 in the DSfield edit box; and ente r 6 in the QueueSpec e dit box.
10 468 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note 0xB8 is the IETF dif ferentiated-services codepoint (in he xadecimal) for expedited forwarding tr affic. m. Click Apply , and then click Save to make your changes perman ent. T o test the configuration 1. Start a telnet session between the client and server . 2. Check the statistics on Nokia Pl atform A and Nokia Platform B a. Click Interfaces under Configuration > Inte rface Configuration in the tree view . b. Click on the link for ser -s3p1 in the Physical column. c. Click on the Interface Statistics link. d. Scroll down to view statis tics for Queue Class wan_1_ef. Y ou should see values ot her than zero on both Nokia P latform A and Nokia Platform B for the Packets Passed and By tes Pas sed counters in the Expedited Forwarding row . 3. Use the telnet session to generate traffic, a nd then check each Nokia Platform’ s interface statistics. a. Click Interfaces under Configuration > Inte rface Configuration in the tree view . b. Click on the link for ser -s3p1 in the Physical column. c. Click on the Interface Statistics link. d. Examine the statistics for input and output traffic and compare them to the statistics for Expedited Forwarding traf fic. 4. Start an ftp session to create h eavy (non-telnet) background traf fic over the W AN. Note that the telnet session remains responsive. Use a text editor to examine a file. 5. Save the QoS routing conf iguration (See S tep 1 in the instructions for how to configure this example), and restore the non-QoS configuratio n. Compare the dif ference in responsiveness when there is heavy W AN traffic bo th with and without QoS routing.
Nokia Network Voyager for IPSO 4.0 Reference Guide 469 11 Configuring Router Services This chapter describes how to enable your system to forward broadcast traf fic by enabling the IP Broadcast Helper , forward BOOTP/DHCP traffic by enabling BOOTP relay , how to enable router discovery , and ho w to configure for Network Time Protocol (NTP). A Nokia appliance, like any routing device, do es not forward broadcast traf fic outside its broadcast domain as per ethern et stan dards. T o have your applian ce forw ard broadcast traffic, you must enable the IP Broadcast Helper , as described in “IP Broadcast Helper” on page 471. T o forward BOOTP/DHCP traffic, you must en able Bootp/DHCP Relay , as described in “BOOTP/ DHCP Relay” on page 469. Both of these services listen for broadcasts on the configured interface and change them into a unicast transmission to the configured destination host. BOOTP/DHCP Relay BOOTP/DHCP Relay extends Boot strap Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) operation across multiple hops in a ro uted network. In standard BOOT P , all interfaces on a LAN are load ed from a single configuration server on the LAN. BOOTP Relay allows configuration requests to be forwarded to and serviced from configuration servers located outside the single LAN. BOOTP Relay has the following advantages over standard BOOTP:  It makes it possible to bootstrap load from redu ndant servers by allowing multiple servers to be configured for a single interface. If one of the redundant configuration servers is unable to perform its job, another takes its place.  It provides load balancing b y allowing dif ferent servers to be configured f or different interfaces instead of re quiring all interfaces to be loaded from a single configuration server .  It allows more centralized management of the bootstrap loading of clients. This advantage becomes more im portant as the network becomes la r ger . The IPSO implementation of BOOTP Relay is compliant with RFC 951, RFC 1542, and RFC 2131. BOOTP Relay supports Et hernet and IEEE 802 LANs by using canonical MAC byte ordering, that is, clients that specify Bootp htype=1: 802.3 and FDDI. When an interface co nfig ure d fo r BOOTP Re lay re ceives a boot requ est, it for wards the requ est to all the servers in its server lis t. It does this after waiting a sp ecified length of time to see if a local server answers the boot request. If a primary IP is specified, it stamps the request with that address, otherwise it stamps the request with the lowe st numeric IP address specified for the interface.
11 470 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring BOOTP/DHCP Relay Y ou can use Network V oyager to enable BOOTP Relay on each interface. If the interface is enabled for relay , you can set up a number of se rvers to which to forward BOOTP requests. Enter a new IP address in the New Server text bo x for each server . T o delete a server , turn it off. Ta b l e 2 8 describes the parameters that you can configure for BOOT P relay T o enable BOOTP relay on an Interface 1. Click BOOTP Relay under Configuration > Router Services in the tree view . 2. Select On for the interface on which yo u want to enable BOOTP . 3. Click Apply . Additional fields appear . 4. (Optional) Enter values for one or more of the following parameters, described in Ta b l e 2 8 , above.  Primary IP —Enter the IP address to use as the BOOTP rou t er ad dre s s.  Wa i t T i m e —Enter the minimum client-elapsed time (in seconds) before forwarding a BOOTP request.  New Server —Enter the IP address of the BOOTP/DHCP configuration se rver to which to relay BOOTP requests. 5. Click Apply . 6. Repeat to relay BOOTP request s to more than one server . 7. Click Save to make your changes pe rmanent. T able 28 BOOTP configuration p arameters Parameter Descr iption Primary IP If you enter an IP address in the Primar y IP text bo x, all BOOTP requests received on the interface a re stamped with this gateway address. This can be useful on interface s with multiple IP ad dresses (aliases). W ait Time Specifies the minimum number of seconds to wait fo r a local configuration server to answer the boot request before forwarding the req uest through the interface. This delay provides an opportun ity for a local configur ation server to reply before attempting to relay to a remote server . Set the wait time to a sufficient length to allow the local configuration server to respond before the r equ est is forwarded. If no local server is present, set the ti me to zero (0). New Server Enables forwarding of BOOTP requests to a configuration server . Y ou can configure relay to multiple configuration servers in dependently on each interface. Configuring different servers on different interfaces provides l oad balancing, while co nfiguring multiple servers on a single interface provides redun dancy . The Server IP Address cannot be an address belonging to the local machin e.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 471 T o disable BOOTP relay on an interface 1. Click BOOTP Relay under Configuration > Router Services in the tree view . 2. Select Off for the interface on which you want to disable BOOTP . 3. Click Apply to disable the interface. When you cli ck off, then apply , the BOOTP relay parameters (primary IP , wait time, and new server) disappear , however the parameters are still stored in the system. If you select On, then Apply , these parameters reappear . 4. Click Save to make your changes permanent. IP Broadcast Helper IP Broadcast Helper is a form of static addressing that uses directed broadcasts to forward local and all-nets broadcasts to desired destinations within the internetwork . IP Broadcast Helper allows the relaying of broadcast UDP pack ets on a LAN as unicasts to one or more remote servers. This is useful when you relocate servers or hosts from their original common segment and still want the service to be available. Note For further informa tion, see RFC1542 section 4. Y ou cannot pass BOOTP UDP packe t s by using th e IP Broadcast helper (UDP port 67). Th e BOOTP functionality on a router is different from generic UDP packet forwarding to a specified IP address. While the IP Broadcast Helper forwar ds the UDP packet to the IP address without modification, the BOOTP implementation is more complex—the client sends a broadcast BOOTP packet to the router , whic h sends a modified packet to th e server . The router modifies the packe t by in serting its IP address in the giad dr field of the BOOTP packet (this field is used by the server to identify the netw ork where the packet originated). Ta b l e 2 9 describe s the parameters that you ca n configure for IP broadcast helper . T able 29 IP Broadcast helper configurat ion paramete rs Parameter Description Forward Non local Allows you to forward packets that ar e not origin ated by a source that is directly on the receiving interface. When you enable Forward Nonlocal, it applies to all interfaces that are running the IP Helper service. Selecting Disable d requires that packets be generated by a source directly on the receiving interfac e to be eligible for re lay . Enabled allows forwarding of packets even if the source is n ot directly on the re ceiving interface. The default is Disa bled, which requires that packets be generated by a source directly on the receiving interface to be e ligible for relay . IP Helper Interface On/Off Specifies whether IP helper service is running on the inte rface. After you select On and click the Apply button, configu ra ti on options for IP broadcast h elper for the interface appear.
11 472 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure the relaying of broadcast UDP packets on your system, use the following procedure. T o configure IP broadcast helper 1. Click IP Broadcast Helper under Configura tion > Router Services in the tree view . 2. Click On for each interface to support IP Helper services. 3. Click Apply . The New UDP Port field app ears under that interface. 4. T o add a new UDP Port to the helper services: a. Enter the new UDP port number in the New UDP Port text box. b. Click Apply . The UDP port appears in the table for that interface with On and Off radio buttons. T o delete forwarding for a UDP service select Off and then click Apply . 5. T o add a n ew server to a UDP port: a. Enter the new server ’ s IP address in the New Address for UDP Port X text box. b. Click Apply . The server IP address appears under the UDP port. T o delete forwarding for a server select Off and then click Apply . 6. V erify that e ach interface, UDP po rt, or server is enabled (On) or disabled (Off) for IP helper support according to your requirements. 7. Click Save to make your changes pe rmanent. Router Discovery The ICMP Router Discovery protocol is an IETF standard protocol that allows hosts runni ng an ICMP router discovery client to learn dynamically about the presence of a viable default router on a LAN. It is intended to be used instead of having hosts wir etap routing protocols such as RIP . It is used in place of, or in addition to, statically configured default routes in hosts. UDP Port Specifies a new UDP service to be forwarded by an interface. Client UDP packets with the specified UDP port number will be fo rwarded to the configured server(s). Server address Specifies the se rvers defined for forwarding for the interface an d UDP servi ce. T able 29 IP Broadcast helper configurat ion paramete rs Parameter Description
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 473 Note Only the server portion of the Router Discove ry Protocol is supported. IPSO implements only the ICMP router discovery server portio n, which means that a Nokia router can advertise itself as a candidate default ro uter , but it will not adopt a default router using the router discovery protocol. The ICMP Router Discovery Service provides a me chanism for hosts attached to a multicast or broadcast network to discover the IP addresses of their neighboring routers. This section describes how you can configure a router to ad vertise its addresses by using ICMP Router Discovery . Router Discovery Overview The router discovery server runs on routers and announces their exis tence to hosts. It does this by periodically multicas ting or broadcasting a r outer advertisement to each interface on which it is enabled. These advertiseme nts conta i n a list of all the router addres ses on a given interfa ce and their preference for use as a default router . Initially , these router advertisements occur ev ery few seconds, then fa ll back to every few minutes. In addition, a host can send a r outer solicitation , to which the router responds wi th a unicast router advertisement, unless a multicast or broadcast advertisement is due in a moment. Each router advertisement contains an advertisement lifetime field indicating for how long the advertised addresses are valid. This lifetime is co nfigured such tha t anot her router advertisement is sent before the lifetime expires. A lifetime of zero (0) indicates that one or more addresses are no longer valid. On systems that support IP multicas ting, the router advertisements are sent by default to the all- hosts multicast address 224.0.0.1. However , you can specify the use of broadcast. When router advertisements are being sent to the all-hosts mu lticast address, or an in terface is configured for the limited-broadcast address 25 5.255.255.255, all IP addresses c onfigured on the phys ic al interface are included in the router advertisement. When the router advertisements are being sent to a net or subnet broadcast, only the address associated with that net or subnet is included. Note Router discovery is not supported when cluster ing is enabled. Configuring Router Discovery Ta b l e 2 9 describe s the parameters that you can configure for router discovery .
11 474 Nokia Network Voyager for IPSO 4.0 Refe rence Guide T o configure the router discovery services on your system, use th e follow ing procedure. T o enable router discovery services 1. Click Router Discovery under Configuration > Router Services in the tree view . 2. Select On for each interface to support router discovery service. 3. Click Apply . Additional fields appear . 4. (Optional) Enter values for the fo llowing parameters, described in Ta b l e 3 0 .  Minimum Advertisement Interval  Maximum Advertisement Interval T able 30 Router discover configuration p arameters Parameter Description Router Discovery Interface O n/Off Specifies whether ICMP router di scovery is running o n the interface. When you select On and click Apply , configur ation options for the interface appear . Min. Advertise Interval Specifies the minimum time (in seconds) allowed between sending unsolici ted broadcast or multicast ICMP Router Advertisements on the interface. Range: Between 3 seconds and the val ue of Maximum Adve rtisement Interval. Default: 0.75 times th e value in the Maxi mum advertisement i nterval field. Max. Advertise Interval Specifies the maximum time (in second s) allowed between sendi ng unsolicited broadcast or multicast ICMP Router advertisements on the interface. Range: 4-1800 Default: 600 Advertisement Lifetime Specifies the time (in seconds) to be p laced in the Lifetime field of Router Advertisement packets sent from the interface. Range: Between the value in the Maximum advertisement inte rval field and 9000 seconds. Default: 3 times the values in the Maximum advertisement interva l fie ld. Advertise Address For each IP address associated with the inte rface, specifies whether the address should be advertised in the Router Adverti sement packets. This option applies to each address on the interface a nd not to the inte rface itself. Default: Y es Preference Specifies the preferabi lity of the address as a default ro uter address, relative to other router addresses on the same subnet. The mi nimum value (0x80000000) is specified by the "Ineligible" button and indi cates that the address is not to be used as a default ro uter . Y ou can also make an IP address ineligible a s a default router address. Click Ineligible to remove an IP address as a possible default router address. The default is Eligible. Enter a value to indicate the level of prefere nce fo r the IP address as a default router address in the text box below the Eli gible button. The default i s 0.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 475  Advertisement Lifetime 5. (Optional) For each IP ad dress on the interfa ce, you can specify the following parameters, described in Ta b l e 3 0 .  Advertise Address  Preference 6. Click Apply . 7. Click Save to make your changes permanent. T o disable router discovery services 1. Click Router Discovery under Configuration > Router Services in the tree view . 2. Click Of f for each interface to disable support for router discovery service. 3. Click Apply . 4. Click Save to make your changes permanent. Network T ime Protocol (NTP) Network T ime Protocol (NTP) is an Internet standard protocol used to sy nchronize the clocks of computers in a network to the m illi second. Synchronized clock ti mes are critical for distributed applications that require time synchronization, such as Chec k Point FireW all-1 Sync, and for purposes such as analyzing event logs from differ ent devices, ensuring cron jobs e xecute at the correct time, and ensuring that applications that use system time to validate certificates find the correct time. NTP runs as a continuous bac kground client program on a computer , sending period ic time requests to the servers that you configure, obtaini ng serve r time stamps and using them to adjust the client’ s clock. Y ou should conf igure several servers for redundancy . When you configure devices as peers, they listen to each othe r and move toward a common time. Peers are considered equal with eac h other as oppo se d to servers, which are c onsidered masters. It is important that you config ure several peers so that they can decide on the right time. If an NTP server or peer is not available, you ca n turn on the NTP reference clock to hav e your server configured as a source of time informatio n. In this mode, Nokia recommends that you keep the stratum value at its default (1). The stratum value tells how far away the NTP reference clock is from a valid time source. The time server begins to provide time info rmation 5 minutes after it is configured. Note IPSO does not implement SNT P .
11 476 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Configuring NTP Y ou can enable or disable NTP on your syst em; when NTP is active the local clock is synchronized as configured and hosts will be able to set th eir time through this machine. T o set the time manually , see “Setting the System T ime” on page 158. T o configure NTP 1. Click NTP under Configuration > Rout er Services in the tree view . 2. Click Y e s in the Enable NTP field. 3. Click Apply . The NTP configuration page appe ars. 4. Enter the new server IP address in the Add New Server Address edit box. 5. Click Apply . The IP address for the new NTP server appears in the NTP Servers field. By default, this new server is enabled, v3 is selected, and Prefer Y es is selected. As you add other servers, you might prefer them over th e initial server you configured. Note Nokia recommends that you use the default settin g of v3. 6. T o add another new server , repeat step 4 and click Apply . 7. (Optional) Enable the NT P reference clock by clicking Y es in the NTP Master field and click Apply . The Stratum edit box and Clock source drop-d ow n list appear . By default, the Stratum value is 1, and the Clock source is set to Local Clock. Nokia recommen ds that you keep these defaults. 8. T o configure a new peer , enter the new peer IP address in the Add New Peer: Address: edit box. Click Apply . The new peer IP address appears in the NTP Pe ers field. By de fault, this new peer is enabled, v3 is selected, and Prefer Y es is selec ted. As you add other peers, you might prefer them over the initial peer you configured. Note Nokia recommends that you use the default settin g of v3. 9. T o add another new peer , repeat step 8 and click Apply . The new peer IP address appears in the NTP Pe ers field. By de fault, this new peer is enabled, v3 is selected, and Prefer No is selecte d. T o prefer this peer over other peers, click Prefer Y es.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 477 10. (Optional) Enable the NTP reference clock by clicking Y es in the NTP Master field. Note Only enable the NTP reference clock if you cannot r each an NTP server . 11 . Click Apply . The Stratum and Clock source fields appear . By default, the Stratum value is 1, and the Clock source is set to Local Clock. Noki a recommends that you keep these defaults. 12. Click Save to make your changes permanent.
11 478 Nokia Network Voyager for IPSO 4.0 Refe rence Guide
Nokia Network Voyager for IPSO 4.0 Reference Guide 479 12 Monitoring System Configuration and Hardware This chapter provides informatio n o n monitoring your system.Y ou can use Network V oyager to monitor many aspects of your IP security platfo rm in order to better maintain performance and security . Y ou can, for example, monitor state inform ation for each interface, view the contents of IP routing tables, and generate reports on events such as throughput, bandwidt h utilization, and link states over specific periods of time. V iewing System Utilization St atistics Use the system utilization statistics to monitor an d tune the allocation of system resources. For example, if the percentage shown under file system capacity becomes a high percentage, you should take action, such as deleting old IPSO im ages an d packages or move yo ur log files to a remote system. T o view statistical information on system utiliza tion, click either CPU-Memory Live Utilization, Disk and Swap Space Utilization, or Process Utilization under Monitor > System Utilization in the tree view . CPU-Memory Live Utilization The CPU-Memory Live Utilizatio n page shows system resour ces usage, including CPU and memory usage. This pa ge retrieves the upd a ted CPU and memory us age every 20 seconds. The CPU Utilization summarizes the load averages, which are the number of processes in the system run queue averaged over th e last 1, 5, and 15 minutes, re spectively . Loa d averages that are high, such as over 2 in all three fields, indicate that the system is under continuous heavy load. The memory utilization summarizes memory usag e in KBs. Free memory (memory that is available to the operating system) is define d as free pages cache pages. The rema inder is active memory (memory the operating sy stem is currently using). The free memory might differ (will mostly be lower) as compared to output of a vmstat command.
12 480 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Disk and Swap Sp ace The Disk and Swap Space Utilization page shows sy stem resources use, in cluding disk and swap space use. This page retrieves the updated disk and swap space us e every 20 seconds. For each file system, you can monitor the number of kilobytes used and available, the percentage of disk space being used, the number of inodes used and free, and th e location where it is mounted. The inode is the intern al identifier for a file and a li mited number are available in a partition. A system can run out o f inod es before running out of disk space. For swap space, you can monitor the name of the device, total number of swap da ta blocks on the device, the number o f used and free swap data blocks on the device, and the type of device. Note Y ou should monitor the /config, /var , and /opt partitions, since these store the configuration files and logs and optional user software. Unlike read-only p artitions, these can grow dynamically . Monitoring Process Utilization The Process Utilization page shows the status of processes. Y ou must monitor and control processes to manage CPU and memory resources. This page retrieves the updated process status every 30 seconds. When you access this page, a table displays the following fields for each process:  USER—User who initiated or executed the process.  PID—Identifier used by the kernel to uniquely identify the process.  %CPU—Percentage of CPU used by the p rocess while activ e. This is a decayin g average taken over a time period of up to the prev ious minute. Because the time base over which CPU utilization of the process is computed va ries (processes might be very young), the sum of all CPU fields can exceed 100%.  %MEM—Percentage of real memory used by the process while active.  VSZ—V irtual size of the process in KBs (also called vsize).  RSS—Real memory (resident set) size of the process in KBs.  WCHAN—W ait channel (as a symbolic name). This is the event on which a process waits .  ST A T—Symbolic process state given as a sequen ce of lette rs . For example, R indicates a runnable process (R) that is a session leader (s). For more information, see the process status man page (man ps).  ST AR TED—T ime the command started.  TIME—Accumulated CPU time: user plus system (alias cputime ).  COMMAND—Command and arguments.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 481 IPSO Process Management When you are troubleshoo ting any system, it is helpful to have an unde rstanding of the daemons, or system processes, that are operating in the background. The process monitor (PM) monitors critical No kia IPSO processes. The PM is responsible for:  Starting and stopping the processes under its control  Automatically restarting the process es if they terminate abnormally The Nokia IPSO processes that the PM monitors are listed in the following ta ble. In addition, the PM might also monitor app lication package processes, such as IFWD, FWD, CPRID. The PM frequently checks the status of the pro cesses it monitors and typically takes less than a second to notice if a process has terminated abnorma lly . It then attempts to restart the process. If the process fails to start, the PM continues to try to restart it at regular intervals, with each interval increasing by a factor of two (for exampl e, 2 seconds, 4 seconds, 8 seconds, 16 seconds, and so on). If the PM fails to start the pr ocess after 900 seconds, it stops trying. Each unsuccessful attempt is lo gged in the system message log. Th e process monitoring behavior of the PM is not user configurable. Process Description inetd Intern et daemon. This daemon hel ps manage In ternet services on IPSO by monitoring port numbers and handling all requ ests for services. ipsrd Routing daemon. This daemon is a user-level process that co nstructs a routing table for the associated kernel to use for packet forwarding. With a few exceptions, IPSRD completely controls the contents of the kernel forwar ding table. This dae mon factors out (and separately provides) functionality common to most protocol implementations. This da emon maintains and implements the routing policy through a database. ifm Interface management daemon. This daemon send s and receives information to and fro m the kernel to verify the integrit y of the interface configuration. xntpd Network time protocol daemon. This dae mon set s and maintains a UNIX system time-of- day in compliance with Internet standard time servers. monitord System monitor daemon. This daemon monitors system hea lth, collects and stores statistical information, and disp lays the data on request. httpd Web server daemon. sshd Secure shel l daemon. xpand Configuration daemon (also called configd). This dae mon processes an d validates all user configuration requests, updates the system config uration database, and cal ls other utilities to carry out the request. snmpd SNMP ag ent. Responds to queries vi a SNMP .
12 482 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Generating Monitor Report s Y ou can generate reports of data collection even ts. T o generate a report , click the link for the appropriate report un de r Monitor > Repo rts in th e tree view . For information on configuring mo nito r reports, see “Configuring Monitor Reports” on page 177. The administrator can configure how often the data is collected, whether each data collection event is enabled or disabled, and how many hours worth of collected data are stored on the system. T able 31 Report s Report Description Rate-Shaping Bandwidth Shows specific bandwidth utilization. Y ou can us e traffic shaping to implement a specific pol icy that controls the way d ata is queued fo r transmission. For information on creating aggregate classes and configuring traffic rules, see Chapter 10, “Configuri ng T raffic Management.” Inclusion of number of packets delayed and bytes delayed is config urable by the administrator . By default, both are included. Interface Throu ghput Sho ws historical through put for each interface.Y ou can often use this information to optimize network perfo rmance or troubleshoot issues network traffic congestion. Inclusion of packet throughput, byte thro ughput, broadcast packets, and multicast packets for each interface is config urable by the administrator . By default, all are included. Network Throughput Similar to the interface thr oug hput report, except that the query is based on the network address ra ther than interface name. Interface Link S tate Shows information abo ut the li nk state of each interface. T he first signs of problems with interfaces is frequently s een in link errors. Y o u can use this report to determine if an interface is experiencing problems or has been incorrectly configured . CPU Utilization Shows historical CPU utilization data, including percentages of CPU time for each of the following: •U s e r % —Percentage of CPU time spent in User-level instructions. • Nice% —Pe rcentage of CPU time spent in "Nice" processes. •S y s t e m % —Percentage of CPU time spent in System level instructions. •I n t e r r u p t % —Percentage of CPU time spent in servicing interrupts. •I d l e % —Percentage time CPU was idle. Memory Utilization Shows histo rical memory utilization, incl uding: • Active Re al Memory —Kilobytes of real memory being used in a given time interval. • Free Real Memory —Kilobytes of rea l memory free in a given time interval.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 483 T o display reports 1. Click the name of the report un der Monitor > Reports in the tree view . 2. Under Select Report T ype, select one of the following:  Hourly —Hourly report with a 1-hour di splay up to a maximum of 7 interval day data.  Daily —Daily report with 1-da y display interval up to a maximum of 35 day data.  We e k l y —W eekly report with 7-day display interval up to a maxim um of 52 weeks.  Monthly —Monthly report with 1-mont h displa y interval up to a maximum of 60 months.  Detailed Search —Select a specific time period. The se reports have a default data interval of one minute. The number of hours wo rth of data stored for detailed searches is configured by the administrato r . For more information, see “Configu ring Monitor Reports” on page 177. 3. For the Rate-Shaping Bandwidth report, selec t an aggregation class for which you want to display a report or select All Aggregates to display data for all config ured ag gregatio n classes. Note Y ou must configure an aggregation class and associate it with an access control list for the name to appear a s a choi ce in the Agg regation Class list. Fo r more in formation, see Chapter 10, “Configuring T raffic Management.” 4. For the Interface Throughput, Ne twork Throughput, or Interface Link State reports, select All Logical or a specific interface name from the Select Interface drop-down list. 5. Under Select Format, choose Graphical V iew or Delimited T ext. If you select Delimited T ext, select Semi-C olon(;), Comma(,), or T ab from the Delimiter drop-down list. The Graphical V iew option displays pie and gr aph charts, as well as in table format. The Delimited T ext option displays the report in a new page from which you can download the information. 6. Click Apply . Monitoring System Health The system health links allow you to display statis tics to help you monitor the status of your IP security platform. T o view this information, click the appropriate link under Monitor > System Health in the t ree view .  Useful System S tatistics —Summarizes configuration inform ation, including the following:  Active Routes—The number of active routes configured.  Packets Forwarded—The number of packets forwarded.  VRRP Masters—The number of VRRP masters configured.
12 484 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Real Memory Used—The percentage of the real memory being used.  Disk Capacity—The percentage of the disk space being used.  Interface T raffic S tatistics —For each physical and logical interface, shows the current state, input and output bytes, input and output errors . For logical interfa ces, also shows the type of device or virtual circuit accessed th rough the logical interface (for example, Ethernet, A TM, FDDI).  I nterface Queue S tatistics —Shows the current information for interface queues, including the following:  Logical Name—The configured name of th e queue.  Maximum Packets—Co nfigured maximum nu mber of packets which ca n be buffered by this queue.  Packets Passed—Number of packets sent fro m this queue to the physical interface.  Bytes Passed—Number of bytes sent from this queue to the physical interface.  Packets Dropped—Number of packets dropped at this queue due to lack of buffer space.  Bytes Dropped—Number of bytes dropped at this queue due to lack of buffer space.  VRRP Service S tatistics —Shows per-interface and per-virtual router VRRP send and receive packet statistics. Monitoring System Logs The system logs links allow you to display update d system logs. T o view system logs, click the appropriate li nk under Monitor > System Logs in the tree view . T o refresh the information in a log, reload the W eb page. System logs incl ude the following:  System Message Log —Y ou can view the message log file in its entirety or select search criteria to view specific system lo g activity . Search criteria include:  T ypes of log activ ity—Select one or more from All, Emergency , Aler ts, Critical, Errors, W arnings, Notifications, Informational or Debug Messages.  Month  Particular date. Y ou must also selec t a month to activate this option.  Keyword. T o make the keyword search case-sensitive, select the Case Sensitive check box.  Y ou can include certain zipped files in your search by clicking th e appropriate check box in the Include Zipped Files in Search section. Note The system log also displays messages genera ted by the system configuration audit log. For informat ion configurin g the audit log, see “ T o set the s ystem configur ation audit log” on page 1 64.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 485  W eb Server Access Log —Shows informa tion about accesses to the Network V oyager interface using HTTP or HTTPS. Messages incl ude IP Address from which the local host did an http access to the system, user , date, time, and HTTP access command.  W eb Server Error Log —Shows error messages from the H TTPD Error Log File, including date and time the error occurred, transaction (type of log message), location, and contents of log message.  User Login/Logout Activity —Shows l ogin and logout activity for users. By default, activity for all user is displayed. Y ou can view activity for a particular user by selecting the user name from the drop -d own list.  Management Activity Log —Shows user login activity as we ll as details about changes made to the IPSO configuration. The log incl udes a time stamp, the hostname or IP address from which the user logged in, and the config en try , which displays the entry changed in the configuration database . For more information, see “T o set the system configuration audit log” on page 164. Note Y ou do not need to configure the Web Server Access log or the Web Server Error log. V iewing Cluster St atus and Members T o view information abou t cluster status and me mbers, click Clustering Monitor un der Monitor in the tree view . This page summarizes information about a configur ed IPSO cluster , including information about cluster status and load sharin g among members of the cluster . The information summary is refreshed every 30 seconds. The Cluster Status table contai ns the following information:  Cluster ID —ID number of the cluster .  Cluster Uptime —T ime since the cluster was formed.  Number of Members —Current number of members in the cluster .  Number Of Interfaces —Number of interfaces on which clustering is enabled.  Network —Networks on which clustering is enabled.  Cluster IP Address —Cluster IP Address on each network. The Cluster Memb er tab le con t ai ns the following information:  Member Id —Node ID in the cluster .  IP Addr —Primary IP address of the member .  Hostname —Hostname of the node .  Platform —T ype of platform.  OS Release —Operating system version node is running.  Rating —Node performance rating.
12 486 Nokia Network Voyager for IPSO 4.0 Refe rence Guide  Time Since Join —T ime since node joined the cluster .  W ork Assigned (%) —Percentage of work load assigned to this no de. Note If your cluster is not initialized, the Cluster Monitor page cont ains a link to the Cluster Configuration pag e, which enables you to configure cluster parameters for this nod e. V iewing Routing Protocol Information T o view statistical information for routing protocols, click the appropriate link und er Monitor > Ro uting Protocols. Y ou ca n select from the following links:  OSPF Monitor  BGP Monitor  RIP Monitor  IGRP Monitor  VRRP Monitor  PIM Monitor  DVMRP Monitor  IGMP Monitor T o monitor routing protocol information for IPv6 , you can select from the following links under Monitor > IPv6 Monitor:  OSPFv3 Monitor  RIPng Monitor  IPv6 VRRP Monitor  IPv6 Router Discovery Monitor  IPv6 Route Monitor  IPv6 Forwarding T able Displaying the Kernel Forwarding T able T o view the IP forwarding table that the kernel is using to make its forwarding decisions, click Forwarding T able under Monitor > Routing Protocols in the tree view . For IPv6, click IPv6 Fo rwarding T able under Monitor > IPv6 Monitor . Displaying Route Settings T o view the route settings for your system, clic k Route under Monitor > Ro uting Protocols in the tree view .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 487 For IPv6, click IPv6 Route Monitor under Monitor > IPv6 Monitor . Displaying Interface Settings T o view the interface settings for your system, click Route under Monitor > Routing Protocols in the tree view . Hardware Monitoring Y ou can use Network V oyager to monitor the following hardw are elements.  W atchdog timer—Monitors the kern el to de tect system hangs. If it detects a hang, it re boots the system. Y ou can view the following information about the watchdog timer:  Current state of the watchdog timer .  Mode—i.e. reset mode indicates that the wa tchdog timer detects a hardware problem or when the timer expires, it will reset the system.  T ickles—Number of times the system tickled the watchdog timer . Tickled means the kernel contacted the timer to indicat e the kernel is operating normally .  Last Reboot—Whether the last system rebo ot was done manually either using the shutdown command or by po wer-cycling.  Fan sensors—Shows the fan ID number , location, status, current value, normal value, and fan limit.  Power supply  T emperature sens ors  V oltage sensors  Slots—Status of each device slot that is in use.  Cryptographic Accelerator—S tatistics of crypto graphic accelerator if one is installed on your IP security platform. These include the following statistics:  Packet statistics—Packets Received: number of packets passed to th e driver for processing. Packets Dropped: number of packets that could not be proc essed by the device. Packets Processed: number of packets successfully pro cessed by the device  Byte statistics—Bytes Received: number of data bytes received by the driver for processing. Bytes Dropped: number of data bytes that could not be processed by the device. Bytes Processed: number of data by tes successfully processed by the device. Note: Byte statistics may overflow quickly on a heavily utilized encrypted channel.  Error statistics—Received Digest: number of times an invalid digest was encountered when a received message w as processed. Rand om Number: number of times a random number could not be gen erated. Buffer A lignment: number of buf fers passed to the device that were incorrectly aligned. Devi ce: number of times that a device was not available to process a data message. Me mory: number of times that memory could not be allocated to process a data message. Context: nu mber of times that an invalid c ontext was specified to process a data me ssage. Packet Header: number of times that an mbuf did not have a valid header .
12 488 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Using the iclid T ool Obtain routing diagnostic inform ation by creating a telnet session on the IP security platform and running iclid (IPSRD command-line interface daemon). T o display routing daemon status using iclid 1. Create a T elnet session and log into the firewall. 2. T ype iclid The prompt change s (to < node-name >) to indicate that you can now en ter iclid commands. iclid Commands Some commands might produce more outp ut than can fit on a single screen; iclid p ages the output of such commands fo r you, that is, stop s the output after one screen and indicates that there is more output with a MORE prompt. Y o u can see the ne xt screenful of outpu t by selecting any key except the q key; you can abort th e command and any further o utput by typing q at the MORE prompt. If you do not ente r anything within about 30 seconds, the system automatically pages to the next screenful of information. Y ou can temporarily defeat this automatic paging by typing ctl-S, although when you resume scro lling (by selecting any key) you might lose a page of information. At any point in iclid , you can type ? to display possible comman d c ompletions. Y ou can a lso abbreviate commands when an abbreviation is not ambiguous. The help comma nd takes as ar gume nts iclid commands and t op-level iclid categor ies; it displays a brief summary of what the specified command displays. The quit command returns control to the firewall shell. The exit command is the same as the quit command. The show command provides m any kinds of information, displayed in useful formats. The following table shows examples of the top-level ic lid element that can be displayed by the show command as applied to each parameter , along wi th any selected categor ies and subcategories , and a description of the inform ation the command displays. Command Description ? or <tab> Shows all possible command completions. help Displays help information. quit or exit Quits iclid . show Shows formatted, categorized system information. Element Category Subcategory Description
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 489 bgp Provides a BGP summary . errors A table of BGP errors. groups A table of p arameters and data for each BGP group. detailed Det ailed statistics on BGP groups. summary A summary of st atistics on BGP group s. memory Lists BGP memory p a rameters and statistics. neighbor < peerid> advertise Shows BGP neighbor statistics. detailed Provides detailed information about BGP neighbors and is organized by neighbor address. In the event of an excessively long list, type q . paths List of BGP paths; in the event of an excessively long list, type q . peers Summary information about peer firewalls. detailed Det ailed information about ea ch peer firewall; in the event of an excessive ly long list, type q . summary Summary table about peer firewalls. redistribution to AS <as number> Shows detailed redistribution data from BGP to the designated AS. to AS <as number> from <proto> Shows detailed redistribution data to the designated AS from the specified protocol. statistics A table of peer parameters and statistics. summary BGP su mmary . Element Category Subcategory Description bootpgw interface BOOTP relay state of interfaces enabled for BOOT protocols. <interface> BOOTP relay state of specified interface. stats Summary of BOOTP relay re quests, and replies received and made. rec Summary of BOOTP relay requests received. req Summary of BOOTP relay requests made.
12 490 Nokia Network Voyager for IPSO 4.0 Refe rence Guide rep Summary of BOOTP relay replies made. Element Category Subcategory Description dvmrp Summary of DVMRP state. interface Interface-specific state of DVMRP for each DVMRP-enabled interface. neighbor routes S tate of DVMRP neighbor route. neighbors Interface state of DVMRP neighbor pa rameters. route Shows state of DV MRP route parameters. stats S tatistical information about DVMRP packets sent and received, includin g an error summary . receive A summary of stat istical informati on about received DVMRP packets. transmit A summary of st atistical information about transmitted DVMRP packet s. error A summary of DVMR P packets with errors. Element Category Subcategory Description igmp S tate of IGMP . groups S tate of the IGMP group s maintained for each network interface. if stats Summary of information about IGMP interface packets transmitted and received for each network interface. interface IGMP settings for each network interface. stats S tatistical informatio n about IGMP packets sent and received as well as an error summary . Element Category Subcategory Description inbound filter Lists inbound filters and data for all protocols. Element Category Subcategory Description interface S tatus and addresses of all configured interfaces. Element Category Subcategory Description krt Displays IPSRD core information.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 491 Element Category Subcategory Description memory T otal memory usage in kilobytes. detailed T otal memory use as well as memory use by each routin g protocol. Element Category Subcategory Description ospf border routers L ists OSPF border routers and associated codes. database area Provides statistical data on OSPF da tabase area. database summary A database summary of the OSPF firewall. router St atistical data on firewall link states as well as link connections. asbr summary A summary of the OSPF firewall. external Information on the OSPF external database. summary Summary of OSPF database. checksum St atistical data on the OSPF checksum database. network Dat a on OSPF da tabase network. type Data on the state of firewall link parameters. errors brief Provi des basic da ta on OSPF errors. dd OSPF dd errors. hello OSPF hel lo errors. ip OSPF interface protocol errors. lsack O SPF ls acknowl edge errors. lsr OSPF lsr errors. lsu A list of OSPF lsu errors. proto OSPF protocol errors. events OSPF events and event occurrences. interface detail A comprehensive presentation of detailed OSPF interface data.
12 492 Nokia Network Voyager for IPSO 4.0 Refe rence Guide stats A comprehensive list of OSPF interface statistics. neighbor Lists OSPF neighbors and associated parameters. packet s Lists received and tr ansmitted OSPF packet s. Element Category Subcategory Description <proto> inbound filter Lists inbound filter data for the specified protocol . redistribution Lists redistributi ons from all sources to the designated protocol. redistribution from <proto> Lists redistributions from a specified protocol to another specified protocol. Element Category Subcategory Description redistribution Shows a comprehensive list of redistribu tions to various protocols and autonomo us systems, and includes detailed distributi on data. Element Category Subcategory Description resource A comprehensive listing of resource statistics. Element Category Subcategory Description rip A summary of informati on on the RIP routing process. errors A list of va rious RIP errors. packets S tatistics on various RIP packet s transmitted and received. Element Category Subcategory Description route Lists data on static and directly connected routes. aggregate Data on aggregate routes by code letter . all List of all routes and st atus da ta. In the event of a long list type q . aggregate Dat a on all aggregate routes by code letter . bgp Data on BGP routes. direct Data on direct routes.
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 493 igrp Data on IGRP routes. ospf Data on OSPF routes. rip Dat a on RIP routes. static Data on static routes. bgp S tatistics on BGP routes. aspath List of parameters and st atus of BGP AS path. communities S tatus of BGP communities. detailed Det ails of BGP rou tes. metrics S tatus of BGP metrics. suppressed List and status of suppressed BGP routes. direct Directly con nected routes and their status. igrp Displays IGRP routes. inactive Inactive routes. aggregate Inactive aggregate routes . bgp In ac tive BGP routes. direct Inactive direct routes. igrp Inactive IG RP routes. ospf Inactive OSPF routes. rip Inactive RIP routes. static Inactive static routes. ospf OSPF route data. rip RIP route data. sta ti c S tati c ro ut e data. summary Displays the number of routes for e ach protocol. Element Category Subcategory Description version Operating system version informa ti on. Element Category Subcategory Description
12 494 Nokia Network Voyager for IPSO 4.0 Refe rence Guide The following table shows examples of the iclid show command. Preventing Full Log Buffers and Related Console Messages When a significant amount of your traffi c is us ing fast path for delay-critical, real-time routing through the firewall, the console might di splay one of the following error messages: [LOG-CRIT] kernel: FW-1: Log Buffer is full [LOG-CRIT] kernel: FW-1: lost 500 log/trap messages The kernel module maintains a buffer of waiting log messages that it forwards through fwd to the management module. The bu ffer is circular , so that high logging volumes can cause buf fer entries to be overwritten before they are sent to fwd . When this happens, the system log displays the following message: log records lost The lost records are those that sh ould have been recorded in the FW-1 log me ssage file (typically located in the $FWDIR/log directory ). Y ou can use one o r both of the follow ing solutions to re solve this issue:  Reduce the nu mber of rules that a re logged by:  Disabling as many accounting rules as possible  Changing as many lon g lo gging ru les to short logging as possible  Eliminating logging entirely if it is practical to do so  Increase the size of the kernel module buffer vrrp VRRP state information. interface VRRP interfaces and associated informa tion. stats VRRP transmission and reception statistics. iclid show command Shows show ospf OSPF summary information. show ospf neighbor (s o n) OSPF neighbor information. show route All routes. show route bgp 127 Only BGP routes that start with 127. show b? All possible command completi ons for show b .
Nokia Network Voyager for IPSO 4.0 Reference Gu ide 495 Note T o perform the following proced ures, use the zap or modzap utility . Y ou can obtain these utilities from the Nokia T echnical Assistance Center (T AC)—refer to Resolution 1261. If you are using FireW all-1 4.1 1. Set the execute permissions by issuing an fwstop command. 2. T o confirm that you have sufficient resources to increase the buffer size, issue the following command: # ./modzap -n _fw_logalloc $FWDIR/boot/modules/fwmod.o 0x20000 where 0x20000 indicates a buffer size of 2MB, and the -n option causes modzap to check the value at the symbol reported. 3. A console message is displayed confirming the change that will take place when you issue the modzap command in the next step. Y ou can safely ignore this message. Note If the message indicates that you have insuf ficient resources to accommodate a larger buffer size, take appro priate action s and try t his procedu re again. For further information, cont act Nokia T echnical Assistance Center (T AC). 4. After you verify that the change is appr opriate, issue the same command without the -n option: # ./modzap _fw_logalloc $FWDIR/boot/modules/fwmod.o 0x20000 A confirmation message is displaye d, which you can safely ig nore. 5. Reboot the system. If you are using FireW all-1 NG 1. Set the execute permissions by issuing a cpstop command. 2. T o confirm that you have sufficient resources to increase the buffer size, issue the following command: modzap -n _fw_log_bufsize $FWDIR/boot/modules/fwmod.o 0x200000 where 0x20000 indicates a buffer size of 2 MB, and the -n option causes modzap to check the value at the symbol reported. 3. A console message is displayed confirming the change that will take place when you issue the modzap command in the next step. Y ou can safely ignore this message.
12 496 Nokia Network Voyager for IPSO 4.0 Refe rence Guide Note If the message indicates th at you have insuf f icient resources to accommodate a larger buffer size, take appro priate action s and try t his procedu re again. For further information, cont act Nokia T echnical Assistance Center (T AC). 4. After you verify that the change is appr opriate, issue the same command without the -n option: modzap _fw_log_bufsize $FWDIR/boot/modules/fwmod.o 0x200000 A confirmation message is displayed, which you can safely ignore. 5. Reboot the system. Because these console messa ges are also writt en to the FW-1 log message file, Nokia recommends that you d o th e follo wing to prev ent depleting the disk space allocated for the FW-1 log message file: 1. Move your log files from the sy stem hard drive to a server . 2. Configure the relocated files by using the Check Point managem ent client GUI (Smart Dashboard) as follows: a. Select the Check Point gateway object you are configuring. b. Under Gateway Object Configuration, selec t the Logs and Masters section a nd do the following:  Specify the amount of free disk space required for local logging.  Specify to stop logging when the free disk space drop s below x MB and to start logging to a new file. Once a new file is being used, the previously u sed log files are deleted until the required free disk space is restored.
Nokia Network Voyager for IPSO 4.0 Refere nce Guide Index - 4 97 Index A AAA account profile 316 authentication profile 314 configuring new se rvice 313 service module entry 314 service profile 314 session profile 31 7 ABR (area border ro uter ) 355 Accept Connections to VRRP IPs option 191 access control list (ACL) 452 access co ntrol lists 449 adding rule to 453 configuring 450 configuring rules 452 DSfield 450 modifying rules 453 rule attributes 454 VRRP 204 access mec hanisms assigning to us er s 295 described 293 account profile, AAA 316 active route 401 active status monitor frame relay 116 admin netwo rk login 297 admin role 29 4 admin use r described 288 initial configuration 24 SSH login permission 305 ADP I/O ports 216 agent address 255 aggregate routes configuring 399 described 398 IPv6 273 weight 401 aggregatio n clas s 454 aggregation clas ses associating with rules 456 configuring 455 Apply button 26 area border r outer s 355 areas OSPF, defined 354 ARP changing g lobal param eters 128 configuring for ATM interf aces 130 deleting dynamic table entries 130 flushing dynamic entries 130 table entries 128 viewing dynamic entries 130 AS_PATH path at tr ibute 405 ASE routes 355 ASPATH regular expressions 448 Asset Management pa ge 28 ATM changing IP address 77 example 78 ATM Example 78 ATM interfaces 75 configuring ARP for 130 ATM QoS 459 ATOMIC_AGGREGATE path attribute 405 attacks person-in- the-middle 304 audit log configuring 163 authenticat ion VRRP 188, 192 authenticat ion profile, AAA 314 authorized keys, SSH 308 auto-deactivation 195 auto-negotiation enabling 34 autonomous sys tem (AS) BGP 407 described 351 B Back button 26 backup address, VRRP 189, 192
Index - 49 8 Nok ia Network Voyage r for IPSO 4.0 Reference Guide backup files default contents 169 manually creating 169 restoring from loca l 172 transferrin g 170 backup state, VRRP 202 backups cancelling scheduled 170 scheduling 170 bandwidth utilization 482 Bellman Ford algorithm 352 Bellman-Ford algorith m 385 best effort queue level 457 BGP capability 403 communities 407 community example 428 confederation example 423 confederations 409 described 403 external session (EBGP) 404 importing 407 in clusters 214 interactions with IGP s 406 internal session (IBGP) 404 LocalPref 401 MED 406 memory require ments 413 multi-exit discri minator (MED) 404 multihop connections 411 neighbors example 415 overview 352 path attribut es 404 redistributing routes 439 redistributing routes to 407 route dampening 411 route flapping 411 route reflection 408 route reflector example 426 VRRP 184 with clusters 413 with VRRP 412 BIOS 28 black hole static routes 395 BOOTP relay about 469 enabling on interface s 470 Bootp relay disabling 471 Bootp Relay (Bo o tp) enabling 470 bootstrap protocol 469 broadcast traffic forward ing 469 C cadmin password resetting 233 cadmin user 288 calling-line identification screening 56 CCLI 209, 210 Certificate Signing Request 303 chargen service 297 chassis fan failure trap 258 Check Point MIB 251, 252 Check Point NGX configuring for VRRP 197 Cisco HDLC changing IP addre ss 112 changing keepalive interval 111 configuring E1 interface 96 configuring for HSSI 103 configuring for T1 88 configuring for V.35 83 configuring for X.21 83 clearing disk cache 26 memory cache 26 CLI interface, described 23 CLI Reference Guide accessing 26 described 22 CLID screening 56 cluster admin role 294 cluster roles 295 Cluster Voyager 209, 212 using 232 clusterAdminRole 233 clustering BGP 214 configuring NGX for 241 considerations 214 crossover cables 215 example 208 forward ing mode 213 modes 212 multicast mode 213 OSPF 214
Nokia Network Voyager for IPSO 4.0 Reference Guide Index - 499 overview 207 PIM 214 static routes 214 three node example 243 transparent mod e 132, 215 upgrading images 217 clusters activating 229 adding nodes 229 administrator 210 administrators 233 configuring 220 configuring interfaces 222 configuring NTP 240 creating 220 deleting configurations 239 failure interval 234 firewall monitoring 223 installing IPSO Images 236 joining 229 managing 209, 231 managing interface configu ra tions 239 monitoring 234 multiple 215 network types 215 performance r ating 234 rebooting 237 removing nodes 238 roles 293 synchronizing time 239 traps 258 viewing members 485 viewing stat us of 485 with BGP 413 with OSPF 356 cold start t rap 256 COM2 login 297 COM3 login 297 commands, routing daemon (iclid) 488 common open policy serve r 461 communities, BGP 407 community strings 254 confederations, BGP 409 configurat ion change log 485 saving 166 traps 257 configuration file creating 167 configuration locks described 25 log in with 25 overriding 25 configuring Ethernet interfaces 34 IP addresses 31 mail relay 157 network devices 30 NTP 476 OSPF 109, 356 S/key 291 Secure Shell (SSH) 305, 309 SSH 305 T1 88 T1 for PPP 90 V.35 85 X.21 85 cookies session manage ment 301 COPS 461 core files on flash-based systems 165 cprestart comman d 253 CPRID process 481 cpsnmp_st art script 253 cpstop co mmand 253 CPU fan failure trap 258 CPU information viewin g 28 CPU memory historical utilization 482 live utilization 479 CPU utilization report 482 CPU utilization report configuring 177 cron jobs ensuring correct time 158 cron jobs, sche du le d tim es 475 crontab scheduling jobs 167 crossover cables in cluste rs 215 cryptographic acce lerator monitoring 487 D data transmission, queuing 482 date setting 158
Index - 50 0 Nok ia Network Voyage r for IPSO 4.0 Reference Guide daytime service 298 DDNS 153 DDR lists 58 applying to interface 60 rules 60 default route configuring 395 deleting IP address, VRRP considerations 193 dense mode described 370 in clusters 371 DES authentication 264 DHCP 469 address ranges 149 configuring 145 configuring client interfaces 146 configuring server 148 enabling client process 146 firewall rules 145 server process 147 dial-control MIB 251 dial-on-demand routing lists 58 disabling router discovery 475 static route 398 discard service 297 disk cache, clearing 26 disk information, viewing 28 disk mirroring 154 disk mirrors traps 256 disk space traps 257 disk utilization 479, 480 displaying routing daemon status (iclid) 488 routing protoc ol information 486 DLCI, changing in frame rel ay 114 DNS described 154 DNS spoofing 304 documentation conventions 21 related 22 domain name service 154 DSA generating host keys 306 user identities 310 DSfield 452, 455 duplex mode ethernet interface 34 duplex settings changing FDDI 50 duplicate IP addresses error message 190 DVMRP configuring 391 described 390 overview 352 DVMRP tunnels 125 DVRMP timers 391 Dynamic Hos t Configuration Pr otocol (DHCP) enabling 470 E E1 CSU/DSU 96 E1 interfaces configuring for Cisco HDLC 96 frame relay 100 EBGP connections 410 echo service 297 effective priority, VRRP 186 enabling Bootp Relay (Bootp) 470 DHCP 470 encryption for network voya ger 301 encryption accelerato r card s 327 encryption level, specifying 301 entity MIB 251 error messages duplicate IP addresses 190 EtherLike MIB 250 Ethernet interfaces configuring 34 Ethernet m anagemen t ports 30 expedited forwarding example 466 expedited forwarding queue level 457 extended mode, VMAC 190 exterior routes, IGRP 387 F failure traps 257 failure interval clusters 234 failure notification configuring 157
Nokia Network Voyager for IPSO 4.0 Reference Guide Index - 501 fan sensors, monitoring 487 FDDI changing dupl ex setting 50 changing IP add ress 50 FIN bits 349 firewall monitoring configuring in cluster 223 firewall policies VRRP 204 firewall state, monitoring fo r VRRP 203 FireWall-1 23 Forward button 26 forwarding broadcast traffic 469 forwarding mode 213 forwarding table viewing 486 frame relay changing active sta tus monitor setting 116 changing LMI p arameters 115 changing the DLCI 114 changing the interface type 115 changing the keepa live inter val 114 configuring E1 interface for 100 configuring for T1 92 configuring for V.3 5 85 configuring HSSI for 105 configuring seria l interface for X.21 85 DTE MIB 251 protocol configuration 114 FreeBSD 23 FTP configuring for 290 enabling access 297 port number 297 full log buffers, preven ting 494 FWD process 481 FWVPN 140 G gateway clu ster object 241 Generic Ro uting Encapsula tion (GRE) 118 GetBulkRequest 262 GetNextRequest 262 GetRequest error messages 261 Getting Started Guide and Release Notes 22 GRE tunnels 118 groups adding 293 described 292 editing 293 group ID 293 ID 289 other group 292 SSH privileges 307 viewing list of 292 wheel 292 H hardware management MIB 251 monitoring 487 viewing summary information 28 HDLC changing IP ad dr es s 112 changing keepalive in terval 111 configuring E1 96 configuring for HSSI 103 configuring for T1 88 configuring for V.35 83 configuring for X.21 83 hello interval VRRP 188, 192 help iclid 488 opening a second help window 27 routing daemon (iclid) 488 high availability disk mirroring 154 GRE tunnels 122 link redundancy 36 home directory, user 289 host address 159 host keys generating DSA 306 generating RSA 306 host resources MIB 250 hostname changing 166 how to change passwords 287 clear memory cache 26 enable SSH 305 open Network Voyage r 24 HSSI configuring for Cisco HD LC 103 configuring for fram e re lay 105 configuring interfaces for PPP 104 HTTP
Index - 50 2 Nok ia Network Voyage r for IPSO 4.0 Reference Guide tunneling over SSH 311 HTTP daemon error message log 304 HTTPD error log file 485 process 481 I IANAifType MIB 250 ICLID description 351 iclid commands 488 displaying status 488 help 488 ICMP router discovery protocol 472 ICMPv6 router di scove ry 2 75 IF MIB 250 ifLinkUpDown trap 256 ifm process 481 IFWD process 481 IGMP cluster membership repor ts 217 described 392 multicast mode 213 IGP 365 IGRP configuring 388 overview 352, 385 redistributing routes to 440 iInterface throu ghput report 482 IKE 329 images changing curren t 173 deleting 174 downgrading 176 installing 174 managing 173 testing 175 upgrading for cluster 176 InATMARP protocol 130 inetd proce ss 481 initialize state, VRRP 202 inodes 480 Integrated Services Digi tal Ne twork interfaces 51 interarea ro ut es 3 55 interface queue statistics 484 interface link state report 482 interface link state report configuring 177 interface m ode, VMAC 190 interface thro ughput report configuring 177 Interface type, changing in frame rela y 115 interfaces ATM logical IP subnet 79 enabling Ethernet 34 LIS 79 logical 31 loopback 117 overview 29 point-to-poin t link over AT M 75 prefixes 30 see also Ethernet see also FDDI see also HSSI see also loopback see also T1 see also V.35 see also x.21 serial 83 setting duplex mode 34 token ring 71 types of 29 unnumbered 107 viewing settings 487 X.21 83 interfaces V.35 83 interfaces, ethernet adding an identifying string 35, 42 setting speed 34 interior gateway protocols 365, 385 Interior Gateway Routing Protocol (IGRP) redistributing 440 internetwork cont rol queue level 457 intra-area routes 355 IP addresses adding to a lo opback 117 changing ATM 77 changing FDDI 50 changing in Cisco HDLC 112 changing in PPP 113 configuring 31 IP Broadcas t Helper configuring 472 description 471 IP forwarding MIB 250 IP MIB 250 IP over ATM (IPoA) 79
Nokia Network Voyager for IPSO 4.0 Reference Guide Index - 503 IP pools 224 IP source routing 304 IP spoofing 304 IP2250 clustering guidelines 216 link aggregation 37, 201 management p orts 30 transparent mod e 132 with clustering 207 IPoA 79 IPSec transpor t mode 329 tunnel mode 329 IPSec tunnels overview 328 requirements 333 Ipsilon Routing Daemo n (IPSRD) description 351 overview 23 IPSO managing images managing 173 overview 23 registration MIB 250 system MIB 250 IPSO images installing in cluster 236 upgrading in clusters 21 7 IPSRD 351 described 23 ipsrd proces s 481 IPSRD, see also Ipsilon routing Daemon IPv6 aggregate routes 273 configuring logical interfaces 268 default rout es 2 72 in IPv4 tunnels 270 OSPFv3 273 overview 267 RIPng 273 security and access 285 through IPv4 without tunnel 271 VRRP 277 ISDN cause values 67 Place and Receive Calls 57 Receive Calls 55 Removing an Incoming Number 57 troubleshooting 65 ISDN interfaces 51 ISDN MIB 250 J jobs, scheduling 167 joining cluster 229 join-time shared feature s 212, 226, 235 K keepalive changing interval for Cisco HDLC 111 changing interval in frame r elay 114 changing interval in PPP 112 maximum failures 113 L link aggregation configuring 39 configuring switches for 36 described 35 on IP2250 37 traps 257 link down trap 256 link recognit ion delay 34 link speed setting interface 34 link state advertisements 354 link trap parameter 34 link up trap 256 LIS interfaces 79 LMI, changing parameter s 115 LOCAL_PREF path attribute 405 LocalPref parameter 401 log buffers preventing full 494 logging configuring on disk-based systems 160 configuring on diskless system 161 logging off 24 logical queue specifier 455 login viewing user activity 485 logs files on diskles s system 162 system message 484 web server access 485 loopback adding an IP address 117 changing IP ad dr es s 117 interfaces 117 LSA
Index - 50 4 Nok ia Network Voyage r for IPSO 4.0 Reference Guide overview 354 M MAC address VRRP 190 mail relay configuring 157 description 156 features 156 sending mail 158 management ports 30, 216 master state, VRRP 202 MD5 authentication 264 MED 406 memory viewing 28 memory cache, clearing 26 memory utilization report 482 configuring 177 menu items, Voyager 22 message log 484 MIBs list of 249 mirror set 154 modem configuring 298 dialback 298 inactivity timeout 298 status 298 status poll interv al 29 8 types 299 Monitor Firewall State option 191 monitor interface parameter 195 monitor reports 482 configuring 177 monitord process 481 monitored-circuit VRRP configuring 192 monitoring fan sensors 487 hardware 487 monitor role 294 monitor us er 288 power supply 48 7 routing prot oc ols 486 slots 487 system logs 484 system resources 479 voltage sensors 487 watchdog t imer 487 monitoring cryptogr aphic accelerator 487 MSS clamping 46 MTU setting for GigE Interfaces 42 MULTI_EXIT_DISC path attribute 405 multicast mode 213, 214, 215 multicast routers 392 multicast routing protocol 352 multicast tunnels changing endpoint address 119 configuring addresses 391 multi-exit discriminato r (MED) 406 autonomous system (AS) 404 BGP 404 multihop feature, EBGP 410 multiple routing instances assigning access to 293 N neighbor di scovery configuring for IPv6 269 network access configuring 297 enabling 298 network devices, configurin g 30 network interface card (NIC) 30 network management station 256 network services chargen 297 daytime 298 discard 297 echo 297 enabling 298 time 298 network throughput report 482 Network Voyager described navigating in 26 opening 24 overview 23 setting session timeout 312 troubleshooting acce ss problems 301 Web access options 301 new password field 289 NEXT_HOP path attribute 405 NGX configuring for clustering 241 NMS 256 notification configuring failure 157
Nokia Network Voyager for IPSO 4.0 Reference Guide Index - 505 not-so-stubby areas 354 NSSA configuration param eters 358 defined 354 NTP configuring 476 description 475 NTP MIB 252 on clusters 240 O OID registration MIB 250 Open Shortes t Path First ( OSPF) configuring 109 opening Voyager 24 operating system (IPSO) 23 optional disks configuring logging to 163 installing 155 logging to 156 removing 156 Ositech Five of Clubs 299 OSPF area configuration para meters 357 configuring interfaces 362 global settings 357, 361 in clusters 214 OSPFv3 273 over unnumbered interfaces 110 overview 352 redistributing routes to 444 virtual links 359 VRRP 184 with clusters 356 with VRRP 355 Other group 292 P packages enabling 178 installing 178 packets filtering 449 prioritizing 449 passwords changing 287 interception of 304 managing 287 path attributes BGP 404 path attributes (BGP) definitions 405 PC card installing 155 logging to 161 storing logs on 156 PCMCIA login 297 PDU address 259 performance rating clusters 234 physical interfaces 30 PIM advanced options fo r dense mode 375 candidate bootstrap 379 configuring sparse mo de 376 debugging 383 described 370 disabling 3 74 high-availabili ty mode 377 in cluste rs 214 rendezvo us point 379 VRRP 184 with clustering 371 with VRRP 371 Point-to-Point changing IP ad dr es s 113 changing keepalive in terval in PPP 112 changing keepalive m axi mum failures in PPP 113 point-to-point links 75 Point-to-Point Over Ether net 43 port numbers SSL/TLS 301 ports redirecting for HTTP tu nnel over SSH 311 power supply traps 258 power supply, monitorin g 487 PPP changing keepalive failure s in Point-to-Point 113 changing keepalive in terval in Point-to-Point 112 configuring E1 interface 98 configuring for HSSI 104 configuring for T1 90 PPPoE 43 preempt mode 195 priority VRRP paramet er 184 priority delta, VRRP 189, 192 priority, VRRP 187, 191 process utilization 479, 480
Index - 50 6 Nok ia Network Voyage r for IPSO 4.0 Reference Guide process monitor 481 Q queue class 449, 450 queue classes associating with interfaces 459 configuring 457 creating 458 queue mode 34 QueueSpec 452, 455 R RADIUS 319 RAID 154 rate shaping example 465 rate-shap e MI B 250 rate-shaping bandwidth report 482 configuring 177 RDI (routing doma in identifier) 409 rebooting cluster 237 redistributin routes to IGRP 440 to RIP 440 redistributing IGRP 440 RIP 440 redistributing routes described 438 inbound route filters 445 to BGP 439 to OSPF 444 refreshing pages 26 reject static routes 395 Release Notes 22 Reload button 26 reloading p ages 26 reports configuring 177 displaying 483 generating 482 Reset Routin g button 26 RFC1583 compatibility 361 RIP aggregating ro utes 369 auto-summarization 369 configuring 367 example 369 MIB 250 overview 352, 365 redistributing routes to 440 RIPng for IP v6 273 timers 368 VRRP 184 rlogin utility vs. SSH 305 role-based administration overview 293 roles 295 adding 294 assigning to users 295 cluster 293, 295 deleting 295 described 293 editing 294 overview 294 predefined system 294 type 294 viewing list of 294 root user controlling root access 292 in wheel group 292 route precedence 401 rank 401 redistribution 441 route aggregatio n described 398 example 400 route dampening 411 route filters 445 route maps described 353 route rank 401 route redistribution described 438 route reflection, BGP 408 route-based VPN 140 router alert IP option 181 router disco very 472 configuring 473 disabling 475 IPv6 275 server 473 router services configuring 469 in clusters 215 routes flapping 411 redistributing 439
Nokia Network Voyager for IPSO 4.0 Reference Guide Index - 507 viewing settings 486 routing configuring 351 configuring ranks 402 creating a defa ult route 395 DDR lists 58 default prot oc ol rank 401 disabling a static route 3 98 features 390 IGRP 388 OSPF 109, 356 routing daemon (iclid ) commands 488 displaying status 488 help 488 routing domain 409 routing informatio n bases 413 Routing Info rm at ion Prot oc ol (RI P ) redistributing 440 routing protocols displayi ng statisti cs 486 RPF algorithm 390 RSA user identities 310 RSA host keys generating 306 RSS (Resident Set Size) 480 S S/Key 291 configuring 291 disabling 292 using 291 Save button 26 Secure Shell (SSH) configuring 305, 309 description 304 seed, S/Key 290 Self-Signed X.509 Certificate 303 sequence number, S/Key 290 serial interfaces 83 service module entry, AAA 314 service profile, AAA 314 session managemen t described 311 enabling 301, 312 Log Off link 24 specifying timeout 301 session timeout configuring 312 setting ti me/date 158 shell, user’s 289 show mcvr 201 show vrrp 201 slots monitoring 487 SMTP 157 SNMP agent address 255 contact info rmation 260 daemon 254 described 249 enabling 254 enabling traps 256, 259 error messages 260 framew ork MIB 250 location information 260 managing users 263 MPD MIB 250 request messages 263 sending traps 259 trap definitions 256 user-based SM MIB 250 snmpd pr oc es s 481 softwar e viewing summary information 28 spanning tree protocol 205 sparse m ode described 370 in cluste rs 372 SPF delay 361 SSH advanced options 306 authorized keys 308 configuring 305 disabling 3 05 enabling 305 features 304 key pairs 309 obtaining SSH client 305 tunnelling HTTP over 311 sshd proc es s 481 SSL/T LS about 302 certificate keys 302 connection testing 302 encryption level 301 generating certificate 302 generating keys 302 private keys 302 specifying port number 301
Index - 50 8 Nok ia Network Voyage r for IPSO 4.0 Reference Guide troubles hooting 304 viewing certificate and private key 304 states, virtu al router 201 static host deleting 160 static mode VMAC 190 static routes backup 398 description 394 disabling 398 example 397 in clusters 214 stub area defined 354 swap space utilization 479, 480 SYN bits 349 synchroniza tio n zon e 155 sysContact configuring 252 sysLocation configuring 252 system logs monitoring 484 system message log 484 system processes list of 481 system resources monitoring 479 viewing summary 28 system roles 295 system state saving 166 system time setting 159 system utilization statistics 479 T T1 configuring for Cisco HDLC 8 8 configuring for frame relay 92 configuring for PPP 90 example 94 T1 Interface Example 94 T1(with built-in CSU/DSU) Interfaces 88 TACACS 321 TCP MD5 authentication 411 TCP MIB 250 TCP packets 349 TCP/IP stac k, tuning 180 TCP-establis hm e nt fla g 454 telnet configuring for 290 enabling access 297 vs. SSH 305 temper ature trap 258 temperat ure sensors monitoring 487 TFTP access 297 time setting system 159 synchron izing on clus ters 239 time service 2 98 time setting 158 timeout, session 301 token ring MIB 251 token ring interfaces 71 TOS value of GRE tunnel 120 traffic queuing 450 shaping 449 traffic management overview 449 traffic shaping 482 translator role, NSSA 358 transpar ent mode configuring 136 described 132 in clusters 215 limitations 132 neighbor lear ning 133 VPN 134 traps sending 259 troubleshooting ISDN 65 SSL/TLS config uration 304 tunnels configuring IPv6 in IPv4 270 GRE 118 IPv4 in IPv6 272 tunnel MIB 251 tunnels DVMRP 125 U UDP UDP MIB 251
Nokia Network Voyager for IPSO 4.0 Reference Guide Index - 509 UDP packets forwarding 471 UDP ports IP Broadc ast Helper 472 unit types MIB 250 unnumbered inte rfaces 107 OSPF 110 users adding 290 attributes of 289 default 288 default pr ivileges for new 293 group ID 289 home directory 289 ID 289 managing accounts of 288 name 289 removing 290 removing director ies 290 shell 289 SSH privileges 307 viewing list of 288 viewing user activity 485 USM described 262 V V.35 configuring for Cisco HDLC 83 configuring for fra me re lay 85 example 8 7 interfaces 83 virtual IP addre ss, VRRP 189 virtual l inks OSPF 359 OSPF over unnumbered interf aces 110 virtual tunnel interfaces 140 VLAN interfaces 46 VMAC 190 VMAC mode 192 voltage senso r s, mo nit or ing 48 7 Voyager See Network Voyager VPN tunnels in clusters 224 VRID 183 selecting 191 VRRP active-active configuration 185 advertisem ents 183 authentication 192 authentication method 188 auto-deactivation 195 backup address 189, 192 changing backu p address 195 Check Point configuration r ules 199 Check Point NGX 197 CLI commands 201 configuring VRRPv2 196 deleting IP address from interface 193 effective priority 186 election protocol 183 established master vs. equivalent priority 188 firewall state 203 full method 193 full method, mon ito re d cir cuit 186 hello interval 188, 192 hello messag es 183 IPv6 277 IPv6 support 183 link aggregation 201 load sharing 185 location 202 MIB 250 monitored cir cuit 186 monitoring 201 OSPF 355 overview 183 packet statistics 484 preempt mode 188, 195 priority 184 priority delta 189, 192 priority parameter 187, 191 providing red undancy 185 removing VRRPv2 virtual router 197 RFC 183 RIP 366 routing protocols 184 service statistics 484 simplified method deleting virtual router 194 simplified method, configurin g 192 simplified method, mo nitor ed circuit 186 stats 202 switched environments 205 transparent mode 132 traps 257 troubleshooting failove r 203 virtual IP address 189 VMAC mode 190, 192 VRID 191 with BGP 412
Index - 51 0 Nok ia Network Voyage r for IPSO 4.0 Reference Guide VSZ 480 VTI 140 W watchdog t imer 487 WCHAN (wait channel) 480 web servers access log 485 wheel group 292 X X.21 configuring for Cisco HDLC 8 3 configuring for frame relay 85 example 87 interfaces 83 xntpd proces s 48 1 xpand process 481