VSX5000-InstlGuide N450000590r001

Nokia Virtual Firewall for Check Point VSX NGX R65 Installation and Configuration Guide
Supplement to the Check Point VPN-1 Power VSX NGX R65 Guide
Part Number N450000590 Rev 001 Published June 2008
COPYRIGHT 2008 Nokia. All rights reserved. Rights reserved under the copyright laws of the United States. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the United States Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 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 States Government regarding its use, reproduction, and disclosure are as set forth in the Commercial Computer Software-Restricted Rights clause at FAR 52.227-19. IMPORTANT NOTE TO USERS This software and hardware is provided by Nokia Inc. as is and any express or implied warranties, including, but not limited to, implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall Nokia, or its affiliates, subsidiaries or suppliers be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; 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 without further notice to any products herein. TRADEMARKS Nokia is a registered trademark of Nokia Corporation. Other products mentioned in this document are trademarks or registered trademarks of their respective holders.
070101
Nokia Virtual Firewall for Check Point NGX Installation and Configuration Guide
Nokia Contact Information Corporate Headquarters Web Site Telephone Fax Mail Address http://www.nokia.com 1-888-477-4566 or 1-650-625-2000 1-650-691-2170 Nokia Inc. 313 Fairchild Drive Mountain View, California 94043-2215 USA
Regional Contact Information Americas Nokia Inc. Tel: 1-877-997-9199 313 Fairchild Drive Outside USA and Canada: +1 512-437-7089 Mountain View, CA 94043-2215 email: info.ipnetworking_americas@nokia.com USA Tel: UK: +44 161 601 8908 Tel: France: +33 170 708 166 email: info.ipnetworking_emea@nokia.com Tel: +65 6588 3364 email: info.ipnetworking_apac@nokia.com
Europe, Nokia House, Summit Avenue Middle East, Southwood, Farnborough and Africa Hampshire GU14 ONG UK Asia-Pacific 438B Alexandra Road #07-00 Alexandra Technopark Singapore 119968 Nokia Customer Support Web Site: Email: Americas Voice: Fax: Asia-Pacific Voice: Fax: +65-67232999 +65-67232897 1-888-361-5030 or 1-613-271-6721 1-613-271-8782
https://support.nokia.com/ tac.support@nokia.com Europe Voice: Fax: +44 (0) 125-286-8900 +44 (0) 125-286-5666
050602
Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 In This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventions This Guide Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 13 14 14 14 15
Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Basic Nokia Virtual Firewall for Check Point VSX NGX R65 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Obtaining Check Point Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18 18 19
Configuring Virtual Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Creating a Virtual Switch Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Virtual Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Virtual Ethernet Interfaces to a Virtual Switch . . . . . . . . . . . . . . . . . . . . . . . Deleting a Virtual Switch Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Virtual Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 23 23 23 24
Planning a VRRP HA Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Hardware Platform Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall Synchronization Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topology and IP Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of Supported VSX Cluster Configurations . . . . . . . . . . . . . . . . . . . . . . . . Example 1: DMI and EVR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: DMI and VSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3: DMI, EVR, and IVR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 4: DMI and No Virtual Router Configuration . . . . . . . . . . . . . . . . . . . . . . Example 5: DMI, EVR, IVR, and DMZ Configuration . . . . . . . . . . . . . . . . . . . . . . Example 6: DMI with Internet Access to VSX Gateway . . . . . . . . . . . . . . . . . . . . Example 7: Non-DMI with EVR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Configuring the VSX Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 26 26 27 29 31 33 35 37 39 42
Nokia Virtual Firewall for Check Point VSX Installation and Configuration Guide
4 Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Using the VSX Configuration Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Using the cpconfig Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Managing the VSX Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Installing the Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Installing Management Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6 Installing the VSX Management Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Next Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7 Configuring the VSX VRRP Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Adding a Customer and a Customer Management Add-On . . . . . . . . . . . . . . . . . . Adding and Configuring the VRRP Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Virtual System for the VRRP Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring VRRP Active-Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing Up Your VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 56 67 73 75
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway . . . . . 77 Adding Interfaces to VRRP Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring Routing and Routing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Multiple Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Routing Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Gateway to Ignore Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CLI Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual IP Address Support for VRRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSPF Virtual Link and VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternate Area Border Router Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of OSPF Configuration in a VRRP Setup . . . . . . . . . . . . . . . . . . . . . . Example 1: OSPF with an EVR and a VS in a VRRP Setup. . . . . . . . . . . . . . . Example 2: OSPF with an EVR, IVR, and a VS in a VRRP Setup . . . . . . . . . . 84 84 85 85 86 86 86 87 88 88 88 89 89 90 93 93 96
Example 3: OSPF with a VS and no EVR in a VRRP Setup . . . . . . . . . . . . . . . 98 Example of OSPF Configuration on a Nokia Virtual Firewall for Check Point VSX Standalone Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Configuring OSPF on Nokia Virtual Firewall for Check Point VSX Standalone Gateway Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Configuring OSPF on Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Configuring OSPF on Nokia Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Enabling RIP for Nokia Virtual Firewall for Check Point VSX . . . . . . . . . . . . . . . 102 RIP 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Network Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 RIP 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Network Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Auto Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Voyager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 CLI Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Virtual IP Address Support for VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Configuring RIP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Configuring Auto-Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Example of RIP Configuration in a VRRP Setup with an EVR and a VS . . . . . . 107 Configuring RIP on the EVR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Configuring RIP on a VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 CLI Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Configuring Virtual IP Support for VRRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Configuring Dense-Mode PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Disabling PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Setting Advanced Options for Dense-Mode PIM (Optional) . . . . . . . . . . . . . . . . 113 Configuring Sparse-Mode PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Configuring High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuring this Router as a Candidate Bootstrap and Candidate Rendezvous Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Configuring a PIM-SM Static Rendezvous Point. . . . . . . . . . . . . . . . . . . . . . . . . 119 Setting Advanced Options for Sparse-Mode PIM (Optional). . . . . . . . . . . . . . . . 120 Debugging PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Example of PIM Configuration in a VRRP Setup . . . . . . . . . . . . . . . . . . . . . . . . 124 Configuring PIM-SM on the EVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Configuring PIM-SM on the VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Voyager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling BGP on Nokia Virtual Firewall for Check Point VSX . . . . . . . . . . . . . . CLI Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Sessions (Internal and External) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Multi-Exit Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Interactions with IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inbound BGP Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Redistribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Reflection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EBGP Multihop Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Dampening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Support for Virtual IP for VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Memory Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memory Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of BGP Configuration in a VRRP Setup . . . . . . . . . . . . . . . . . . . . . Example 1: BGP Configuration in a VRRP Setup with an EVR and a VS. . . . Example 2: BGP Configuration in a VRRP Setup with a VS Only. . . . . . . . . . Examples of BGP Configuration on a Standalone Gateway . . . . . . . . . . . . . . . Example 1: BGP Configuration in Standalone Setup With an EVR and a VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: BGP Configuration in a Standalone Setup with a VR and No EVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Neighbors Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IBGP on Nokia Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IBGP on Nokia Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IBGP on Nokia Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Nokia Platform C as an IBGP Peer to Nokia Platform A . . . . . . . Configuring Nokia Platform A as an IBGP Peer to Nokia Platform C . . . . . . . Configuring EBGP on Nokia Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring EBGP on Nokia Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring EBGP on Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring EBGP on Nokia Platform E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Path Filtering Based on Communities Example . . . . . . . . . . . . . . . . . . . . . . . . . BGP Multi Exit Discriminator Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Default MED for Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . .
128 130 130 131 131 132 133 133 134 134 135 135 136 137 138 139 139 140 140 140 141 141 142 149 150 151 151 152 152 153 153 154 154 154 154 155 155 156 156 157 157
Configuring MED Values for all Peers of AS200 . . . . . . . . . . . . . . . . . . . . . . . Configuring MED Values for each External BGP Peer for Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring MED Values and a Route Redistribution Policy on Nokia Platform D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Local Preference Value Example . . . . . . . . . . . . . . . . . . . . . . . . . BGP Confederation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Reflector Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform B as Route Reflector . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Platform C as IBGP Peer of Platform B . . . . . . . . . . . . . . . . . . . . Configuring Platform D as IBGP Peer of Platform B . . . . . . . . . . . . . . . . . . . . Configuring BGP Route Inbound Policy on Platform B . . . . . . . . . . . . . . . . . . Configuring Redistribution of BGP Routes on Platform B . . . . . . . . . . . . . . . . BGP Community Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EBGP Load Balancing Example: Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform A . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform B . . . . . . . . . . . . . . . . . . . . . . . Configuring a Static Route on Platform A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Static Route on Platform B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . EBGP Load Balancing Example: Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform A . . . . . . . . . . . . . . . . . . . . . . . Configuring a Loopback Address on Platform B . . . . . . . . . . . . . . . . . . . . . . . Configuring OSPF on Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an EBGP Peer on Platform B . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adjusting BGP Timers Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP MD5 Authentication Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring TCP MD5 Authentication on Nokia Platform A . . . . . . . . . . . . . . . Configuring BGP Route Redistribution on Nokia Platform B . . . . . . . . . . . . . . BGP Route Dampening Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Path Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static Routes on Nokia Virtual Firewall for Check Point VSX Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
158 158 159 159 160 161 161 163 165 165 167 167 168 168 168 170 170 170 170 171 171 171 172 172 172 172 172 173 173 173 174 174 175 175 176 176 177 177 178 179
Setting the Rank for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Multiple Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding and Managing Static Routes Example . . . . . . . . . . . . . . . . . . . . . . . . . . Creating and Removing Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Backup Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a Backup Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Aggregation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rank Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Route Rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Protocol Rank Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Rank for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Route Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Route Redistribution Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BGP Route Redistribution on Nokia Platform D. . . . . . . . . . . . . . Redistributing a Single Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing All Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing RIP to OSPF Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing Routes from RIP to OSPF External. . . . . . . . . . . . . . . . . . . . . . . Redistributing Routes from OSPF to RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redistributing OSPF to BGP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nokia Platform A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inbound Route Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IGP Inbound Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP Route Inbound Policy Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Route Inbound Policy on Nokia Platform D Based on ASPATH Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BGP AS Path Filtering Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASPATH Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOTP/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BOOTP/DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
179 180 181 181 182 182 183 183 184 184 185 186 186 187 187 188 188 189 189 190 190 190 191 192 193 193 194 194 195 196 197 197 198 198
10 Configuring Security and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Role-Based Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Roles and Access Mechanisms to Users . . . . . . . . . . . . . . . . . . . . . Authentication, Authorization, and Accounting (AAA) . . . . . . . . . . . . . . . . . . . . . . Configuring AAA Service Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 201 203 203 204 209
10
Configuring Nonlocal RADIUS Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Configuring TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Configuring Nonlocal TACACS+ Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 11 Policy-Based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 12 Configuring Automatic Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Enabling and Configuring Automatic Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Creating SSH Certificates for Automatic Backup . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Restoring System Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 A Helpful Commands and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Entering Commands from the Nokia Virtual Firewall for Check Point VSX Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SecureXL Commands: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup and Restore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EVR Default Policy Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Customers from Provider-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Authentication Is Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an Extreme Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-establishing Trust on Provider-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 226 226 226 226 228 229 229 229 229
11
12
About This Guide
This guide describes the installation and configuration of Nokia Virtual Firewall for Check Point VSX NGX R65on a Nokia IP security platform. Nokia Virtual Firewall for Check Point VSX NGX R65consists of Check Point VPN-1 Power VSX NGX R65running on Nokia IPSO 5.0. This guide describes how to configure features that are unique to Nokia Virtual Firewall for Check Point VSX, such as dynamic routing on a per virtual system basis.The guide also describe various configurations of Nokia Virtual Firewall for Check Point VSX gateways, including single gateway and VRRP pairs. This guide supplements the Check Point VPN-1 Power VSX NGX R65 guide, which contains important information, including VPN-1 VSX architecture and concepts, how to plan a VSX environment, and how to configure and manage objects in the VSX environment. You can download the Check Point VPN-1 Power VSX NGX R65 guide from the Check Point Web site at http://www.checkpoint.com. This preface provides the following information: In This Guide Conventions This Guide Uses Related Documentation
In This Guide
This guide is organized into the following chapters: Chapter 1, Installation Overview contains an overview of the installation process. Chapter 2, Configuring Virtual Switches, Chapter 3, Planning a VRRP HA Environment describes how to plan a Nokia Virtual Firewall for Check Point VSX environment in which two VSX gateways form a VRRP cluster. Chapter 4, Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway describes how to perform the initial configuration of the VSX gateway. Chapter 5, Installing the Management Server describes how to install the management server. Chapter 6, Installing the VSX Management Clientdescribes how to install the management client applications on your Microsoft Windows platform and contains
13
information on the next steps to take to configure your Nokia Virtual Firewall for Check Point VSX environment. Chapter 7, Configuring the VSX VRRP Cluster describes how to create and configure two VSX gateways in a VRRP cluster. Chapter 8, Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway, describes how to reconfigure certain aspects of the Nokia IP security platform after the initial setup. Chapter 9, Configuring Routing and Routing Services describes how to configure dynamic and static routing on a virtual system. Chapter 10, Configuring Security and Access describes how to configure non-local users and role-based administration. Chapter 11, Policy-Based Routing describes how to configure policy-based routing on a virtual system. Chapter 12, Configuring Automatic Backup and Restore describes how to configure automatic backups of a VRRP pair. Appendix A, Helpful Commands and Tips contains information about useful commands, back up and restore of a gateway, and tips on configuration and troubleshooting.
Conventions This Guide Uses

The following sections describe the conventions this guide uses, including notices, text conventions, and command-line conventions.
Notices
Note Notes provide information of special interest or recommendations.
Caution Cautions indicate potential equipment damage, equipment malfunction, loss of performance, loss of data, or interruption of service.
Text Conventions
The following table describes the text conventions this guide uses.
14
Related Documentation
Convention
Description Indicates command syntax, or represents computer or screen output, for example:
monospace font
Log error 12453 bold monospace font

Indicates text you enter or type, for example:
# cpconfig
Menu commands Menu commands are separated by a greater than sign (>): Choose File > Open. Enter indicates you type something and then press the Return or Enter key. Do not press the Return or Enter key when an instruction says type. Emphasizes a point or denotes new terms at the place where they are defined in the text. Indicates an external book title reference. Indicates a variable in a command:
The words enter and type
Italics
newpkg file_name.tgz
Related Documentation
For more information about Check Point VPN-1 Power VSX NGX R65 see the following documents: The Check Point VPN-1 Power VSX NGX R65 guide The Check Point Provider-1/SiteManager-1 User Guide for the version of Provider-1 you are using. The preceding guides are available at the Check Point Product Documentation Web site: http://www.checkpoint.com. For more information about how to configure and manage a Nokia IP security platform, see: The IPxxx Series Installation Guide for your platform. The Nokia Network Voyager Reference Guide for IPSO 4.2 The CLI Reference Guide for IPSO 4.2 The preceding documents are available at the Nokia Support Site: http://support.nokia.com. The Nokia Network Voyager Reference Guide and CLI Reference Guide are available both as PDF documents for printing and as a package which can be installed on your platform, allowing the documents to be accessed from Nokia Network Voyager.
Note The Nokia Network Voyager Reference Guide and the CLI Reference Guide are based on Nokia IPSO 4.2, which does not support routing instances. For information about configuring
15
routing instances for features such as VRRP, transparent mode, and routing, please consult the appropriate chapters in this manual.
16
Installation Overview
This chapter describes the basic components in the Nokia Virtual Firewall for Check Point VSX NGX R65environment and what you need to do to prepare for installation of Nokia Virtual Firewall for Check Point VSX NGX R65. The topics covered are: Basic Nokia Virtual Firewall for Check Point VSX NGX R65 Components Installation Overview Preparing the Network Obtaining Check Point Licensing
Basic Nokia Virtual Firewall for Check Point VSX NGX R65 Components
Nokia Virtual Firewall for Check Point VSX NGX R65 consists of a Nokia IP security platform that is running the Nokia IPSO operating system and the Check Point VPN-1 Power VSX NGX R65 NGX R65 packages. The Nokia Virtual Firewall for Check Point VSX NGX R65 components include management products, gateway products, and client software. Table 1 lists the components you need to build a Nokia Virtual Firewall for Check Point VSX NGX R65 environment. For information on supported platforms, see the Nokia Virtual Firewall for Check Point VSX NGX R65 Release Notes.
Table 1 Nokia Virtual Firewall for Check Point VSX NGX R65 Components
Component Gateway Enforcement Module Name VPN-1 Power VSX NGX R65 Description Consists of the Check Point VPN-1 Power VSX NGX R65 software.
17
Table 1 Nokia Virtual Firewall for Check Point VSX NGX R65 Components
Component Management Server Name Provider-1/SiteManager-1 NGX R65 or SmartCenter NGX R65 Description Maintains the databases of network object definitions, user definitions, policies, and log files for any number of enforcement Modules. Provides the GUI interface you use to define network objects, customers, and policies.
Management Client Provider-1/SiteManager-1 GUI VSX NGX R65 SmartConsole NGX R65)
You can use Provider-1 or SmartCenter to manage Nokia Virtual Firewall for Check Point VSX NGX R65 gateways. The management model you choose depends on the deployment size, administration requirements, and your existing Check Point product deployment.
Preparing the Network

The Check Point VPN-1 Power VSX NGX R65 guide contains detailed information about how to plan a VSX environment, including examples of typical deployments. Use the Check Point guide to plan and prepare the network topology for your VSX environment. For information about planning a VSX environment with two Nokia Virtual Firewall for Check Point VSX gateways in a VRRP cluster, see Chapter 3, Planning a VRRP HA Environment. Nokia recommends that you physically connect all interfaces to the network before you perform any installation or configuration on the Nokia IP security platform.
You must install and configure the Nokia Virtual Firewall for Check Point VSX modules in the correct order: 1. Install and configure the VSX gateway. See the Release Notes for Nokia Virtual Firewall for Check Point VSX NGX R65 for more information on how to install the VSX software on your gateway. 2. Install and configure the Provider-1Server or SmartCenter. For more information see the Release Notes for Nokia Virtual Firewall for Check Point VSX NGX R65 and Chapter 5, Installing the Management Server. 3. Install the GUI applications (Provider-1 GUI and SmartConsole for the Provider-1 management model, or SmartConsole alone for the SmartCenter management model). For more information see Chapter 6, Installing the VSX Management Client.
18
Obtaining Check Point Licensing
Obtaining Check Point Licensing

Obtain the appropriate Check Point licenses from the Check Point User Center (http://www.checkpoint.com/usercenter) or from your vendor. You can also obtain trial licenses so that you can evaluate Check Point VPN-1 Power VSX NGX R65 without purchasing it. Start this process several days before the anticipated installation. You cannot complete the installation and configuration without the Check Point licenses. For more information on Check Point licenses and how to obtain them, see the Check Point documentation.
19
20
Configuring Virtual Switches
Virtual switches give you the ability to connect virtual systems without using a virtual router. Since virtual switches operate at layer 2, you will not have to segment your network or manually configure routing on routers adjacent to shared interfaces. Simplifying your typology from layer 3 to layer 2 reduces overall configuration complexity and overhead. As with a physical switch, virtual switches maintain forwarding tables with a list of MAC addresses and their associated ports. The following is the configuration process: 1. Create a virtual switch. 2. Add a physical interface to the switch. 3. Create virtual ethernets for each virtual system. 4. Add the virtual ethernets to the virtual switch.
Note Virtual switches cannot be created on a link-aggregated interface. Virtual Ethernet interfaces cannot be link aggregated.
Note Virtual switches do not support ADP acceleration.
The following diagram shows a virtual switch connecting three virtual systems. The virtual systems all reside on the same subnet using virtual Ethernet connections. When you view this configuration in the Provider-1 GUI, you will see the Ethernet interfaces and not the physical interface connected to the virtual switch.You configure virtual switches through either Network Voyager or Provider-1 or SmartCenter GUIs. Once you have created a virtual switch in either the Voyager GUI or the Check Point GUIs, all other virtual switches must be configured with the same GUI interface.
21
Creating a Virtual Switch Group

1. Click Configuration in the tree view. 2. Click Interface Configuration. 3. Click Virtual Switch. 4. Enter a number in the Virtual Switch ID text box. 5. Choose a physical interface to associate with the virtual switch from the Add Interface dropdown box. 6. Click Apply. You will see a link in the VSW-ID column with the virtual switch ID preceded by VSW, for example VSW 1. 7. Click Save to make your change permanent.
22
Creating Virtual Ethernet Interfaces
Creating Virtual Ethernet Interfaces

1. Click Configuration in the tree view. 2. Click Interface Configuration. 3. Click Virtual Switch. 4. Enter a number in the System ID text box. The number you enter becomes the unique identifier of the MAC addresses on the system. By giving a unique identifier to each system that is configured with virtual switches and virtual Ethernet interfaces, you prevent address clashes on your network. If you enter 3, then all virtual Ethernet interfaces on the system will have the designator 3, for example 0:a0:8e:3:0:1, 0:a0:8e:3:0:2 and so on. 5. Enter the starting identification number of the virtual Ethernet interfaces in the Interface ID text box. The number will be the number of the first virtual Ethernet interface, for example, if you enter 5 then the virtual Ethernet identifier will start at 5. All preceding virtual Ethernet interfaces will be numbered 6, 7, and so on. 6. Enter the number of virtual Ethernet interfaces you want configured on the system. 7. Click Apply. You will see virtual Ethernet interfaces along with their respective VED numbers, a link to the virtual Ethernet interface, and their MAC addresses. 8. Click Save to make your changes permanent.
Adding Virtual Ethernet Interfaces to a Virtual Switch

1. Click Configuration in the tree view. 2. Click Interface Configuration. 3. Click Virtual Switch. 4. Click the link of the virtual switch you want to configure. 5. Select an interface from the Add Interface drop-down box. 6. Click Apply. 7. Repeat steps 4 and 5 to add interfaces. 8. Click Save to make your changes permanent.
Deleting a Virtual Switch Group

1. Click Configuration in the tree view. 2. Click Interface Configuration. 3. Click Virtual Switch.
23
4. Click the delete box next to the virtual switch group you want to delete. 5. Click Apply.
Deleting Virtual Ethernet Interfaces

Note If VRRP was enabled on the interface, and no VS was created, you must remove the interface from the VRRP monitored list. Click Configuration in the tree view.
Note The interface must be removed from a virtual switch group before deleting the interface.
1. Click Interface Configuration. 2. Click Virtual Switch. 3. Click the delete box next to the interface you want to delete. 4. Click Apply.
24
Planning a VRRP HA Environment
This chapter describes how to plan a Nokia Virtual Firewall for Check Point VSX environment with VRRP High Availability (HA). It assumes you are familiar with the basic VSX architecture and concepts, as described in the Check Point VPN-1 Power VSX NGX R65. Nokia Virtual Firewall for Check Point VSX supports two modes of VRRP HA: Active-passive modein active-passive mode, one member of a VRRP HA cluster acts as the master member. If any interface fails in the master, the entire gateway fails over to the backup member. Active-active modein active-active mode, an individual virtual system (VS) can failover if one of its interfaces fails. Traffic for that VS fails over to the VS on the second member, but traffic for the other VSs is still handled by the cluster member on which the interface failed. Active-active mode also allows static load sharing to be implemented.
Note You cannot implement VRRP HA active-active mode on a VS where the VS is connected to any virtual router (either EVR or IVR). The external and internal interfaces of a VS should be connected to the physical interfaces. However, VSs in the same VSX gateway that are not configured in VRRP HA active-active mode can be connected to an EVR or IVR.
This chapter includes the following sections: Hardware Platform Planning Topology and IP Planning Examples of Supported VSX Cluster Configurations Overview of Configuring the VSX Cluster
25
Hardware Platform Planning

To set up a VSX VRRP cluster, you must use identical Nokia IP security platforms with the same network interface cards. Each platform must have the same number of installed NICs, and the NICs must be in the same slot on each platform. Use a minimum of three network interfaces on each gateway for a VSX cluster. The interfaces on both gateways must match physical and logical port names.
Firewall Synchronization Interface

VSX allows you to aggregate the built-in Ethernet ports to achieve redundancy for the firewall synchronization interface only. If the primary port of the link aggregation group fails, another member of the link aggregation group takes over the synchronization traffic.
Topology and IP Planning

Before you configure your VSX VRRP cluster, carefully plan the VSX VRRP topology and IP address allocation. You need to plan IP allocation for four networks: Virtual networkthe IP addresses visible to the user networks. These IP addresses are the same virtual addresses used in traditional cluster setups. The following virtual devices require virtual IP addresses: VSX gateway (external interface) EVRs and IVRs (external interfaces) VSs (external and internal network interfaces) Management networkused by the VSX gateway to manage the virtual devices. Each virtual device in each cluster member requires a unique real IP address for management purposes. Synchronization networka dedicated network used for state synchronization between cluster members. Internal communication networka private network that the VSX gateway uses internally to configure connections between virtual systems on a cluster member. The private network must not be used by any other interface on the cluster member and must not correspond to the network used on the synchronization interface.
Examples of Supported VSX Cluster Configurations

This section provides examples of supported configurations and their IP address allocations.
Note When you use NGX R65 management, the internal communication network can be changed after creating GWs and before creating VSs or VRs.
26
The following configurations are not supported: A non-DMI configuration with an IVR A non-DMI configuration without an EVR A VS configured for VRRP HA active-active mode that is connected to an EVR or IVR
Example 1: DMI and EVR Configuration

In the following example, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway is connected through a direct management interface (DMI) to the management server. Two virtual systems, VS1 and VS2, connect to the external network through a virtual router, (EVR). One virtual system, VS3, has a direct physical connection to the external network. Each virtual system has a direct physical connection to an internal network.
27
Figure 1 DMI and EVR Configuration

VSX1
VS1 EXT VRRP IP 10.10.10.75 eth-s1p4
VS1
VS1 VIP 192.168.1.75 eth-s1p2
VSX
VS2
VS2 EXT VRRP IP 10.10.20.75
EVR
eth-s1p1
VS3
eth4
eth-s1p3 VS2 VIP 192.168.2.75 eth2 eth-s1p3 VS3 VIP 192.168.3.75 eth3 VS1 EXT VRRP IP 10.10.10.75 Sync VSX VIP 172.16.1.75
EVR VIP 10.50.50.75
172.16.1.50 Provider-1 MDS eth-s1p4
Gateway 10.50.50.25
VS1
VSX
VS2
EVR
eth-s1p1
VS3
VS3 EXT VIP 10.10.30.75 eth4
Virtual Links Physical Links
VSX2
Private Internal Network 10.88.88.0/24 00057
Table 2 summarizes the interfaces shown in Figure 1.

Table 2 DMI and EVR Configuration
Interface VSX gateway (DMI) EVR VS1 to external network VS2 to external network VS3 to external network VS1 to internal network Physical interface name eth-s1p4 eth-s1p1 none Virtual IP address 172.16.1.75 10.50.50.75 10.10.10.75
none
10.10.20.75
eth4
10.10.30.75
eth-s1p2
192.168.1.75
28

Interface VS2 to internal network VS3 to internal network Synchronization Physical interface name eth2 Virtual IP address 192.168.2.75
eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the Management Server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Example 2: DMI and VSW Configuration

In the following example, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway is connected through a direct management interface (DMI) to the management server. Two virtual systems, VS1 and VS2, connect to the external network through a virtual switch, VSW One virtual system, VS3, has a direct physical connection to the external network Each virtual system has a direct physical connection to an internal network.
29
Figure 2 DMI and VSW Configuration

VSX1
VS1
VS1 VIP 192.168.1.75 eth-s1p2
VSX
VS2
VSW
eth-s1p1
VS3
eth4
eth-s1p3 VS2 VIP 192.168.2.75 eth2 eth-s1p3 VS3 VIP 192.168.3.75 eth3 VS1 EXT VRRP IP 10.50.50.75 Sync VSX VIP 172.16.1.75 Gateway 10.50.50.25
172.16.1.50 Provider-1 MDS eth-s1p4
VS1
VSX
VS2
VSW
eth-s1p1
VS3
VS3 EXT VIP 10.10.30.75 eth4
VSX2

Interface VSX gateway (DMI) VSW VS1 to external network VS2 to external network VS3 to external network VS1 to internal network Physical interface name eth-s1p4 eth-s1p1 none Virtual IP address 172.16.1.75 None 10.50.50.75
none
10.50.50.50
eth4
10.10.30.75
eth-s1p2
192.168.1.75
30

eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25, the IP address of the management interface on the management server is 172.16.1.50, and the IP address of the gateway internal communication network is 10.88.88.0/24.
Example 3: DMI, EVR, and IVR Configuration

In this example configuration, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway connects through a direct management interface (DMI) to the management server. All virtual systems connect to the external network through a virtual router, EVR Two virtual systems, VS1 and VS2, connect to the internal network through a virtual router, IVR. Virtual system VS3 has a direct physical connection to an internal network.
31
Figure 3 DMI, EVR, and IVR Configuration

VSX1
VS1 Internal VRRP IP 192.168.100.100 VS1 EXT VRRP IP 10.10.10.75
VS1
eth-s1p4
IVR
VS2 Internal VRRP IP 192.168.150.100
VSX EVR VS2

eth-s1p1
eth-s1p2 IVR VIP 192.168.50.100
VS3
VS3 EXT VRRP IP 10.10.30.75 EVR VIP 10.50.50.75
eth-s1p3 Sync eth-s1p3 VS2 Internal VRRP IP 192.168.100.100 eth2 VS3 Internal VIP 192.168.200.100 VS1 EXT VRRP IP 10.10.10.75 172.16.1.50 Provider-1 MDS VSX VIP 172.16.1.75
Gateway 10.50.50.25
VS1
eth-s1p4
IVR
VS2 Internal VRRP IP 192.168.150.100
VSX EVR VS2

VS3
VS3 EXT WRP IP 10.10.30.75
VSX2

Table 4 DMI, EVR, and IVR Configuration
Interface DMI-VSX gateway EVR VS1 to external network Physical interface name eth-s1p4 eth-s1p1 none Virtual IP address 172.16.1.75 10.50.50.75 10.10.10.75
32
Table 4 DMI, EVR, and IVR Configuration

Interface VS2 to external network VS3 to external network IVR VS1 to internal network VS2 to internal network VS3 to internal network Synchronization Physical interface name none Virtual IP address 10.10.20.75
none
10.10.30.75
eth-s1p2 none
192.168.50.100 192.168.100.100
none
192.168.150.100
eth2
192.168.200.100
eth-s1p3
none
Example 4: DMI and No Virtual Router Configuration

In this example, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway is connected through a direct management interface (DMI) to the management server. Each virtual system has direct physical link to the external and internal network. No virtual routers are used.
33
Figure 4 DMI and No Virtual Router Configuration

VSX1
eth-s3p1 VS1 EXT VIP 10.10.10.75 eth-s1p4 eth-s3p2
VS1
VS1 Internal VIP 192.168.1.75 eth-s1p2
VSX
VS2
eth-s3p3
VS2 EXT VIP 10.10.20.75
VS3
VS3 EXT VIP 10.10.30.75
eth-s1p3 VS2 Internal VIP 192.168.2.75 eth2 VSX VIP 172.16.1.75 Gateway 10.50.50.25
Sync
VS3 Internal VIP 192.168.3.75 eth3
eth-s1p3 eth-s3p1
172.16.1.50 Provider-1 MDS
VS1
eth-s1p4 eth-s3p2
VSX
VS2
eth-s3p3
VS3
Virtual Links Physical Links Private Internal Network 10.88.88.0/24 00064
VSX2

Table 5 DMI and No Virtual Router Configuration
Interface DMI-VSX gateway VS1 to external network VS2 to external network VS3 to external network VS1 to internal network Physical interface name eth-s1p4 eth-s3p1 Virtual IP address 172.16.1.75 10.10.10.75
eth-s3p2
10.10.20.75
eth-s3p3
10.10.30.75
eth-s1p2
192.168.1.75
34
Table 5 DMI and No Virtual Router Configuration

eth3
192.168.3.75
eth-s1p3
none
Example 5: DMI, EVR, IVR, and DMZ Configuration

In this example, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway is connected through a direct management interface (DMI) to the management server. All virtual systems connect to the external network through a virtual router, EVR. Virtual systems VS1 and VS2 connect to the internal network through a virtual router, IVR. Virtual system VS3 connects to a DMZ network through a virtual router, IVR-1.
35
Figure 5 DMI, EVR, IVR, and DMZ Configuration
VSX1
VS1 Internal WRP IP 192.168.100.100 eth-s4p1 eth-s4p2 eth-s4p3 IVR VIP 192.168.50.100 VS1 EXT VRRP IP 10.10.10.75
VS1
eths1p4
IVR
VS2 Internal WRP IP 192.168.150.100
VSX EVR VS2

eth-s1p1
IVR-1 DMZ
VS3 Internal WRP IP 192.168.200.100 eth-s1p3 Sync eth-s1p3 VS1 Internal WRP IP 192.168.100.100 VS1 EXT VRRP IP 10.10.10.75 172.16.1.50 Provider-1 MDS VSX VIP 172.16.1.75
VS3
VS3 EXTVRRP IP 10.10.30.75 EVR VIP 10.50.50.75 Gateway 10.50.50.25
VS1
eth-s4p3 eth-s4p2 eth-s4p1 IVR-1 VIP 192.168.200.75 eth-s1p2 eths1p4
IVR
VS2 Internal WRP IP 192.168.150.100
VSX EVR
eth-s1p1
VS2
IVR-1 DMZ
VS3 Internal WRP IP 192.168.200.100 Virtual Links Physical Links
VS3
VSX2

Table 6 DMI, EVR, IVR, and DMZ Configuration
Interface DMI-VSX gateway EVR VS1 to external network Physical interface name eth-s1p4 eth-s1p1 none Virtual IP address 172.16.1.75 10.50.50.75 10.10.10.75
36
Table 6 DMI, EVR, IVR, and DMZ Configuration

Interface VS2 to external network VS3 to external network IVR Physical interface name none Virtual IP address 10.10.20.75
none
10.10.30.75
eth-s4p1 eth-s4p2 eth-s4p3 eth-s1p2
192.168.50.100
IVR-1 (DMZ)
192.168.200.75
VS1 to internal network VS2 to internal network VS3 to internal network Synchronization
none
192.168.100.100
none
192.168.150.100
none
192.168.200.100
eth-s1p3
none
Example 6: DMI with Internet Access to VSX Gateway

In this example, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway is connected through a direct management interface (DMI) to an Internet router external to the VSX gateway. Instead of being accessed locally, the VSX gateway is accessed remotely over the Internet. The two virtual systems, VS1 and VS2, connect to the external network through a virtual router, EVR. VS1 and VS2 each has a direct physical connection to an internal network.
37
Figure 6 DMI with Internet Access to VSX Gateway Configuration
VSX1
VS1 EXT VRRP IP 10.10.10.75 Provider-1 MDS
VSX VS1
VS1 VIP 192.168.1.75 eth-s1p2
eth-s1p4
eth-s1p1
EVR
VSX VIP 172.16.1.75
VS2
VS2 EXT VRRP IP 10.10.20.75 eth-s1p3 EVR VIP 10.50.50.75 Sync VS2 VIP 192.168.2.75 eth3 Gateway 10.50.50.25 VS1 EXT VRRP IP 10.10.10.75
eth-s1p3
VSX VS1
eth-s1p4
EVR
eth-s1p1
VS2
VSX2

Table 7 DMI with Internet Access to VSX Gateway
Interface VSX gateway (DMI) EVR VS1 to external network VS2 to external network VS1 to internal network Physical interface name eth-s1p4 eth-s1p1 none Virtual IP address 172.16.1.75 10.50.50.75 10.10.10.75
none
10.10.20.75
eth-s1p2
192.168.1.75
38
Table 7 DMI with Internet Access to VSX Gateway

Interface VS2 to internal network Synchronization Physical interface name eth3 Virtual IP address 192.168.2.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25 and the IP address of the gateway internal communication network is 10.88.88.0/24.
Example 7: Non-DMI with EVR Configuration

In this example, each of the two cluster members, VSX1 and VSX2, is configured as follows: The VSX gateway is connected to the Internet through the external virtual router (EVR). No dedicated physical interface for the VSX gateway is needed and the VSX gateway is remotely managed. All three virtual systems connect to the external network through the EVR. Each virtual system has a direct physical connection to the internal network.
Note In a non-DMI configuration, if you have a VS from which traffic does not go through the EVR, you must use the Check Point GUI to manually create a wrp link between the VS and the EVR before you push the VS configuration to the gateway.
39
Figure 7 EVR and No DMI Configuration
VSX1
VS1 EXT VRRP IP 10.10.10.75 Provider-1 MDS VSX VRRP IP 172.16.1.75
VSX VS1
VS1 VIP 192.168.1.75 eth-s1p2
VS2
EVR
eth-s1p1
Internet
VS3
eth-s1p3 VS2 VIP 192.168.2.75 eth2 Sync eth-s1p3 VS1 EXT VRRP IP 10.10.10.75 VS3 VIP 192.168.3.75 eth3 EVR VIP 10.10.50.75 Gateway 10.50.50.25
VSX VS1
VSX VRRP IP 172.16.1.75
VS2
EVR
eth-s1p1
VS3
VS3 EXT VRRP IP 10.10.30.75 Private Internal Network 10.88.88.0/24 00068
VSX2

Table 8 EVR and No DMI Configuration
Interface VSX gateway EVR VS1 to external network Physical interface name none eth-s1p1 none Virtual IP address 172.16.1.75 10.50.50.75 10.10.10.75
40
Table 8 EVR and No DMI Configuration

Interface VS2 to external network VS3 to external network VS1 to internal network VS2 to internal network VS3 to internal network Synchronization Physical interface name none Virtual IP address 10.10.20.75
none
10.10.30.75
eth-s1p2
192.168.1.75
eth2
192.168.2.75
eth3
192.168.3.75
eth-s1p3
none
The IP address of the external gateway for the VSX cluster is 10.10.50.25 and the IP address of the gateway internal communication network is 10.88.88.0/24.
41
Overview of Configuring the VSX Cluster

After you determine the topology and interface IP addresses of the VSX gateways in the VRRP cluster, you must perform the following steps to complete the VSX cluster configuration: 1. Prepare the Nokia IP security platform. For more information, see Chapter 3, Preparing the Nokia IP Security Platform. 2. Perform the initial configuration of the VSX gateway. Configuring a cluster member is similar to configuring a single VSX gateway. The initial configuration procedures for VSX gateways in single and VRRP topologies is described in Chapter 4, Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway.
Note You must configure VRRP on an interface before you assign that interface to a VS.
3. Configure static routes on the management server. For VSX gateways, the VSX gateway, EVR, and IVR interfaces, and the main IP addresses of the external VS interfaces, must be routable from the management server through the VSX gateway interface for DMI configuration and through the EVR interface for non-DMI configuration. For VSX gateways in a VRRP cluster, the management server must be able to reach the appropriate interfaces for both cluster members. 4. Add a customer and a customer management add-on by using the management client. For more information, see Adding a Customer and a Customer Management Add-On on page 55. 5. Create the VSX gateway and optional EVR by using the management client. For more information, see Adding and Configuring the VRRP Cluster on page 56. 6. Add one or more virtual systems by using the management client. For more information, see Creating a Virtual System for the VRRP Cluster on page 67.
Note In a non-DMI configuration, if you want to add a VS from which traffic does not go through the EVR, you must use the Check Point GUI to manually create a wrp link between the VS and the EVR before you push the VS configuration to the gateway.
7. Configure routing, policy-based routing, or transparent mode on the routing instances that are created in IPSO when you create a VS. For more information about routing instances, see Multiple Routing Instances on page 84. 8. Back up your configuration on both the master and backup member as described in Backup and Restore on page 226. You must have a backup file to restore a VRRP gateway.
42
Configuring the Nokia Virtual Firewall for Check Point VSX NGX R65 Gateway
This chapter describes how to perform the initial configuration of the Nokia Virtual Firewall for Check Point VSX NGX R65 gateway. The procedures in this chapter assume that you have already installed the Check Point VPN-1 Pro/Express package on the IP security platform as described in Chapter 3, Preparing the Nokia IP Security Platform. It also assumes that your IP security platform is running IPSO 5.0. After you install the Check Point packages, you must create the management interface and perform the initial configuration of the Nokia Virtual Firewall for Check Point VSX NGX R65 gateway. The procedures for the initial configuration of the gateway are as follows: 1. Run the vsx_config utility. 2. Run the cpconfig utility (automatically called at the end of vsx_config). 3. Reboot the system.
Note Do not use Nokia Network Voyager to configure VRRP and your interfaces. Use the vsx_config utility instead.
Using the VSX Configuration Utility

The vsx_config utility uses your input to configure: Link aggregation for the firewall synchronization interface for VRRP configurations. The VSX gateway interface The sync interface for VSX cluster members VRRP on selected interfaces for VSX cluster members To answer the prompts, use the information you entered in the Deployment Planning Sheet discussed in the Check Point VPN-1 Power VSX NGX R65 guide.
43
No changes are made to the configuration until the end of the script, when you are asked to confirm your selections. If you confirm them, then the configuration changes are made. The final prompt on the vsx_config utility asks if you would like to execute the cpconfig utility. The cpconfig utility guides you through the steps of licensing and configuring the software. Before You Begin Make sure you know the following information for direct management interface (DMI) configurations: The physical interface to use for the management interface The IP address of the management interface and its default gateway Make sure you know the following information for VRRP cluster configurations: The IP address of the synchronization interface for each cluster member The names of each physical interface that you would like VRRP to monitor Router VRRP ID You can aggregate up to three interfaces. To perform the initial VSX gateway network configuration 1. Log in to the host from a console connection. 2. At the command prompt, enter vsx_config to start the configuration utility. 3. Enter y to continue. 4. If you wish to create a link-aggregated synchronization interface, type y. Otherwise, type n and skip to step 9. 5. Type y to create a link-aggregation group (LAG). 6. From the list of interfaces, select the interfaces that will make up the link aggregation group. Enter the interface you want to be the primary interface first. You can enter up to three interfaces. 7. You will now be given the opportunity to change the speed and duplex configuration of the intefaces in the link aggregation group. Make sure that the settings for each interface is identical. These settings must match the settings for the switch ports that the interfaces are connected to. When you are finished configuring the interface settings, vsx_config creates the link aggregation group. The link aggregation group is given an interface name in the form of aexxxc0: for example, ae1c0 for the first link aggregation group configured.
Note If you make a mistake while setting up link aggregation, exit vsx_config. Using Network Voyager, select Interface Configuration > Link Aggregation and correct your mistake by adding or deleting interfaces in the Link Aggregation group. If you are adding an interface, make sure you set the correct speed and duplicity first. If
44
Using the VSX Configuration Utility
you need to correct the speed/duplicity of an interface that is a member of the Link Aggregation group, you will have to delete it from the group first, correct the speed/ duplicity, and the re-add it to the group. When you are finished reconfiguring link aggregation, rerun vsx_config, but skip the link aggregation configuration by typing n when asked if you want to create Link Aggregated interfaces.
8. Type n when you are asked if you want to create a new link aggregation group. 9. At the prompt, select the logical interface to use as your management interface. 10. At the prompt, select the speed of the interface. 11. At the prompt, select half or full duplex. 12. To accept the IP address associated with the management interface, enter 1. To configure a new IP address for the management interface, enter 2, and then enter the address, network mask, and gateway address at the subsequent prompts.
Note If you change the IP address for the management interface, you must make sure a host name is assigned to that address before running cpconfig. Use the Host Address Assignment page in Network Voyager to assign a host name to the IP address. You must also manually remove the previous IP address using Network Voyager.
.Accept the current default gateway for the management interface or configure a new default gateway. 13. For non-DMI configurations, configure the IP address for the VSX gateway interface. 14. At the next prompt, enter:
n if the VSX gateway is not part of a VRRP cluster. Skip to step 24. y if the VSX gateway is part of an VRRP cluster. Continue with the rest of this procedure.
15. After confirming that you want to configure clustering on this system, select the interface to use for synchronization traffic. If you created an aggregated interface, select it (ae1c0).
Note Do not use ports on IP2250 or IP2255 ADP I/O cards for firewall synchronization traffic. The ADP I/O ports should be used for production traffic.
16. Configure the IP address for the synchronization interfacefor example, 10.10.10.10and enter the mask length.
45
Note With the exception of a link-aggregated sync interface, the sync interface is configured for 10 Mb half-duplex. If you want to change the speed or duplex mode for this interface, you must use Nokia Network Voyager or the CLI to do so on both members of the VRRP cluster.
17. At the next prompt, Do you wish to setup VRRP now (y/n) [y]?, enter y. 18. If this machine will be master, enter y. 19. From the list, select the interfaces that will be used by virtual systems and virtual routers. In DMI configurations, the VSX gateway interface is automatically configured for VRRP; in non-DMI configurations, the EVR interface is automatically configured for VRRP. The interfaces to be monitored must be identical on both VSX gateways in a VRRP cluster. You must enter the numbers in the same order on both platforms.
Note If you deselect a VLAN interface in the management GUI, you must configure it as a monitored interface again using vsx_config before you reselect it.
20. Enter the first number of the VRRP ID range. 21. If you wish to enable the auto-backup feature, type y. Otherwise type n and go to step 33. 22. At the prompt, enter the IP address of the other node of the VRRP pair. 23. At the prompt, enter the time to schedule the daily backup. 24. Review the configuration displayed on the screen. If the configuration is correct, select y and the configuration wizard applies the configuration to your current system. If you enter n, the configuration wizard gives you the option of restarting vsx_config to correct the configuration or of exiting completely without saving the configuration.
Note If you type n to discard the configuration and start again, all configuration is discarded except the link aggregation configuration. When you rerun vsx_config, skip the link aggregation configuration portion of vsx_config since link aggregation is already configured. If you make an error when initially configuring link aggregation, you can correct the error before you rerun vsx_config by using Network Voyager. Select Interface Configuration > Link Aggregation and correct your mistake by adding or deleting interfaces in the Link Aggregation group. If you are adding an interface, make sure you set the correct speed and duplicity first.
46
Using the cpconfig Utility
Using the cpconfig Utility

The cpconfig utility is automatically started by the vsx_config utility. The cpconfig utility guides you through the steps of licensing the software and generating security certificates for secure internal communication (SIC) between the MDS and the Nokia Virtual Firewall for Check Point VSX gateway. When the system is rebooted after you have run cpconfig, the firewall starts. By default, a firewall policy is loaded that does not allow browser access to the gateway. If you want to have immediate access to Nokia Network Voyager after the gateway is rebooted, then do the following: Enable HTTPS service on the platform as described in Enabling HTTPS on page 44. Answer n when cpconfig asks whether to reboot the system or not. The utility will then ask if you want to install an policy that allows HTTPS access. Answer y to this prompt.
Note You must have a hostname assigned to the VSX gateway IP address before running cpconfig. If you have changed the VSX gateway IP address from the default address when you ran vsx_config, you must assign a hostname to that address. Use the Host Name Assignment page in Nokia Network Voyager to do so.
To complete the configuration by using the cpconfig utility 1. After you finish the initial network configuration, the following prompt appears:
Do you wish to execute cpconfig now?
Enter y to configure the VSX software and finish the gateway configuration process. If you exit the configuration process, you can enter cpconfig at the command prompt any time to finish the initial configuration. 2. Read the license agreement, and then enter y to accept it. 3. If you plan to use two VSX gateways in a VRRP cluster, enter y in response to the following prompt:
Would you like to install a Check Point clustering product (CPHA, CPLS or State Synchronization)? (y/n) [n]?
Otherwise, accept the default value of n. 4. Enter y to add a license and fill in the license information, or enter n to complete the license information later. 5. As part of configuring the certificate authority, type random text at a random pace until you hear a beep. The timing latency between your keystrokes is used to generate cryptographic data. VPN-1 VSX uses certificates for secure internal communication (SIC) between the MDS and the VSX gateway.
47
6. Enter an activation key to authenticate secure communication between VSX components. Enter and re-enter the activation key. You need to enter this key later from the Provider-1 Client to initialize trust between the MDS and the VSX gateway. 7. You will be asked to reboot the system. If you answer No or n, you will be asked if you wish to open HTTPS access for Nokia Network Voyager. You will then have to reboot manually from the command prompt. If you enter Yes or y, your system will be rebooted.
Note If you do not activate HTTPS access to Network Voyager, you will have no Network Voyager access after the reboot until you install a policy on the gateway that accepts Network Voyager access.
Managing the VSX Gateway

You manage and monitor the VSX gateway by using the VSX GUI applications that you install on the Microsoft Windows PC, as described in Chapter 6, Installing the VSX Management Client. The command-line reference chapter in the Check Point VPN-1 Power VSX NGX R65 guide describes the firewall commands you can issue from the IPSO shell to help you monitor the VSX gateway. Nokia recommends limited use of the CLI and the Nokia Network Voyager for configuration that is not described in this guide or the Check Point guide. For information about how to change the link speed or duplex settings for an interface, see Changing Physical Interface Properties on page 43.
48
Installing the Management Server
You can use either Provider-1/SiteManager-1 or SmartCenter to manage your Nokia gateways. Provider-1 allows you to centrally configure, manage and monitor VSX gateways and other Check Point enforcement modules from a single console. The following versions of management software are supported: Provider-1/SiteManager-1 VSX NGX R65 SmartCenter VSX NGX R65 The standard NGX R65 version of Provider-1 or SmartCenter can manage both standard VPN-1 and VPN-1 Power VSX NGX R65 gateways.
Installing Management Servers

The installation steps to install a management server depends on whether the server is a SmartCenter or Provider-1 server and on what platform it is installed on. Table 9 shows in which manuals you can find the installation instructions for you management server and platform combination. Except where otherwise noted, all manuals listed are available at the Check Point Downloads Web site.
49
Installing the Management Server
Table 9 Supported Platforms and Installation Documentation

Software Version Provider-1/SiteManager-1 NGX R65 Platforms SecurePlatform Solaris 8, 9, 10 Installation Documentation Provider-1/SiteManager-1 Getting Started Guide for VSX NGX R65
Provider-1/SiteManager-1 VPN-1 Power VSX NGX R65 SmartCenter VSX NGX R65
Solaris 2.8 Solaris 2.9
Provider-1/SiteManager-1 Getting Started Guide for VPN-1 Power VSX NGX R65
IPSO SecurePlatform Solaris 8, 9, 10 Linux Red Hat Enterprise 3.0 Windows server
Check Point for Nokia IPSO Getting Started Guide VSX NGX R65. Available from Nokia. Enterprise Security Product Suite for VSX NGX R65
SmartCenter VPN-1 VSX NGX R65
SecurePlatform
SecurePlatform VPN-1 Power VSX NGX R65Guide
50
Installing the VSX Management Client
This chapter describes how to install the Provider-1 Client and the SmartConsole and lists the next steps you take to set up your Nokia Virtual Firewall for Check Point VSX NGX R65 environment. The VSX management clients provide the interfaces to manage the VSX gateway. If you are using Provider-1, you must install both the Provider-1 and SmartConsole GUIs on the management client. If you are using SmartCenter, you install only SmartConsole. You can install the management client applications on as many Microsoft Windows desktops as you desire. The procedures in this chapter assume that you downloaded the Check Point management client software to an FTP server. Depending on the version of your management server and platform, you might also install the management client from CD. See the Check Point documentation for information on how to do so. To install the management client applications on a Windows platform 1. Close any Check Point applications running on the Windows platform. 2. Copy the installation files for Provider-1 GUI and SmartConsole from the FTP server to a temporary folder on the Windows computer. 3. Unzip the SmartConsole installation file and double-click setup.exe. The Installation Wizard opens. Accept the default values by clicking Next. 4. After the SmartConsole software installation completes, unzip the Provider-1 installation file and double-click setup.exe. The Installation Wizard opens. Accept the default values by clicking Next.
Testing Connectivity
The management client connects to the Provider-1 Server (MDS). The MDS must contain the IP addresses of all management clients allowed to connect to it. During the MDS configuration, you specified the IP address of the management clients that you use to connect to the MDS.
51
To test connectivity 1. Double-click the appropriate icon to launch the Provider-1 client. The login screen appears. 2. Enter the administrative username and password you specified when you configured the management server. 3. In the Server field, enter the IP address of the Server. Select the Read Only option to allow others access to the SmartCenter Server while you view information. 4. Click OK. A successful connection indicates that you installed the Client and Server correctly.
Next Steps
When you successfully install the VSX gateway, the Provider-1 MDS, and the management clients, you can configure the objects in the Nokia Virtual Firewall for Check Point VSX environment. The next steps to take are as follows: 1. Create a customer for VSX gateway interface and EVR management. 2. Define a customer management add-on (CMA) for the customer. 3. Add the VSX gateway.
Note When you add the VSX gateway, you must establish trust between the MDS and the VSX gateway. You configured the activation key in step 6 on page 48. Check the connectivity and routing from the management server to the VSX gateway interface and EVR interfaces.
4. Configure the external virtual router or virtual switch.

Note When you configure a virtual switch, the interfaces are automatically enabled.
5. Configure the management virtual system. 6. Create a customer and CMA (or create a new CMA in the original customer) for each VS that is independently managed. The Check Point VPN-1 Power VSX NGX R65 guide contains detailed instructions about how to complete each of the required steps. The Check Point guide also contains instructions about how to: Add and edit customers Define and edit virtual systems and virtual routers
52
Next Steps
Define policies Install policies Obtain status information about the VSX deployment
53
54
Configuring the VSX VRRP Cluster
This chapter describes how to configure the Check Point VPN-1 Power VSX NGX R65 gateways in a VRRP cluster. This chapter assumes that you already successfully performed the initial configuration on both Check Point VPN-1 Power VSX NGX R65 gateways, and that you completed the installation for the Provider-1 MDS and the management clients. This chapter covers: Adding a Customer and a Customer Management Add-On Adding and Configuring the VRRP Cluster Creating a Virtual System for the VRRP Cluster
Note The procedures and examples in the above subsections assume that you are using NGX R65 management.
Configuring VRRP Active-Active Mode Backing Up Your VRRP Configuration
Adding a Customer and a Customer Management Add-On

Before you can add a Check Point VPN-1 Power VSX NGX R65 cluster, you must create a customer and a customer management add-on (CMA). The procedures are the same whether you are configuring a standalone Check Point VPN-1 Power VSX NGX R65 gateway or a VRRP cluster.
Note Nokia recommends that you create a separate CMA for managing the VSX gateway interface and EVR's.
To add a customer and a CMA 1. Log on to the client on the Windows system. 2. From the Manage menu, click New Customer to run the New Customer Wizard.
55
3. Complete the required information to add a new customer. For information about customers and CMAs, see the Provider-1 documentation available on the Check Point Web site. 4. Choose to define the CMA and click Next.
5. Enter the required CMA information.

Note The IP address you use for the CMA is a virtual IP address that is typically in the same subnet as the MDS management interface. Make sure the CMA IP address is unique and is not used by any host.
If you do not enter any license information, you can still complete the configuration. Check Point software comes with a 15-day evaluation license. 6. Start the CMA.
Adding and Configuring the VRRP Cluster

You can use the New VSX Cluster wizard in the Provider-1 client to configure a VRRP cluster. After you add the cluster, you must configure the VSX gateway interface and EVR for each cluster member.
56
Note You must first launch SmartDashBoard from the Provider-1 client and then follow the procedures below.
To add the VRRP cluster 1. From the main Provider-1 Client window, right-click the customer you created and select New Check Point > VPN-1 VSX > Cluster.
2. From the Set the VSX Cluster Version drop-down list, select VPN-1 Power VSX NGX R65.
57
3. From the Select the VSX Cluster Platform drop-down list, select Nokia VRRP.
58
4. Add each member to the cluster.

Note Cluster member names are usually the host names of the cluster member machines.
59
5. Establish trust with each cluster member.

Note The addresses you configure on the cluster members must be routable from the management server.
60
6. Optionally, select the interfaces on the VSX gateway to support VLAN.
61
7. Add the Sync interface

Note Select the interface that you identified as the sync interface when you ran vsx_config.
62
8. Optional, Add management access rules
63
9. Optionally, configure an EVR or virtual switch on each cluster member.

Note You can create more virtual routers and virtual switches using the Check Point GUI. See the Check Point VPN-1 Power VSX NGX R65 User Guide for more information.
Note You cannot implement VRRP-HA active-active mode on a VS which is connected to a virtual router (either EVR or IVR). The external and internal interfaces of a VS should be connected to the physical interfaces. However, VSs in the same VSX gateway that are not configured in VRRP-HA active-active mode can be connected to an EVR or IVR.
64
Note If you are configuring a non-dmi typology, you must select the management interface. This is important since you cannot configure the non-dmi typology with a management interface afterwards.
.
65
10. Click Finish on the VSX Cluster Definition Completed screen to create the VSX cluster. The Creating VSX Cluster window opens.
66
Creating a Virtual System for the VRRP Cluster

1. Right click the customer and select New Virtual System.
2. Enter a name for the VS. 3. From the VSX Gateway/Cluster drop-down list, select the VSX cluster you configured.
67
4. Add the main interface and a wrp link to the EVR, if you have configured one.
68
Note For the main IP address, use the VS to EVR IP address
69
5. Enter the IP address of the VS for each Cluster member.

Note The IP addresses you enter in this step must be routable from the management server.
70
6. (Optional) Configure the default gateway, which can be an IP address or a virtual router.
71
7. Shows compete configuration of a virtual system with two interfaces and a default route.
72
Configuring VRRP Active-Active Mode
8. After the VS is successfully completed, return to the main Provider-1 Client screen to add other virtual systems, if necessary.
Configuring VRRP Active-Active Mode

The default configuration for a VRRP cluster is active-passive mode. In this mode, the only active VSs are in the master member; if an interface in the master member fails, all VSs fail over to the backup member. In active-active mode, active VSs can be in both the master and backup. If an interface for an active VS fails, only the interfaces for that VS fail over to the other VRRP member. Figure 8 illustrates an active-active configuration.
73
Figure 8 VRRP Active-Active Mode Example
When you configure a VRRP cluster, all interfaces on which VRRP is configured in the master member are given a priority of 100 and all interfaces in the backup member are given a priority of 95. To make a VS active in the backup member rather than the master member, you must give the interfaces for VS instance in the master member a lower priority than the interfaces for VS instance in backup. You must also ensure that the VS interfaces are monitoring only each other, and not other interfaces.
74
Backing Up Your VRRP Configuration
To achieve the configuration shown in Figure 8, you would: 1. Specify that eth1, eth2, eth3, and eth4 are to be configured for VRRP when you run vsx_config on the member gateways. 2. Create the VRRP cluster and VSs using the management GUI as described in the preceding sections of this chapter. Although Figure 8 does not show this, you can configure VLAN on the VRRP interfaces. Do not create an EVR for the VSs. In active-active mode, the VSs must be connected directly to the physical interface and not to virtual routers. You can, however, configure an EVR for use by other interfaces. 3. Install the configuration and policy on both VRRP members. 4. Connect to the master gateway using Network Voyager. Using the VRRP Configuration page (Virtual Systems tab> Configuration for Default (VSX gateway) instance > VRRP), change the VRRP priority for interfaces eth3 and eth4 to 90. 5. For each interface, including the VSX gateway interface, in the master and backup gateways, correct the list of interfaces to be monitored by setting the interfaces that should not be monitored to off. For example: For eth1, only eth2 should be monitored (and vice versa). Remove all other monitored interfaces by setting them to off. For eth3, only eth4 should be monitored (and vice versa). Remove all other monitored interfaces by setting them to off. For eth1sp1 (the VSX gateway interface), no other interfaces should be monitored, so remove all monitored interfaces by setting them to off.
Backing Up Your VRRP Configuration

When you have completed your VRRP configuration or whenever you make a change to the configuration, you should back up the configuration on both the master and backup gateways as described in Backup and Restore on page 226. You cannot restore an VSX gateway by simply installing the existing configuration saved on the management server. You must first restore the configuration from the backup file as described in Backup and Restore on page 226 and then install the configuration from the management server.
75
76
Reconfiguring the Nokia Virtual Firewall for Check Point VSX Gateway
This chapter describes how to use the vsx_config command to add interfaces to a VRRP configurations.
Note Re-run the vsx_config script for the instances specified in this chapter only. Complete all other configuration through the Check Point GUI.
Adding Interfaces to VRRP Configurations

Complete the following procedure to add interfaces to VRRP configurations. The following situations require you to add an interface to the monitoring list: You want to add an interface that wasnt allocated during the initial configuration A new interface was added to the system A VS has been deleted and you want to reallocate its interfaces. When a VS is deleted, VRRP monitoring is turned off its interfaces, unless the interface is a VLAN interface shared by other VSs. To add an interface monitored by VRRP, you must: Follow the procedure in To add interfaces to the platform on page 78 if you are adding new interfaces to the system. Configure the interface for VRRP as described in To configure VRRP on an interface on page 78. Add the interface to system interfaces list in the Check Point GUI as described in To add interfaces using SmartCenter on page 79 or To Add Interfaces Using Provider-1 on page 81.
77
Note For a VS to use an interface, it must be allocated in the system interfaces list. This list is created during initial configuration of the VSX object. Any addition or removal of interfaces must be reflected manually in that list.
Add the interfaces to an existing or new VS. If you are using active-active mode, configure the interfaces as described in Configuring VRRP Active-Active Mode on page 73. To add interfaces to the platform 1. Plug in the network interface card. 2. Use Network Voyager to set the speed and duplex mode for the interfaces: To configure VRRP on an interface 1. Log on to the host from a console connection 2. At the prompt, enter vsx_config to start the configuration utility. The console displays the following message:
Welcome to the VSX reconfiguration utility. This utility will
permit you to reconfigure parts of the system. Choose a configuration item: ---------------------------------------------------------------------1. Configure VRRP on Additional Interface 2. Show VSX Summary 3. Modify Speed/Duplexity on interfaces 4. Change starting VRID for new Virtual Ethernets. 5. Exit ---------------------------------------------------------------------Note: Configuration changes are automatically saved
3. Enter 1 to configure VRRP on the interface.

Note The console displays a list of interfaces that have VRRP configured on them. Check the list to make sure you are not adding interfaces that are already configured for VRRP before you enter y to continue with the process.
4. Enter y when you see the following message:

Do you wish to continue (y/n) [y]?
78
5. Enter the new interfaces to configure for VRRP when you see the following message:
From the list below select the additional interfaces to be used for Virtual Systems and Virtual Routers: ----------------------------------------------------------------------1) 2) 3) 4) eth1c0 eth2c0 eth4c0 Configure all available interfaces
Enter the list of interfaces (separated by spaces):
For example, enter 1 2 6. If you are installing a new network card into an IP1220 or IP1260, you need to change the logical interface names so that they follow the naming convention of the existing interfaces. For example, change eth-s1/s1p1c0 to: e-s1s1p1c0 Using Network Voyager, select the logical interface on the Interfaces Configuration page (Default > Interfaces) and then change the logical name in the Logical name field. You can now use either Provider-1 or SmartCenter to add the interfaces to the system interfaces list. Complete one of the following procedures. To change the virtual router identification of an interface 1. Choose option 4. 2. Follow the onscreen instructions. To add interfaces using SmartCenter 1. Edit the VSX cluster properties. 2. Go to the System Interfaces tab and click the name of each interface you configured VRRP on.
79
3. Click OK to commit the changes. 4. If the interface does not appear on the list, this means the interface was added after initial setup. To add the interface, click Add. The following dialogue box appears.
80
5. Enter the name of the interface you are adding and click OK to commit the changes. 6. Install the configuration on the gateways and reboot. To Add Interfaces Using Provider-1 1. Edit VSX Cluster properties
2. Go to the System Interfaces tab and check the box for each interface you configured VRRP on. 3. Click OK to commit the changes. 4. If the interface does not appear on the list, this means the interface was added after initial setup. To add the interface, click Add. The following dialogue box appears.
81
5. Enter the name of the interface and click OK to commit the changes. 6. Install the configuration on the gateways and reboot.
82
Configuring Routing and Routing Services
This chapter describes in detail how to configure the following routing protocols: Multiple Routing Instances OSPF RIP PIM IGMP BGP Static Routes Route Aggregation Route Rank Route Redistribution Inbound Route Filters Nokia Virtual Firewall for Check Point VSX NGX R65 also supports an option to configure the gateway to ignore the default route. For more information about this option, see Configuring Gateway to Ignore Default Route on page 86. For more information about policy routes, which you can also configure using Nokia Network Voyager, see Policy-Based Routing on page 217.
Note The Nokia Virtual Firewall for Check Point VSX NGX R65 Feature Pack provides optional advanced routing functionality. For more information, contact your Nokia sales representative.
Note You must install the license key supplied by Nokia to use individual dynamic routing protocols, including OSPF, RIP, PIM, and BGP, as well as transparent mode. For more information on how to install a license key, see Installing Nokia License Keys on page 45.
83
Multiple Routing Instances

The multiple routing instances (MRI) feature lets you isolate different virtual systems from each other that are connected to a Nokia Virtual Firewall for Check Point VSX NGX R65 gateway through tunnels that form a virtual private network. Each virtual system is configured to form an instance that terminates at the gateway. Each instance has its own separate routing table and corresponding forwarding table. In this way, information about each virtual system is not exposed to other virtual systems connected to the same Nokia Virtual Firewall for Check Point VSX gateway. The MRI feature supports OSPF, RIP, PIM, BGP, Static Routes, Route Aggregation, Inbound Route Filters, and Route Redistribution. The MRI feature supports only IPv4 interfaces.
Creating a Routing Instance

Although you use Network Voyager to configure instances, you must use Check Point Provider1 to create individual instances. To create an instance, you must first create a customer and customer management add-on (CMA) and Nokia Virtual Firewall for Check Point VSX gateway or cluster. For more information about how to create a CMA see Adding a Customer and a Customer Management Add-On on page 55. For more information about initial configuration of a Nokia Virtual Firewall for Check Point VSX gateway, see Using the VSX Configuration Utility on page 43. For more information about creating a Nokia Virtual Firewall for Check Point VSX cluster, see Adding and Configuring the VRRP Cluster on page 56. You can now create individual multiple routing instances, which essentially means using Provider-1 to create virtual systems. For more information on how to create a VS, see Creating a Virtual System for the VRRP Cluster on page 67. After you create one or more virtual systems using Provider-1, you can log on to Network Voyager and configure dynamic routing for the instances, that is, VSs, you created. When you log onto the Network Voyager, click the Virtual Systems tab to take you a page that displays all the instances, that is, virtual systems you created using Provider-1. From that page, you click on links for each instance to configure each individual virtual system separately.
Note Network Voyager has an option for creating routing instances. Although you can create a routing instance this way, the instance created this way cannot be used by the Check Point VSX application. Use the Check Point GUI to create a VS, which automatically creates a routing instance.
84
Multiple Routing Instances
Configuring a Routing Instance

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. This page takes you to the main configuration page for that instance. The specific instance name appears at the top of the page. 3. To configure a specific dynamic routing protocol, including RIP, OSPF, BGP or PIM, click the link for that protocol in the Routing section. This action takes you to the configuration page for that protocol for the specified instance. For more information on how to configure specific routing protocols, see Configuring OSPF on page 90, Configuring RIP on page 105, PIM on page 110, and BGP on page 130.
Note If you do not see the links for the dynamic routing protocols, you have not installed the license key for the protocols. For more information on how to install a key, see Installing Nokia License Keys on page 45.
Note You must also enable RIP and BGP through the Provider-1 MDS. For more information, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102 and Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
4. You can also use the main page for the specific routing instance to configure all other features, including Static Routes, Transparent Mode, route aggregation, Inbound Route Filters, and Routing Options. You can also use the Show Configuration Summary page to configure specific routing protocols for an instance. From the main configuration page for a specific multiple routing instance, click the Show Configuration Summary link. That page displays a summary of configured routing protocols and options and lets you make configuration changes.
Monitoring a Routing Instance

1. Click the Virtual Systems tab. 2. Click the Monitor in the tree view next to the name of the routing instance for which you want to view interfaces and routing information and statistics. This action takes you to a monitor page for that instance. The page includes links to monitoring pages for enabled routing protocols, a Route monitoring page, an Interfaces monitoring page, a Forwarding Table page, and a Transparent Mode monitoring page.
85
Deleting a Routing Instance

Do not use Network Voyager to delete a routing instance that was created by the Check Point GUI. If you wish to delete a routing instance, use the Check Point GUI to delete the VS associated with the instance.
Configuring Gateway to Ignore Default Route

Nokia Virtual Firewall for Check Point VSX NGX R65 supports an option that lets you configure the gateway to ignore the default route. By default, the Provider-1 client GUI installs a default route for each VS that points to the EVR after you initially configure the gateway. If you do not want the gateway to use default route for a specific VS, complete the following procedure. Configuring the gateway to ignore the default route means that the IPSO routing deamon removes the default route if it is installed. 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure 3. Click the Routing Options link. 4. Click on next to Ignore IPv4 Default Route. 5. Click Apply. 6. Click Save to make your changes permanent.
OSPF
OSPF is a link-state routing protocol based on the Dijkstra (or shortest path first) algorithm. OSPF is an interior gateway protocol (IGP) that distributes routing information between routers in a single autonomous system. OSPF chooses the least-cost path as the best path. Suitable for complex networks with a large number of routers, OSPF provides equal-cost multipath routing where packets to a single destination can be sent using more than one interface. OSPF groups networks into areas. Routing information passed between areas is summarized and allows significant potential reduction in routing traffic. OSPF uses four different types of routes: Intra-area Interarea Type 1 external Type 2 external Intra-area paths have destinations within the same area; interarea paths have destinations in other OSPF areas; and autonomous system external (ASE) routes are routes to destinations external to the autonomous system (AS). Routes imported into OSPF as Type 1 routes are supposed to be from IGPs whose metrics are directly comparable to OSPF metrics. When a routing decision is being made, OSPF adds the internal cost to the AS border router to the external metric. Type 2 ASEs are used for routes whose metrics are not comparable to OSPF internal metrics. In this
86
OSPF
case, only the external OSPF cost is used. In the event of ties, the least cost to an AS border router is used. OSPF areas are connected by the backbone area, the area with identifier 0.0.0.0. All areas must be logically contiguous, with the backbone being no exception. To permit maximum flexibility, OSPF allows the configuration of virtual links, enabling the backbone area to appear contiguous despite the physical reality. All routers on a link must agree on the configuration parameters of the link. 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. Misconfigurations prevent adjacencies from forming between neighbors, and routing black holes or loops can form.
Types of Areas
Routers using OSPF send packets called Link State Advertisements (LSA) to all routers in an area. Areas are smaller groups within the AS that you can design to limit the flooding of an LSA to all routers. LSAs do not leave the area from which they originated, thus increasing efficiency and saving network bandwidth. You must specify at least one area in your OSPF networkthe backbone area, which has the responsibility to propagate information between areas. The backbone area has the identifier 0.0.0.0. You can designate other areas, depending on your network design, of the following types: Normal AreaAllows all LSAs to pass through. The backbone is always a normal area. Stub AreaStub areas do not allow Type-5 LSAs to be propagated into or throughout the area and instead depends on default routing to external destinations. You can 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 Stubby Area)Allows the import of external routes in a limited fashion using Type-7 LSAs. NSSA border routers translate selected Type-7 LSAs into Type-5 LSAs which can then be flooded to all Type-5 capable areas. Configure an area as an NSSA if you want to reduce the size of the routing table, but still want to allow routes that are redistributed to OSPF. It is generally recommended that you limit OSPF areas to about 50 routers based on the limitations of OSPF (traffic overhead, table size, convergence, and so on). All OSPF areas must be connected to the backbone area. If you have an area that is not connected to the backbone area, you can connect it by configuring a virtual link, enabling the backbone area to appear contiguous despite the physical reality.
Note If you need to connect two networks that both already have backbone areas and you do not want to reconfigure one to something other than 0.0.0.0, you can connect the two backbone areas using a virtual link.
87
Each router records information about its interfaces when it initializes and builds an LSA packet. The LSA contains a list of all recently seen routers and their costs. The LSA is forwarded only within the area it originated in and is flooded to all other routers in the area. The information is stored in the link-state database, which is identical on all routers in the AS.
Authentication
The OSPF protocol exchanges can be authenticated. Authentication guarantees that routing information is accepted only from trusted routers. A variety of authentication schemes can be used, but a single scheme must be configured for each interface. This enables some links to use much stricter authentication than others. The currently supported authentication schemes are: null, simple password, and MD5. Null authentication does not authenticate packets. Simple password authentication uses a key of up to eight characters. MD5 algorithm uses a key of up to 16 characters. The simple password scheme provides little protection because the key is sent in the clear, and it is possible to capture packets from the network and learn the authentication key. The MD5 algorithm provides much stronger protection, as it does not include the authentication key in the packet. Instead, it provides a cryptographic hash based on the configured key. The MD5 algorithm creates a crypto checksum of an OSPF packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead it contains a crypto-checksum called the digest. The receiving router performs a calculation using the correct authentication key and discards 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 assurance that routing data originated from a router with a valid authentication key.
CLI Support
IPSO 5.0 supports CLI commands for configuring and monitoring OSPF for a routing instance, that is, virtual system. To configure OSPF, use the following syntax before any specific command:
set instance <instance_name>
To use the show commands for OSPF, use the following syntax:
show instance <instance_name>
For more information about how to use CLI, see the Nokia IPSO CLI Reference Guide.
Virtual IP Address Support for VRRP

Nokia Virtual Firewall for Check Point VSX supports the advertising of the virtual IP address of the VRRP virtual router. You can configure OSPF to advertise the virtual IP address rather than the actual IP address of the interface. 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
88
OSPF
the new master. A traffic break might occur during the time it takes both the VRRP and OSPF protocols to learn the routes again. The larger the network, the more time it would take OSPF to synchronize its database and install routes again. You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address. For more information on enabling the advertising of a virtual IP address when running OSPF, see Configuring OSPF on page 90, step 15.
Note Nokia also provides support for BGP and PIM, both sparse mode and dense mode, and RIP to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
OSPF Virtual Link and VRRP

If you implement VRRP when an OSPF virtual link is configured between the Nokia Virtual Firewall for Check Point VSX gateway and either an internal or external router, you must use the same router ID, an IPv4 address, on the external virtual router (EVR) and virtual system of both the master and the backup. If you do not use the same router ID for the EVR and VS on both the master and backup members of the VRRP pair, after a VRRP failover, the virtual link is not established because the router that is the endpoint of the virtual link has two different router IDs, one for the master and another for the backup.
Alternate Area Border Router Behavior

Nokia supports the implementation of Area Border Router (ABR) behavior as outlined in the internet draft of the Internet Engineering Task Force (IETF). The definition of an ABR in the OSPF specification as outlined in RFC 2026 does not require a router with multiple attached areas to have a backbone connection. However, under this definition, any traffic destined for areas that are not connected to an ABR or that are outside the OSPF domain is dropped. According to the Internet draft, a router is considered to be an ABR if it has more than one area actively attached and one of them is the backbone area. An area is considered actively attached if the router has at least one interface in that area that is not down. Rather than redefine an ABR, the Nokia implementation includes in its routing calculation summary LSAs from all actively attached areas if the ABR does not have an active backbone connection, which means that the backbone is actively attached and includes at least one fully adjacent neighbor. You do not need to configure this feature; it functions automatically under certain topographies. OSPF uses the following types of routes: Intra-areaHave destinations within the same area. InterareaHave destinations in other OSPF areas.
89
Autonomous system external (ASE)Have destinations external to the autonomous system (AS). These are the routes calculated from Type-5 LSAs. NSSA ASE RouterHave destinations external to AS. These are the routes calculated from Type-7 LSAs. All routers on a link must agree on the configuration parameters of the link. 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. Misconfigurations prevent adjacencies from forming between neighbors, and routing black holes or loops can form.
Configuring OSPF
1. Use the Provider-1 GUI to configure the Ethernet interface. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure OSPF. 4. Click the OSPF link in the Routing section. 5. (Optional) This step is encouraged so that the ID is not tied to an address. Enter the router ID in the Router ID text box. 6. (Optional) If you have new OSPF areas to enter, enter the new OSPF area name in the Add New OSPF Area text box; then click Apply. Repeat this step for each new area. Area 0.0.0.0 is already defined as the backbone area. 7. (Optional) If some of the defined areas are stub areas: a. Click yes for the Stub Area for each area, then click Apply. b. Enter the cost for the default route to originate into the stub area in the Cost for default stub area route text box. c. Click Apply. This is not an option for the backbone area. 8. (Optional) If some of the stub areas are totally stubby areas: a. Click yes in the Totally Stubby Area field for each stub area. b. Click Apply. This disallows the stub area entry point from advertising interarea routes and summaries. 9. (Optional) If some of the defined areas are not so stubby areas (NSSA): a. Select NSSA in the area type drop-down box. b. Click Apply. c. Configure additional parameters that appear as described in Table 25.
90
OSPF
10. (Optional) For each summary to define: a. Enter the network prefix summary in the Add new address range: prefix text box, and enter the length of the subnet mask (in bits) in the Mask Length text box. b. Click Apply. This procedure is useful for decreasing the number of prefixes advertised into the backbone. 11. (Optional) For each summary you do not want to define, click off in the Restrict section where the network prefix summary is defined 12. Click Apply. 13. (Optional) To add a new stub network: a. Enter the prefix in the Add new stub network: Prefix text box. b. Enter the mask length in the Mask length text box. c. Click Apply. 14. Assign the appropriate area to each interface: a. Click the appropriate area in the drop-down list for each interface; then click Apply. This completes configuring an interface with the default parameters. 15. If VRRP is enabled on a physical interface, click On next to the Virtual Address field to enable OSPF on the virtual IP address associated with this interface; then click Apply.
Note Do not enable the option to advertise the virtual IP address on a wrp interface. If VRRP is not configured on an interface, do not enable the option to advertise the virtual IP address for that interface.
16. (Optional) For the configuration parameters for each interface to change: a. Enter a new hello interval (in seconds) in the Hello Interval text box; then click Apply. The hello interval must be the same for all routers on the link for them to become adjacent. b. Enter a new dead interval (in seconds) in the Dead Interval edit box; then click Apply. The router dead interval must be the same for all routers on the link for them to become adjacent. c. Enter a new cost metric in the OSPF Cost text box for each interface; then click Apply. d. Enter a new designated router priority (0-255) in the Election Priority text box; then click Apply e. Click On to make the interface operate in Passive mode; then click Apply. f. For simple authentication, select Simple from the AuthType drop-down list; then click Apply. Enter the password in the Password text box; then click Apply.
91
g. For MD5 authentication, select MD5 from the AuthType drop-down list; then click Apply. In the add MD5 key field, enter the new MD5 key ID (in the Key Id text box) and MD5 password (in the MD5 Secret text box); then click Apply. 17. To make your changes permanent, click Save. Table 10 describes 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.
Table 10 NSSA (Not So Stubby Area) Parameters
Parameter Translator Role Description Specifies whether this NSSA border router will unconditionally translate Type-7 LSAs into Type-5 LSAs. When role is Always, Type-7 LSAs are translated into Type-5 LSAs regardless of the translator state of other NSSA border routers. When role is Candidate, this router participates in the translator election to determine if it will perform the translations duties. If this NSSA router is not a border router, then this option has no effect. Default: Candidate. Specifies how long in seconds this elected Type-7 translator will continue to perform its translator duties once it has determined that its translator status has been assumed by another NSSA border router. This field appears only if an area is defined as an NSSA with translator role as Candidate. Default: 40 seconds. Specifies if summary routes (summary link advertisements) are imported into the stub area or NSSA. Each summary link advertisement describes a route to a destination outside the area, yet still inside the AS (i.e. an interarea route). These include routes to networks and routes to AS boundary routers. Default: On. Enter a cost associated with the default route to the NSSA. Specifies the route type associated with the Type-7 default route for an NSSA when routes from other protocols are redistributed into OSPF as ASEs. If a redistributed route already has a route type, this type is maintained. If summary routes are imported into an NSSA, only then a Type7 default route is generated (otherwise a Type-3 default route is generated). This field appears only if an area is defined as an NSSA into which summary routes are imported. The route type can be either 1 or 2. A type 1 route is internal and its metric can be used directly by OSPF for comparison. A type 2 route is external and its metric cannot be used for comparison directly. Default: 1
Translator Stability Interval
Import Summary Routes
Cost for Default Route Default Route Type
92
OSPF
Table 10 NSSA (Not So Stubby Area) Parameters

Parameter Redistribution Description Specifies if both Type-5 and Type-7 LSAs or only Type-7 LSAs will be originated by this router. This option will have effect only if this router is an NSSA border router and this router is an AS border router. Default: On An NSSA border router that performs translation duties translates Type-7 LSAs to Type-5 LSAs. An NSSA border router can be configured with Type7 address ranges. Use these ranges to reduce the number of Type-5 LSAs. Many separate Type-7 networks may fall into a single Type-7 address range. These Type-7 networks are aggregated and a single Type-5 LSA is advertised. By definition, a Type-7 address range consists of a prefix and a mask length. Note: To prevent a specific prefix from being advertised, select On in the Restrict field next to the entry for that prefix.
Type 7 Address Ranges
Examples of OSPF Configuration in a VRRP Setup

The following three examples show how to configure OSPF in a VRRP setup with: An external virtual router and an internal virtual router Only an external virtual router No virtual router, only a virtual system You use Check Point Provider-1 GUI to configure the interfaces and create the virtual routers and virtual systems, and you then log on to Network Voyager for each Nokia appliance to complete configuration of OSPF for each virtual system. In these example, you disable anti-spoofing on both the internal and external interfaces of virtual routers and VS. Use Check Point SmartDashboard to ensure that anti-spoofing is disabled on those interfaces. You must also make sure routing propagation is disabled. Log on to SmartDashboard, click the link for the VS and then click the Topology tab. Highlight and click the interface for the VS. This action displays the Interface Property window. Click the Topology tab, and make sure the propagate route to adjacent virtual routers box is not checked. Uncheck the box if it is checked.
Example 1: OSPF with an EVR and a VS in a VRRP Setup

In the following example Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair, which you configure as follows: Enable OSPF on the EVR physical interface in Area 0 Enable OSPF on the VS physical interface in Area 1 Enable OSPF on the wrp, that is, virtual point-to-point (vpp), interfaces between the EVR and the VS in area 0
93
Figure 9 OSPF and VRRP Configuration with an EVR and VS

Area 0
Nokia Platform D
Area 1
24.58/30 24.57/30 Nokia Platform B 24.45/30

24.49/30 e4
24.46/30
Nokia Platform C
24.50/30 e1
24.53/30 e2 24.54/30 e3 Nokia Platform E

00340
Nokia Platform A
In Figure 9 above: Nokia platforms A and E are gateways Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair. Each member of the pair is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A and B are in the backbone area. Nokia Platform E is in Area 1.
Configuring OSPF on the Nokia Virtual Firewall for Check Point VSX VRRP Pair
1. Use the Provider-1 GUI to configure an EVR and a VS on each member of the VRRP pair, that is, on Nokia platforms C and D. 2. Log on to Nokia Network Voyager sessions and complete the following steps on each member of the VRRP pair, Nokia platforms C and D. 3. Click the Virtual Systems tab. 4. Click Configuration next to the instance name for the EVR. 5. Click the OSPF link in the Routing section. 6. In the Area drop-down list for the e1 interface, select BACKBONE; then click Apply. 7. Click on next to the Virtual Address field to advertise the VRRP virtual IP address for this interface; then click Apply. 8. In the Router ID text box, enter the virtual IP address of the EVR; then click Apply. 9. For the wrpj interface that connects the EVR to the VS in Area 0, select BACKBONE in the Area drop-down list for that interface.
94
OSPF
Caution Do not enable the virtual address option for the wrpj interface. This option is not supported on wrp interfaces.
10. Return to Nokia Voyager, and click the Virtual Systems tab. 11. Click Configuration next to the instance name for the VS. 12. Click the OSPF link in the Routing section. 13. In the Add New OSPF Area text box, enter 0.0.0.1 Click Apply. 14. In the Area drop-down list for interface e2, select AREA 1;then click Apply. 15. Click on next to the Virtual Address field to advertise the VRRP virtual IP address on this interface. then click Apply. 16. In the Router ID text box, enter the virtual IP address of the VS; then click Apply. 17. In the area drop-down list for the wrp interlace that connects to the VS to the EVR, select BACKBONE; then click Apply.
Caution Do not enable the virtual address option for the wrp interface. This option is not supported on wrp interfaces.
18. Click Save to make your changes permanent.

Configuring OSPF on Nokia Platform E
1. Initiate a Nokia Network Voyager session to Platform E. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; then click Apply. 6. Click Save to make your changes permanent.
Configuring OSPF on Nokia Platform B
1. Initiate a Nokia Network Voyager session to Platform B. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4, select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
95
Example 2: OSPF with an EVR, IVR, and a VS in a VRRP Setup

In the following example Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair, which you configure as follows: Enable OSPF on the EVR physical interface in Area 0 Enable OSPF on the IVR physical interface in Area 1 Enable OSPF on the wrp, that is virtual point to point (vpp), interfaces between the EVR and VS and Area 0 Enable OSPF on the wrp, that is vvp, interfaces between the IVR and the VS in Area 0
Figure 10 OSPF and VRRP Configuration with EVR, IVR, and VS
Area 0 Area 1
Nokia Platform D
24.58/30 24.57/30 Nokia Platform B 24.45/30
Nokia Platform A
24.46/30
Nokia Platform C
24.50/30 e1 24.53/30 e2 24.54/30 e3 Nokia Platform E
00340
24.49/30 e4
In Figure 10 above: Nokia platforms A and E are gateways Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair. Each member of the cluster is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A and B are in the backbone area. Nokia platform E is in Area 1.
1. Use the Provider-1 GUI to configure an EVR, an IVR, and a VS on each member of the VRRP pair, that is, on Nokia platforms C and D. 2. Initiate Network Voyager sessions and complete the following steps on each member of the VRRP pair, Nokia platforms C and D. 3. Click Configuration next to the instance name for the EVR. 4. Click the OSPF link in the Routing section. 5. In the Area drop-down list for interface e1, select BACKBONE; then click Apply.
96
OSPF
6. Click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface; then click Apply. 7. In the Router ID text box, enter the virtual IP address of the EVR; then click Apply. 8. In the Area drop-down list for the wrpj interface that connects the EVR to the VS, select BACKBONE.
Caution Do not enable the virtual address option for the wrpj interface. This option is not supported on wrp interfaces.
9. Click Apply, and then click Save to make your changes permanent. 10. Click Configuration next to the instance name for the IVR. 11. Click the OSPF link in the Routing section. 12. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 13. In the Area drop-down list for interface e2, select AREA 1; then click Apply. 14. Click on in the Virtual Address field to advertise the VRRP virtual IP address on the interface.; then click Apply. 15. In the Router ID text box, enter the virtual IP address of the IVR; then click Apply. 16. In the Area drop-down list for the wrp interface that connects the IVR to the VS, select backbone.
17. Click Apply, and then click Save to make your changes permanent. 18. Click Configuration next to the name of the VS. 19. In the Area drop-down list for the wrp interface that connects the VS to the EVR, select BACKBONE.
20. Click Apply, and then click Save to make your changes permanent.
1. Initiate a Nokia Network Voyager session to Platform E. 2. Click Configuration in the tree view.
97
3. Click the OSPF link in the Routing section. 4. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; then click Apply. 6. Click Save to make your changes permanent.
1. Initiate a Nokia Network Voyager session to Platform B. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4, select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
Example 3: OSPF with a VS and no EVR in a VRRP Setup

In the following example Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, VRRP pair, which you configure as follows: Enable OSPF on the VS physical interface in Area 0 Enable OSPF on the VS physical interface in Area 1
Figure 11 OSPF and VRRP Configuration with a VS and no EVR
Area 0
Nokia Platform D
Area 1
24.58/30 24.57/30 Nokia Platform B 24.45/30

24.49/30 e4
24.46/30
Nokia Platform C
24.50/30 e1
24.53/30 e2 24.54/30 e3 Nokia Platform E

00340
Nokia Platform A
In Figure 11 above: Nokia platforms A and E are gateways Nokia platforms C and D comprise a Nokia Virtual Firewall for Check Point VSX cluster, that is, a VRRP pair. Each member of the cluster is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A nd B are in the backbone area. Nokia Platform E is in Area 1.
98
OSPF
1. Use the Provider-1 GUI to configure an EVR and a VS on each member of the VRRP pair, that is, on Nokia platforms C and D 2. Initiate Network Voyager sessions and complete the following steps on each member of the VRRP pair, Nokia platforms C and D. 3. Click the Virtual Systems tab. 4. Click the OSPF link in the Routing section. 5. In the Area drop-down list for interface e1, select BACKBONE; then click Apply. 6. Click on next to the Virtual Address field to advertise the VRRP virtual IP address on this interface; then click Apply. 7. In the Router ID text box, enter the virtual IP address of the VS; then click Apply. 8. In the Add New OSPF Area text box, enter 0.0.0.1 Click Apply. 9. In the Area drop-down list for interface e2, select AREA 1; then click Apply. 10. Click on next to the Virtual Address field to advertise the VRRP virtual IP address for this interface; then click Apply. 11. Click Save to make your changes permanent.
1. Initiate a Network Voyager session to Nokia platform E. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Add New OSPF Area text box, enter 0.0.0.1 Click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; then click Apply. 6. Click Save to make your changes permanent.
1. Initiate a Network Voyager session to Nokia platform E. 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4 select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
99
Example of OSPF Configuration on a Nokia Virtual Firewall for Check Point VSX Standalone Gateway
In the following example, Nokia platform C is a Nokia Virtual Firewall for Check Point VSX standalone gateway, which means VRRP is not configured. You configure the gateway as follows: Enable OSPF on VS physical interface in Area 0 Enable OSPF on VS physical interface in Area 1
Figure 12 OSPF Configuration of Nokia Virtual Firewall for Check Point VSX Standalone Gateway
Area 0
Area 1
24.58/30 24.57/30 Nokia Platform B 24.45/30 24.49/30 e4 24.50/30 e1

Nokia Platform C
24.46/30
24.53/30 e2 24.54/30 e3 Nokia Platform D

00340
Nokia Platform A
In Figure 12: Nokia platforms A and D are gateways. Nokia platform C is a standalone Nokia Virtual Firewall for Check Point VSX gateway. Platform C is an area border router with interface e1 in the backbone area (Area 0) and interface e2 in Area 1. Nokia platforms A and B are in the backbone area. Nokia Platform D in is Area 1.
Configuring OSPF on Nokia Virtual Firewall for Check Point VSX Standalone Gateway Platform C
1. Use Check Point Provider-1 GUI to configure platform C as a VSX gateway. This means that platform C is not part of a VSX cluster, that is VRRP is not configured on the platform. 2. Initiate a Nokia Network Voyager session to platform C. 3. Click Configuration in the tree view.
100
RIP
4. Click the OSPF link in the Routing section. 5. In the Area drop-down list for interface e1, select BACKBONE; then click Apply.
Caution Do not enable the virtual address option for this interface.
6. (Optional) Enter a value in the Router ID text box for platform C.; then click Apply. 7. In the Add New OSPF Area text box, enter 0.0.0.1; then click Apply. 8. In the Area drop-down list for interface e2, select AREA 1; then click Apply.
Caution Do not enable the virtual address option for this interface.
Configuring OSPF on Nokia Platform D

1. Initiate a Network Voyager session to Nokia Platform D 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Add New OSPF area text box, enter 0.0.0.1; then click Apply. 5. In the Area drop-down list for interface e3, select AREA 0.0.0.1; the click Apply. 6. Click Save to make your changes permanent.

1. Initiate a Network Voyager session to Nokia Platform B 2. Click Configuration in the tree view. 3. Click the OSPF link in the Routing section. 4. In the Area drop-down list for interface e4, select BACKBONE; then click Apply. 5. Click Save to make your changes permanent.
RIP
The Routing Information Protocol (RIP) is one of the most widely used interior gateway protocols (IGP). RIP is an implementation of a distance-vector, or Bellman-Ford, routing protocol for local networks. Routers advertise their routes (reachability information) to other neighboring routers.
101
When it has information to send, a router running RIP sends updates on each configured interface at set intervals. Each update contains paired values, where each pair consists of an IP network address and a distance (expressed as an integer) to that network. RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a router advertises directly connected networks as a metric of 1. Networks that are reachable through one other router are two hops, and so on. Thus, the number of hops, or hop count, along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path. The maximum number of hops in a RIP network is 15 as the protocol treats anything equal to or greater than 16 as unreachable.
Enabling RIP for Nokia Virtual Firewall for Check Point VSX
For RIP to function with Nokia Virtual Firewall for Check Point VSX, you must complete the following procedure to add manually an entry to the table.def file in the Provider-1. Complete this procedure for each customer you want to enable RIP. 1. Open a console connection to the Provider-1 MDS. 2. Change directories (cd) to the directory for customers, which includes a subdirectory for each customer: /var/opt/CPmds-V25/customers. 3. Locate the name of the CMA you want to enable RIP and change to that directory. 4. Change directories (cd) to the private lib directory for that customer: CPfw1-V25/lib 5. Open the table.def file 6. Locate the table called nokia_no_fold_ports and add the following entry: <0, 520> 7. Log on to the Provider-1 GUI and push the policy for this entry change to take effect. 8. You can now continue to configure RIP for the specific CMA using Network Voyager. Repeat steps 2 through 6 for each CMA you want to enable RIP.
Note For more information about how to operate the Provider-1 MDS, see the Check Point Provider-1 User Guide.
Note If you want to implement BGP, you also need to modify the table.def file in the Provider-1 MDS. For more information, see Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
RIP 2
The RIP version 2 protocol adds capabilities to RIP. Some of the most notable RIP 2 enhancements follow.
102
RIP
Network Mask
The RIP 1 protocol assumes that all subnetworks of a given network have the same network mask. It uses this assumption to calculate the network masks for all routes received. This assumption prevents subnets with different network masks from being included in RIP packets. RIP 2 adds the ability to explicitly specify the network mask for each network in a packet.
Authentication
RIP 2 packets also can contain one of two types of authentication methods that can be used to verify the validity of the supplied routing data. The first method is a simple password in which an authentication key of up to 16 characters is included in the packet. If this password does not match what is expected, the packet is discarded. This method provides very little security, as it is possible to learn the authentication key by watching RIP packets. The second method uses the MD5 algorithm to create a crypto checksum of a RIP packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead, it contains a crypto-checksum called the digest. The receiving router performs a calculation using the correct authentication key and discards 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 assurance that 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 the interface from which the packet was received. 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 outside the mask are set, it is assumed to be a host; otherwise, it is assumed to be a subnet.
Auto Summarization
The Nokia implementation of RIP 1 supports auto summarization; this allows the router to aggregate and redistribute nonclassful routes in RIP 1.
Note Nokia recommends that you run version 2 only on a Nokia Virtual Firewall for Check Point VSX gateway. For warp interfaces, only version 2 multicast mode is supported.
103
Voyager Interface
Using Voyager, you can configure the following options: Version: You an use either RIP 1or RIP 2. RIP interfaces: You can specify the interfaces on which to run RIP. Metric: You can set the cost to use a given interface. Accept updates. You can configure whether or not to accept updates from other routers speaking RIP. Accepting updates specifies whether RIP packets received from a specified interface is accepted or ignored. Ignoring an update can result in suboptimal routing. Therefore, Nokia recommends that you retain the default setting for accepting updates. Transport: You can set this option only for RIP 2. You can set either broadcast or multicast. The RIP 2 option should always be set to multicast unless RIP 1 neighbors exist on the same link and it is desired that they hear the routing updates. Auto summarization: You should set auto summarization to aggregate and redistribute nonclassful routes in RIP 1.
CLI Not Supported

IPSO 5.0 does not support CLI commands for configuring or monitoring RIP for a routing instance, that is, virtual system. Use Nokia Network Voyager both to configure and to monitor RIP for a virtual system. For Network Voyager monitoring support, click the Virtual Systems tab, and then click the Monitor link in the routing instance that you want to monitor, that is, virtual system, for which you want to view statistics. For more information about monitoring RIP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
Virtual IP Address Support for VRRP

Beginning with IPSO 3.7.90, Nokia supports the advertising of the virtual IP address of the VRRP virtual router. You 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 time it takes both the VRRP and RIP 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.
104
RIP
You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable the option to advertise the virtual IP address on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address. For more information on enabling the advertising of a virtual IP address when running RIP, see Configuring RIP on page 105, step 14.
Note Nokia also provides support for BGP, OSPF, and PIM, both Sparse-Mode and Dense-Mode, to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
Configuring RIP
1. Use Check Point Provider-1 to configure an Ethernet interface. 2. You must enable RIP on the management station using Provider-1. For more information on how to do so, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102. 3. Click the Virtual Systems tab. 4. Click Configuration in the tree view next to the name of the routing instance you want to configure RIP. 5. Click the RIP link in the Routing section. 6. Click on for each interface to configure; then click Apply. 7. Click either 1 or 2 in the Version field to select RIP 1 or RIP 2, respectively, for each interface; then click Apply.
Note Nokia recommends that you run version 2 on a Nokia Virtual Firewall for Check Point VSX gateway. On wrp interfaces, only version 2 multicast mode is supported.
8. (Optional) Enter a new cost in the Metric text box for each interface; then click Apply. 9. (Optional) To configure the interface to not accept updates, click on the on radio button in the Accept updates field; then click Apply. 10. (Optional) If you want to configure the interface to not send updates, click on in the Send updates field; then click Apply. 11. (Optional) If you selected RIP 2 for an interface, make sure that Multicast is turned on for that interface; then click Apply.
Note When you use RIP 2, always select the multicast option. Nokia recommends that you not operate RIP 1 and RIP 2 together.
105
12. (Optional) If you selected RIP 2 for an interface, select the type of authentication scheme to use from the AuthType drop-down list; then click Apply. For simple authentication, select SIMPLE from the AuthType drop-down window. Enter the password in the Password edit box; then click Apply. The password must be from 1 to 16 characters long. For MD5 authentication, select MD5 from the AuthType drop-down list. Enter the password in the MD5 key text box; then click Apply. 13. (Optional) If you selected MD5 as your authentication type 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 RIP MD5 is set to conform to Nokia platforms. Click Apply. 14. If VRRP is enabled on a physical interface, click On next to the Virtual Address field to enable RIP on the virtual IP address associated with this interface; then click Apply.
Note Do not enable the option to advertise the virtual IP address on a wrp interface. If VRRP is not configured on an interface, do not enable the option to advertise the virtual IP address for that interface.
15. To make your changes permanent, click Save.
Configuring RIP Timers

Configuring RIP timers allows you 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.
Note By default, the update interval is set to 30 seconds and the expire interval is set to 180 seconds.
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure RIP. 3. Click the RIP link in the Routing section. 4. To modify the update interval, enter the new update interval in the Update Interval text box; then click Apply. 5. To modify the expire interval enter the new expire interval in the Expire Interval text box; then click Apply. 6. To make your changes permanent, click Save.
106
RIP
Configuring Auto-Summarization
Auto-summarization allows you to aggregate and redistribute non-classful routes in RIP 1.
Note Auto-summarization applies only to RIP 1.
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure RIP. 3. Click the RIP link in the Routing section. 4. To enable auto-summarization, click on in the Auto-Summarization field; then click Apply. 5. To disable auto-summarization click off in the Auto-Summarization field; then click Apply. 6. To make your changes permanent, click Save.
Note By default, auto-summarization is enabled.
Example of RIP Configuration in a VRRP Setup with an EVR and a VS

In this example, you disable anti-spoofing on both the internal and external interfaces of EVR and VS. Use Check Point SmartDashboard to ensure that anti-spoofing is disabled on those interfaces. You must also make sure routing propagation is disabled. Log on to SmartDashboard, click the link for the VS and then click the Topology tab. Highlight and click the interface for the VS. This action displays the Interface Property window. Click the Topology tab, and make sure the propagate route to adjacent virtual routers box is not checked. Uncheck the box if it is checked. Finally, you must enable RIP on the management station for each customer. For more information on how to do so, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102.
Configuring RIP on the EVR

Perform the following procedure on each member of the VRRP pair, beginning with the master. The example assumes that you used Provider-1 GUI to configure interfaces and to create the EVR and VS. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab.
107
3. Click Configuration in the tree view next to the name of the EVR., which in this example, as the Example screen shot of Network Voyager below shows, is referred to as vs1. 4. Click on next to the external and internal interfaces of the EVR to enable RIP. The screen shot below of Network Voyager configuration for the EVR shows that interface eth4 is configured as an external interface with an IP address of 172.168.231.1/24. The screen shot also shows that the internal interface is an unnumbered link called wrpj129. 5. Click either 1 or 2 to select the version of RIP for each interface. Nokia recommends that you select version 2. 6. Click on next to the Virtual Address field for the eth4 interface to advertise the VRRP virtual IP address on this interface.
Caution Do not enable the virtual address option for the wrpj129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent. 8. (Optional) You can remove the default route for the EVR. To do so, click Configuration in the tree view next to the name of the EVR, which in this example, is vs1. Click the Routing Options link. Click on next to Ignore IPv4 Default Route. The default is off, which means that the default route is automatically installed.
Note Make sure that you are not removing the route from the EVR to the Provider-1 or SmartCenter management station. The EVR must always have a route to the management station.
108
RIP
Network Voyager Configuration of EVR
Configuring RIP on a VS
This example shows you how to configure RIP on a VS in a VRRP setup. You do not have to have an EVR configured. If you want to configure an IVR, configure it the same way you configure a VS. Perform the following procedure on each member of the VRRP pair, starting with the master.The example assumes that you configured interfaces and created the VS using the Provider-1 GUI. 1. Initiate a Nokia Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as the Example Nokia Network Voyager screen shot below shows, is vs2. 4. Click on next to the internal and external interfaces for the VS. In this example, the internal interface is eth-s1p1c0.339 with an IP address of 173.168.39.0/24 The external interface is an unnumbered interface, which in this example is wrp129. 5. Click either 1 or 2 to select the version of RIP for each interface. Nokia recommends that you select version 2. 6. Click on in the Virtual Address field to advertise the VRRP virtual IP address for the eths1p1c0.330 interface only.
109
Caution Do not enable the virtual address option for the wrp129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent. 8. Make sure that the wrp129 interface, the interface that connects the VS to the EVR, is also enabled on the configuration page for the EVR, which in this example is vs1. That is, both the wrpj129, which connects the EVR to the VS, and wrp129 interfaces must be enabled on the configuration page for the EVR.
Network Voyager Configuration of VS
PIM
Protocol-Independent Multicast (PIM) gets its name from the fact that it can work with any existing unicast protocol to perform multicast forwarding. It supports two different types of multipoint traffic distribution patterns: dense and sparse. Dense mode is most useful when: Senders and receivers are in close proximity.
110
PIM
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 Vector Multicast Routing Protocol (DVMRP). Like DVMRP, dense-mode PIM uses Reverse Path Forwarding and the flood-and-prune model. Sparse mode is most useful when: A group has few receivers. Senders and receivers are separated by WAN links. The type of traffic 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 substantial departure from floodand-prune protocols, such as dense-mode PIM, which set up the forwarding state through he arrival of multicast data. You can configure different modes of PIM, either sparse or dense, for different routing instances. You cannot, however, enable both modes of PIM on the same routing instance, that is, virtual system. For more information about PIM, read the following Internet Engineering Task Force (IETF) drafts. For Dense-Mode PIM, see Protocol-Independent MulticastDense Mode (PIM-DM): Protocol Specification (Revised). For Sparse-Mode PIM, see Protocol-Independent MulticastSparse Mode (PIM-SM): Protocol Specification (Revised).
CLI Support
IPSO 3.9.92 supports CLI commands to configure and to monitor PIM for a virtual system. To configure PIM, use the following syntax before any specific command:
set instance <instance name>
To use the show commands for PIM, use the following syntax:
show instance <instance name>
For more information about how to use CLI, see the Nokia IPSO CLI Reference Guide.
Configuring Virtual 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 using 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.
111
You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable, the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address. For more information on how to configure this option through Voyager, see either Configuring Dense-Mode PIM or Configuring Sparse-Mode PIM.
Note Nokia also provides support for BGP, OSPF, and RIP to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
Configuring Dense-Mode PIM

1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the Interfaces section, click On for each interface on which to run PIM.
Note The number of interfaces on which you can run PIM is unlimited.
4. Click Apply, and then click Save to make your changes permanent. 5. (Optional) To configure this interface to use the VRRP virtual IP address, in the Virtual address field, click On.
Note You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address.
6. Click Apply. 7. (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.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, all messages from the neighbor are rejected. A PIM router on a shared LAN must have at least one interface address with a subnet prefix that all neighboring PIM routers share.
112
PIM
8. (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 designated router. The default is 1, and the range is 0 to 4294967295 (2^32 - 1).
Note Although you can configure this option, PIM-DM does not use DR Election Priority. On a LAN with more than one router, data forwarding is implemented on the basis of PIM Assert messages. The router with the lowest cost (based on unicast routing) to reach the source of data traffic is elected as the router that forwards traffic. In the case of a tie, the router with the highest IP address is elected to forward traffic.
9. Click Apply, and then click Save to make your change permanent.
Disabling PIM
You can disable PIM on one or more interfaces you configured on each Nokia platform. 1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the Interfaces section, click Off for each interface on which to disable PIM. To disable PIM entirely, click Off next to each interface that is currently running PIM. 4. Click Apply; then click Save to make your change permanent.
Setting Advanced Options for Dense-Mode PIM (Optional)

1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the Interfaces section, click On for each interface on which to run PIM.
4. Click Apply, and then click Save to make your changes permanent. 5. (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.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, all messages from the neighbor are rejected. A PIM router on a shared LAN must
113
have at least one interface address with a subnet prefix that all neighboring PIM routers share.
6. (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 designated router. The default is 1, and the range is 0 to 4294967295 (2^32 - 1). 7. Click Apply, and then click Save to make your changes permanent. 8. Click the Advanced PIM Options link. In the General Timers section, enter a value for the hello interval (in seconds) in the Hello Interval text box. The router uses this interval to send periodic Hello messages on the LAN. 9. In the General Timers section, enter a value for the data interval (in seconds) in the Data Interval text box. This value represents the interval after which the multicast (S, G) state for a silent source is deleted. 10. In the General Timers section, enter a value for the assert 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. 11. In the General 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 second at which the designated router sends assert messages. The upper limit is 10,000 assert messages per second. 12. In the General Timers section, enter a value (in seconds) for the interval between sending join or prune messages in the Join/Prune Interval text box. 13. In the General Timers section, enter a value for the random delay join or prune interval (in seconds) in the Random Delay Join/Prune Interval text box. This value represents the maximum interval between the time when the Reverse Path Forwarding neighbor changes and when a join/prune message is sent. 14. In the General Timers section, enter a value for the join/prune suppression interval (in seconds) in the Join/Prune Suppression Interval text box. This value represents the mean interval between receiving a join/prune message with a higher hold time and allowing duplicate join/prune messages to be sent again.
Note The join/prune suppression interval should be set at 1.25 times the join/prune interval.
15. In the Assert Ranks section, in the appropriate text box, enter a value for the routing protocol(s) you are using.Assert Rank values are used to compare protocols and determine which router forwards multicast packets on a multiaccess LAN. Assert messages include these values when more than one router can forwarding the multicast packets.
114
PIM
Note Assert rank values must be the same for all routers on a multiaccess LAN that are running the same protocol.
16. Click Apply. 17. To make your changes permanent, click Save.
Configuring Sparse-Mode PIM

1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the PIM Instance Mode field, click On for sparse. 4. Click Apply. 5. In the Interfaces section, click On for each interface on which to run PIM.
6. Click Apply. 7. (Optional) To configure this interface to use the VRRP virtual IP address, in the Virtual address field, click On.
Note You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable, the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address.
8. Click Apply. 9. (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 addresses are configured on the interface.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, then all messages from the neighbor are rejected. A PIM router on a shared LAN must have at least one interface address with a subnet prefix that all neighboring PIM routers share.
115
10. (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 designated router. To break a tie, the designated router with the highest IP address is chosen. If even one router does not advertise a DR election 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 (232 - 1).
Note To verify whether a PIM neighbor supports DR Election Priority, use the following CLI command: show instance <instance name> pim neighbor <ip_address> For neighbors that advertise a DR election priority value, the following message appears in the summary: DRPriorityCapable Yes.
Configuring High-Availability Mode

Enable the high-availability (HA) mode when two routers are configured to back each other up to forward multicast traffic and sparse-mode PIM is implemented. When this option is enabled, all PIM-enabled interfaces are available only if each interface is up and has a valid address assigned. If any PIM-enabled interface goes down or if all of its valid addresses are deleted, then all PIM-enabled interfaces become unavailable and remain in that state until all interfaces are back up. Beginning with IPSO 3.7.90, you can configure either a PIM-SM or a PIM-DM interface to advertise the VRRP virtual IP address 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 Virtual IP Address Support for VRRP.
Note The HA mode applies only to sparse-mode PIM. The HA mode feature does not affect the functioning of dense-mode PIM. You cannot enable HA mode if you enable IP clustering.
1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the PIM Instance Mode field, click On for sparse. 4. Click Apply.
116
PIM
5. In the HA Mode field, click On to enable the high-availability mode. 6. Click Apply. 7. In the Interfaces section, click On for each interface to run PIM.
Note The number of interfaces on which you can run PIM is unlimited
8. Click Apply. 9. (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 advertisements on the interface. This option is useful only when multiple addresses are configured on the interface.
Note If neighboring routers choose advertisement addresses that do not appear to be on a shared subnet, then all messages from the neighbor are rejected. A PIM router on a shared LAN must have at least one interface address with a subnet prefix that all neighboring PIM routers share.
10. (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 designated router. To break a tie, the designated router with the highest IP address is chosen. If even one router does not advertise a DR election 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 To verify whether a PIM neighbor supports DR Election Priority, use the following CLI command: show instance <instance name> pim neighbor <ip_address> For neighbors that advertise a DR election priority value, the following message appears in the summary: DRPriorityCapable Yes.
117
Configuring this Router as a Candidate Bootstrap and Candidate Rendezvous Point

1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the PIM Instance Mode field, click On button for sparse. 4. Click Apply. 5. In the Interfaces section, click On for each interface on which to run PIM.
6. Click Apply. 7. In the Sparse Mode Rendezvous Point (RP) Configuration section, to enable this router as a candidate bootstrap router: a. Click On in the Bootstrap Router field. b. (Optional) Enter the address of the bootstrap router in the Local Address text box. Configure an address for the candidate bootstrap router to help specify the local address used as the identifier in the bootstrap messages. By default, the router chooses an address from one of the interfaces on which PIM is enabled. c. (Optional) Enter the bootstrap router priority (0 to 255) in the Priority text box. Use the priority option to help specify the priority to advertise in bootstrap messages. The default priority value is 0.
Note The domain automatically elects a bootstrap router, based on the assert rank preference values configured. The candidate bootstrap router with the highest preference value is elected the bootstrap router. To break a tie, the bootstrap candidate router with the highest IP address is elected the bootstrap router.
8. In the Sparse Mode Rendezvous 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 Candidate Rendezvous Point router in the Local Address field. This router sends Candidate Rendezvous Point messages. Configure an address for the Candidate Rendezvous Point to select the local address used in candidate-RP-advertisements sent to the elected bootstrap router. By default, the router chooses an address from one of the interfaces on which PIM is enabled. c. (Optional) Enter the Candidate Rendezvous Point priority (0 to 255) in the Priority text box.
118
PIM
Use the priority option to set the priority for this rendezvous point. The lower this value, the higher the priority. The default priority value is 0. 9. (Optional) To configure a multicast address for which this router is designated as the rendezvous point, in the Local RPSET field, enter an IP address in the Multicast address group text box and the address mask length in the 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 groups (224/4)
Configuring a PIM-SM Static Rendezvous Point

1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the PIM Instance Mode field, click On for sparse. 4. Click Apply. 5. In the Interfaces section, click On for each interface on which to run PIM.
6. Click Apply. 7. In the Sparse Mode Rendezvous Point (RP) Configuration section, to enable a Static Rendezvous Point router, click On in the Static RP Router field.
Note Static Rendezvous Point configuration overrides rendezvous point (RP) information received from other RP-dissemination mechanisms, such as bootstrap routers.
8. Enter the IP address of the router to configure as the static rendezvous point in the RP Address text box. Click Apply. 9. (Optional) Enter the multicast group address and prefix length in the Multicast group address and Mask length text boxes. Click Apply.
119
Note If you do not configure a multicast group address and prefix length for this Static Rendezvous Point, it functions by default as the rendezvous point for all multicast groups (224.0.0.0/4).
Setting Advanced Options for Sparse-Mode PIM (Optional)

1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the PIM Instance Mode field, click On for sparse. 4. Click Apply. 5. In the Interfaces section, click On each interface on which to run PIM.
6. Click Apply. 7. Click the Advanced PIM Options link. In the Sparse Mode Timers section, enter a value for the register suppression interval (in seconds) in the Register-Suppression Interval text box. This value represents the mean interval between receiving a Register-Stop message and allowing Register messages to be sent again. 8. In the Sparse Mode Timers section, enter a value for the bootstrap interval for candidate bootstrap routers (in seconds) in the Bootstrap Interval text box. This value represents the interval between which bootstrap advertisement messages are sent. 9. In the Sparse Mode Timers section, enter a value for the candidate rendezvous point advertisement interval (in seconds) in the Candidate RP-Advertisement Interval text box. This value represents the interval between which Candidate Rendezvous Point routers send Candidate-RP-Advertisement messages. 10. In the Sparse Mode Timers section, enter a value for the shortest path tree threshold (in kilobits per second) in the Threshold (kbps) text box. Enter an IP address for the multicast group to which the SPT threshold applies in the Multicast Group ID text box. Enter the mask length for the group multicast address in the Mask Length edit box. When the data rate for a sparse-mode group exceeds the shortestpath-tree threshold at the last-hop router, an (S,G) entry is created and a join/prune message is sent toward the source. Setting this option builds a shortest-path tree from the source S to the last-hop router.
120
PIM
11. Click Apply, and then click Save to make your changes permanent. 12. (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 send periodic Hello messages on the LAN. 13. (Optional) In the General Timers section, enter a value for the data interval (in seconds) in the Data Interval text box. This value represents the interval after which the multicast (S, G) state for a silent source is deleted. 14. (Optional) In the General Timers section, enter a value for the assert 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. 15. (Optional) In the General 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 second at which the designated router sends assert messages. The upper limit is 10,000 assert messages per second. 16. (Optional) In the General Timers section, enter a value (in seconds) for the interval between sending join/prune messages in the Join/Prune Interval text box. 17. (Optional) In the General Timers section, enter a value for the random delay join/prune interval (in seconds) in the Random Delay Join/Prune Interval text box. This value represents the maximum interval between the time when the reverse path forwarding neighbor changes and when a join/prune message is sent. 18. (Optional) In the General Timers section, enter a value for the join/prune suppression interval (in seconds) in the Join/Prune Suppression Interval text box. This value represents the mean interval between receiving a join/prune message with a higher Holdtime and allowing duplicate join/prune messages to be sent again.
Note The join/prune suppression interval should be set at 1.25 times the join/prune interval.
19. (Optional) In the Assert Ranks section, enter a value for the routing protocol(s) you are using in the appropriate text box. Assert Rank values are used to compare protocols and determine which router forwards multicast packets on a multiaccess LAN. Assert messages include these values when more than one router can forward the multicast packets.
Note Assert rank values must be the same for all routers on a multiaccess LAN that are running the same protocol.
20. Click Apply, and then click Save to make your change permanent. 21. (Optional) The checksum of the PIM register messages is calculated without including the multicast payload. Earlier releases of the Cisco IOS calculate the checksum by including the
121
multicast payload. If you experience difficulties 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 register messages that calculate the checksum with or without the multicast payload, that is, it accepts all register messages. a. To enable Cisco compatibility for register checksums, click On in the Cisco Compatibility Register Checksums field. b. Click Apply, and then click Save to make your change permanent.
Debugging PIM
The following IPSO CLI commands can assist you in debugging PIM:
Command show instance <instance name> pim interface show instance <instance name> pim neighbors Shows Which interfaces are running PIM, 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. The IP address of each PIM neighbor and the interface on which the neighbor is present. This command also displays the neighbors DR priority, generation ID, holdtime and the time the neighbor is set to expire based on the holdtime received in the most recent hello message. The number of different types of PIM packets received and transmitted and any associated errors.
show instance <instance name> pim statistics show instance <instance name> mfc cache show instance <instance name> mfc interfaces
Multicast source and group forwarding state by prefix.
Shows multicast source and group forwarding state by interface.
The following CLI commands can assist you in debugging sparse-mode PIM (PIM-SM):
Command show instance <instance name> pim bootstrap show instance <instance name> pim candidate-rp Shows The IP address and state of the Bootstrap router.
The state of the Candidate Rendezvous Point state machine.
122
PIM
Command show instance <instance name> pim joins
Shows PIMs view of the join-prune (*, G and S, G) state, including RP for the group, incoming, and outgoing interface(s), interaction with the multicast forwarding cache and the presence of local members. To view the equivalent information for dense-mode PIM, use the show mfc cache command. The active RP-set, including the RP addresses, their type (or source of information about them) and the groups for which they are configured to act as RP. The RP selected for a particular group based on information from the active RP-set.
show instance <instance name> pim rps
show instance <instance name> pim group-rpmapping <groupaddress> show instance <instance name> pim sparse-mode statistics
Error statistics for multicast forwarding cache (MFC); Bootstrap Router (BSR) messages; Candidate Rendezvous Point (CRP) advertisements; and the Internet Group Management Protocol (IGMP).
Use the Trace Options feature to log information about errors and events. 1. Click the Virtual Systems tab. 2. Click PIM under Configuration > Routing in the tree view for the routing instance you want to configure. 3. In the Trace Options section, click on the Add Option drop-down window in the PIM field. Select each option for which you want to log information. You must select each option one at a time and click Apply after you select each option. For each option you select, its name and on and off radio buttons appear just above the drop-down window. To disable any of the options you have selected, click the off radio button, and then click Apply. 4. Click Save to make your changes permanent. The following trace options apply both to dense-mode and sparse-mode implementations: Assert: traces PIM assert messages. Hello: traces PIM router hello messages. Join: traces PIM join/prune messages MFC: traces calls to or from the multicast forwarding cache MRT: traces PIM multicast routing table events. Packets: traces all PIM packets. Trap: Trace PIM trap messages. All: traces all PIM events and packets. The following trace options apply to sparse-mode implementations only: Bootstrap: traces bootstrap messages. CRP: traces candidate-RP-advertisements.
123
RP: traces RP-specific events, including both RP set-specific and bootstrap-specific events. Register: traces register and register-stop packets. The following trace option applies to dense-mode implementations only: Graft: traces graft and graft acknowledgment packets
Example of PIM Configuration in a VRRP Setup

In this example, you disable anti-spoofing on both the internal and external interfaces of the EVR and VS. Use Check Point SmartDashboard to ensure that anti-spoofing is disabled on those interfaces. The example assumes that you used Provider-1 to configure interfaces and to create the EVR and VS. This example shows how to configure PIM-SM, but you can follow the same procedure to configure PIM-DM, except that you select dense in the protocol type field on the Network Voyager PIM configuration pages for the EVR and for the VS.
Configuring PIM-SM on the EVR

Perform the following procedure on each member the VRRP pair, that is, the VSX cluster, beginning with the master. 1. Initiate a Nokia Network voyager session 2. Click the Virtual Systems tab. 3. Click the Config link for the EVR, which in this example, as the Example Network Voyager screen shot below shows, is called vs1. 4. Click sparse in the Protocol type field. As the example screen shot shows, do not enable the HA mode for the VS. The default is off.
Note To configure PIM-DM, click dense in the Protocol type field and continue with the procedure below.
5. Click on next to the internal and external interfaces for the EVR to enable PIM-SM on those interfaces. In this example, the external interface is eth4 with an IP address 172.168.1.231, and the internal interface is an unnumbered interface, wrpj129. Click Apply. 6. Click on next to Virtual Address for the eth4 interface to advertise the VRRP virtual IP address on this interface.
124
PIM
Network Voyager Configuration of EVR
Configuring PIM-SM on the VS

This example shows you how to configure PIM-SM on a VS in a VRRP setup. You do not have to have an EVR configured. If you want to configure an IVR, configure it the same way you configure a VS. You can also complete this procedure to configure PIM-DM, but you click dense in the protocol type field, instead of sparse. Perform the following procedure on each member of the VRRP pair, starting with the master.The example assumes that you configured interfaces and created the VS using the Provider-1 GUI. 1. Initiate a Nokia Network Voyager session. 2. Click the Virtual Systems tab. 3. Click the Config link for the VS, which in this example, as the Example Network Voyager screen shot below shows, is vs2.
125
4. Click sparse in the Protocol Type field. As the example screen shot shows, do not enable the HA mode for the VS. The default is off.
Note To configure PIM-DM, click dense in the Protocol type field and continue with the procedure below.
5. Click on next to the internal and external interfaces for the EVR to enable PIM-SM on those interfaces. In this example, the internal interface is eth-21p1c0.330 with an IP addresses 20.20.20.1/28 and 173.168.39.0, and the external interface is an unnumbered interface, wrp129. Click Apply. 6. Click on in the Virtual Address field for the eth4 interface only to advertise the VRRP virtual IP address on this interface.
Caution Do not enable the virtual address option for the wrp129 interface. This option is not supported on wrp interfaces.
7. Click Apply, and then click Save to make your changes permanent. 8. Make sure that the wrp129 interface, the interface that connects the VS to the EVR, is also enabled on the Nokia Network configuration page for the EVR. That is, both the wrpj129 interface, which connects the EVR to the VS, and the wrp129 interface, must be enabled on the configuration page for the EVR, which in this example is vs1.
Note Nokia recommends that you not configure the VS as either a rendezvous point for a bootstrap candidate router, as the screen shot of the VS configuration shows.
126
IGMP
Network Voyager Configuration of VS
IGMP
Internet Group Management Protocol (IGMP) allows hosts on multiaccess networks to inform locally attached routers of their group membership information. Hosts share their group membership information by multicasting IGMP 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 messages are encapsulated in IP datagrams, with an IP protocol number of 2. Protocol operation requires that a designated querier router be elected on each subnet and that it periodically 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 active members on the subnet to cancel their reports. This behavior limits the number of reports generated to one for each active group on the subnet. This exchange allows the multicast routers to maintain a database of all active host groups on each of their attached subnets. A group is declared inactive (expired) when no report is received for several query intervals.
127
The IGMPv.2 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 group-directed query with a very small maximum response time to probe for any remaining active group members. This accelerated leave extension can reduce the time required to expire a group and prune the multicast distribution tree from minutes, down to several seconds The unicast traceroute program allows 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 unicast traceroute is the ICMP TTL exceeded message that is specifically precluded as a response to multicast packets. The traceroute facility implemented within IPSRD conforms to the traceroute facility for IP multicast draft specification.
Features
Complete IGMPv.2 functionality Multicast traceroute Complete configurability of protocol timers Administratively-blocked groups Support for interfaces with secondary addresses Monitoring template
Voyager Interface
Using Voyager, you can configure the following options: Version number Loss robustness Query interval Query response interval Last-member query interval Additionally, you can enable and disable router alert.
Configuring IGMP
1. Configure a multicast routing protocol, such as PIM-DM or PIM-SM. The IGMP feature supports IP multicast groups on a network and functions only in
128
IGMP
conjunction with a multicast routing protocol to calculate a multicast distribution tree. For more information on multicast routing protocols supported by IPSO 5.0, see PIM.
Note After you enable a mulitcasting protocol, either PIM-DM or PIM-SM, you do not typically need to perform any additional configuration for IGMP because the multicasting protocol automatically enables version 2 of IGMP and set the default values.
2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure IGMP. 4. Click the IGMP link in the Routing section. 5. Complete the following steps for each interface on which you enabled a multicast routing protocol. 6. Click the appropriate Version button to enable either version 1 or 2; then click Apply. The default is version 2
Note A router configured for IGMP version 2 can interoperate with hosts running either IGMP version 1 or version 2. Nokia recommends that you use version 1 only on networks that include multicast routers that are not upgraded to IGMP version 2.
7. (Optional) Enter the loss robustness value in the Loss robustness text box; then click Apply. The range is 1 to 255, and the default is 2. 8. (Optional) Enter the query interval in the Query interval text box; then click Apply. This value specifies the interval, in seconds, that the querier router sends IGMP general queries. The default is 125, and the range is 1 to 3600. 9. (Optional) Enter the query response interval in the Query response interval text box; then click Apply. This value specifies the maximum response time, in seconds, inserted into the periodic IGMP general queries. The higher the value the 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. 10. (Optional) Enter the last member query interval in the Last member query interval text box,; then click Apply. This value specifies the maximum response time, in seconds, inserted into IGMP groupspecific queries. A lower value results in less time to detect the loss of the last member of a multicast group. This value must be lower than that of the query interval. The default is 1, and the range is 1 to 25. 11. (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 interoperating with broken IP implementations that
129
might otherwise discard packets from the specified interface. The default is Off, meaning that the IGMP messages include the IP router alert. Click Apply. 12. To make your changes permanent, click Save.
BGP
Border Gateway Protocol (BGP) is an inter-AS protocol, meaning that it can be deployed within and between autonomous systems (ASes). 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 routing protocol to route packets to other ASes.
Note This implementation supports only BGP version 4.
BGP sends update messages that consist of network number-AS path pairs. The AS path contains the string of ASes through which the specified network can be reached. An AS path has some structure in order to represent the results of aggregating dissimilar routes. These update messages are sent over TCP transport 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.
Enabling BGP on Nokia Virtual Firewall for Check Point VSX

For BGP to function with Nokia Virtual Firewall for Check Point VSX, you must complete the following procedure to remove manually an entry the table.def file in the Provider-1 sever. 1. Open a console connection to the Provider-1 MDS. 2. Change directories (cd) to the directory for customers, which includes a subdirectory for each customer: /var/opt/CP-mdsV25/customers. 3. Locate the name of the CMA you want to enable BGP and change to that directory. 4. Change directories private lib directory for that customer: CPfw1V25/lib 5. Open the table.def file 6. Locate the table called nokia_no_fold_ports and remove the following entry: <6, 179> 7. Log on to the Provider-1 GUI and push the policy for this entry to take effect. 8. You can now continue to configure BGP for the specific CMA using Network Voyager. Repeat steps 2 through 6 for each CMA you want to enable BGP.
130
BGP
Note For more information about how to operate the Provider-1 MDS, see the Check Point Provider-1 User Guide.
Note To implement RIP, you also need to modify the table.def file in the Provider-1 MDS. For more information, see Enabling RIP for Nokia Virtual Firewall for Check Point VSX on page 102.
CLI Not Supported

IPSO 5.0 does not support CLI commands for configuring or monitoring BGP for a routing instance, that is, virtual system. Use Nokia Network Voyager both to configure and to monitor BGP for a virtual system. For Network Voyager monitoring support, click Routing Instance on the home page of Voyager, and then click the Monitor link next to the routing instance, that is, virtual system, for which you want to view statistics. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
BGP Sessions (Internal and External)

BGP supports two basic types of sessions between neighbors: internal (sometimes referred to as IBGP) and external (EBGP). Internal sessions run between routers in the same autonomous systems, while external sessions run between routers in different autonomous systems. When sending routes to an external peer, the local AS number is prepended to the AS path. Routes received from an internal neighbor have, in general, the same AS path that the route had when the originating internal neighbor received the route from an external peer. BGP sessions might include a single metric (Multi-Exit Discriminator or MED) in the path attributes. Smaller values of the metric are preferred. 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 protocol processing. BGP implementations expect external peers to be directly 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. Type internal groups determine the immediate next hops for routes by using the 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 distant peers, but they need to be informed of the IGP whose routes they are using to determine immediate next hops.
131
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 running 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 loops in an arbitrary topology. You can also use path attributes to determine administrative preferences. BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update are readvertised 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 that the kernel forms message by message. Instead, it fills the input buffer. BGP processes all 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 busy peer connection to block other protocols for prolonged intervals.
The following table displays the path attributes and their definitions
Path Attribute AS_PATH Definition Identifies the autonomous systems through which routing information carried in an UPDATE message passed. Components of this list can be AS_SETs or AS_SEQUENCES. Defines the IP address of the border router that should be used as the next hop to the destinations listed in the UPDATE message. Discriminates among multiple exit or entry points to the same neighboring autonomous system. Used only on external links. Determines which external route should be taken and is included in all IBGP UPDATE 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.
NEXT_HOP
MULTI_EXIT_DISC
LOCAL_PREF
132
BGP
Path Attribute ATOMIC_AGGREGATE
Definition Specifies to a BGP speaker that a less specific route was chosen over a more specific route. The BGP speaker attaches the ATOMIC_AGGREGATE attribute to the route when it reproduces it to other BGP speakers. The BGP speaker that receives this route cannot remove the ATOMIC_AGGREGATE attribute or make any Network Layer Reachability Information (NLRI) of the route more specific. This attribute is used only for debugging purposes.
All unreachable messages are collected into a single message and are sent before reachable routes during a flash update. For these unreachable announcements, 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 path in unreachable announcements is set to the local AS. On internal connections, the AS path length is set to zero. Routing information shared between peers in BGP has two formats: announcements and withdrawals. A route announcement indicates that a router either learned of a new network attachment or made a policy decision to prefer another route to a network destination. 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 external 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 traffic that originates from locations outside of that AS, is destined to locations outside of that AS, or both. This requires a certain degree of interaction and coordination between BGP and the Interior Gateway Protocol (IGP) that the particular AS uses. In general, traffic that originates outside of a given AS passes through both interior 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 propagate BGP information within a given AS, take special care to ensure consistency between BGP and the IGP, since changes in state are likely to
133
propagate at different rates across the AS. A time window might occur between the moment when some border gateway (A) receives new BGP 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. To minimize such routing problems, border gateway (A) should not advertise to any of its external peers a route to some set of exterior destinations associated with a given address prefix using border gateway (B) until all the interior gateways within the AS are ready to route traffic destined to these destinations by using the correct exit border gateway (B). Interior routing should converge 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 full knowledge of all BGP routes. The IGP is then only used for routing within the AS, and no BGP routes are imported into the IGP. The user can perform a recursive lookup in the 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.
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 with a negative preference. A negative preference prevents a route from becoming active and prevents it from being installed in the forwarding table or being redistributed to other protocols. This behavior eliminates the need to break and re-establish a session upon reconfiguration if importation policy is changed. The only attribute that can add or modify when you import from BGP is the local preference. The local preference parameter assigns a BGP local preference to the imported route. The local preference is a 32-bit unsigned value, with larger values preferred. This is the preferred way to bias a routing subsystem preference for BGP routes.
BGP Redistribution
When redistributing routes to BGP, you can modify the community, local preference, and MED attributes. Redistribution to BGP is controlled on an AS or AS path basis. BGP 4 metrics (MED) are 32-bit unsigned quantities; they range from 0 to 4294967295 inclusive, with 0 being the most desirable. If the metric is specified as IGP, any existing metric on the route is sent as the MED. For example, this 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 significant only when used with internal BGP. It is a 32-bit unsigned quantity and larger values are preferred. The local preference should normally be specified within the redistribution list unless no BGP sources are present in the redistribution list.
134
BGP
Note If BGP routes are being redistributed into IBGP, the local preference cannot be overridden, and this parameter is ignored for IBGP sources. The same is true for confederation 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. To implement this feature, map a set of communities to certain BGP local preference values. Then you can apply a uniform BGP configuration 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 can configure your BGP speaker to set, append, or modify the community of a route that controls which routing information is accepted, preferred, or distributed to other neighbors. The following table displays some special community attributes that a BGP speaker can apply.
Community attribute NO_EXPORT (0xFFFFFF01) Description Not advertised outside a BGP confederation boundary. A standalone autonomous system that is not part of a confederation should be considered a confederation itself. Not advertised to other BGP peers. Not advertised to external BGP peers. This includes peers in other members autonomous systems inside a BGP confederation.
NO_ADVERTISE (0xFFFFFF02) NO_EXPORT_SUBCONFED(0xFFFFFF03)
For further details, refer to the communities documents, RFCs 1997 and 1998.
Route Reflection
Generally, all border routers in a single AS need to be internal peers 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 large internal peer groups in large networks. To help address this problem, BGP supports route reflection for internal and routing peer groups (BGP version 4). When using route reflection, the rule that specifies that a router can not readvertise routes from internal peers to other internal peers is relaxed for some routers called route reflectors. A typical
135
use of route reflection might involve a core backbone of fully meshed routers. This means that all the routers in the fully meshed group peer directly with all other routers in the group. Some of these routers act as route reflectors for routers that are not part of the core group. Two types of route reflection are supported. By default, all routes received by the route reflector that originate from a client are sent to all internal 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 are 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 internal peer are sent to all route reflection clients. Typically, a single router acts as the reflector for a set, or cluster, of clients; for redundancy, two or more routers can also be configured to be reflectors for the same cluster. In this case, a cluster ID should be selected to identify all reflectors serving the cluster, using the cluster ID keyword.
Note Nokia recommends that you not use multiple redundant reflectors unnecessarily as it increases the memory required to store routes on the peers of redundant reflectors.
No special configuration is required on the route reflection clients. From a client perspective, a route reflector is a normal IBGP peer. Any BGP 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).
Non-client IBGP Nokia Platform B route reflector Nokia Platform C Nokia Platform E Non-client IBGP Cluster EBGP AS1 Nokia Platform D
Nokia Platform A
IBGP
AS676 Nokia Platform F IBGP Nokia Platform G

00328
Client
Client
AS1 has five BGP-speaking routers. With Router B working as a route reflector, there is no need to have all the routers connected in a full mesh.
Confederations
An alternative to route reflection is BGP confederations. As with route reflectors, you can partition BGP speakers into clusters where each cluster is typically a topologically close set of routers. With confederations, this is accomplished by subdividing 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 large AS.
136
BGP
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 (RDI). 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 does need to be unique within the confederation. Many confederations find it convenient to select their RDIs from the reserved AS space (ASes 64512 through 65535 (see RFC 1930)). RDIs are used as the ASes in BGP sessions between peers within the confederation. The confederation as a whole, is referred to by a confederation identifier. This 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. For this reason, the confederation ID must be a globally unique, normally assigned AS number.
Note Do not nest confederations.
For further details, refer to the confederations specification document (RFC 1965 as of this writing).
AS1
RDI A IBGP
AS2
EBGP
RDI B
IBGP RDI C
00329
AS1 has seven BGP-speaking routers grouped under 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 different ASes are referred to as EBGP connections. BGP enforces the rule that 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 restriction by enabling the EBGP multihop feature. TCP connections between EBGP peers are tied to the addresses of the outgoing interfaces. Therefore, a single interface failure severs the session even if a viable path exists between the peers.
137
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 addition, you can use EBGP multihop support to balance the traffic among all links.
Caution Enabling multihop BGP connections is dangerous because BGP speakers might establish a BGP connection through a third-party AS. This can violate policy considerations and introduce forwarding loops.
AS1 Nokia Platform A EBGP

Nokia Platform B
AS2
Loopback Address
Loopback Address
00330
Router A and Router B are connected by two parallel serial links. To provide fault tolerance and enable load-balance, enable EBGP multihop and using addresses 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. Without route dampening, autonomous systems continually send advertisement and withdrawal messages each time the flapping route becomes available or unavailable. As the Internet has grown, the number of announcements per second has grown as well and caused performance problems within the routers. Route dampening enables routers to keep a history of the routes that are flapping and prevent them from consuming significant network bandwidth. This is achieved by measuring how often a given route becomes available and then unavailable. When a set threshold is reached, that route is no longer considered valid, and is no longer propagated for a given period of time, usually about 30 minutes. If a route continues to flap even after the threshold is reached, the time out period for that route grows in proportion to each additional 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 threshold. Route dampening can cause connectivity to appear to be lost to the 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.
138
BGP
TCP MD5 Authentication

The Internet is vulnerable to attack through its routing protocols and BGP is no exception. External sources can disrupt communications between BGP peers by breaking their TCP connection with spoofed RST packets. Internal sources, such as BGP speakers, can inject bogus routing information from any other legitimate BGP speaker. Bogus information from either external or internal sources can affect routing behavior over a wide area in the Internet. The TCP MD5 option allows BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. To spoof a connection using MD5 signed sessions, the attacker not only has to guess TCP sequence numbers, but also the password included in the MD5 digest.
BGP Support for Virtual IP for VRRP

Beginning with IPSO 3.7.90, the Nokia BGP implementation supports advertising the virtual IP address of the VRRP virtual router. You can force a route to use the virtual IP address as the local endpoint for TCP connections for a specified internal or external peer autonomous system. Only the VRRP master establishes BGP sessions. For more information on VRRP, see Configuring the VSX VRRP Cluster on page 55.
Note Nokia also provides support for OSPF and PIM, both sparse mode and dense mode, and RIP to advertise the virtual IP address of the VRRP virtual router, beginning with IPSO 3.7.90.
Perform the following procedure to configure an a peer autonomous system, corresponding local address, and to enable support for virtual IP for VRRP. 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Enter a value between 1 and 65535 in the Peer autonomous system number edit box. 5. Click the Select the peer group type drop-down list and click either INTERNAL or EXTERNAL. If the peer autonomous system number is different from the local autonomous system of this router, click EXTERNAL. If the peer autonomous system number is the same as that of the local autonomous system of this router, click INTERNAL. You must also select Internal if the local autonomous system is part of a confederation. For more information on confederations, see Confederations. 6. Click Apply. 7. Click the Advanced BGP Options link on the BGP page. 8. Click on in the Virtual Address field to enable virtual IP for VRRP support.
139
Note You must use enable advertising of the virtual IP address when you implement VRRP. Do not, however, enable, the option to advertise the virtual IP dress on a wrp interface. If VRRP is not configured, do not enable the option to advertise the virtual IP address.
BGP Memory Requirements

Tables
BGP stores its routing information in routing information bases (RIBs).
RIB Name Adjacency RIB In Local RIB Adjacency RIB Out Description Stores routes received from each peer. Forms the core routing table of the router. Stores routes advertised to each peer.
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 To 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 the number of peers by the number of routes accepted. Multiply 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 ISPs 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. With these figures, you can compute the total memory requirements:
140
BGP
The base IPSRD memory is 2 MB. Add this value to the following values to calculate the total memory requirements. 1. To calculate the inbound memory requirements, multiply the number of peers (two ISPs) by the number of routes 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,000,000 or 2 MB. 2. To calculate the local memory requirements, multiply the number of routes accepted (50,000) by the size of each route entry in the local route table (76 bytes). The answer is 4,000,000 or 4MB. 3. To calculate the outbound memory requirements, 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 IPSRD requires 8.05MB of memory for this example.
Note Make sure that IPSRD is not swapping memory. Look at the memory sizes occupied by user-level daemons like Check Point, ifm , xpand, etc.
To find out how much memory IPSRD occupies, run the following command:
ps -auxww | grep ipsrd
The fourth column labeled, %MEM, displays the percentage of memory that IPSRD occupies.
BGP Configuration Examples

The following sections show how to configure BGP in different Nokia Virtual Firewall for Check Point VSX environments and in various scenarios that implement specific BGP features. The first two sections show how to configure BGP in a VSX environment, both on a Nokia Virtual Firewall for Check Point VSX cluster, that is, in a VRRP setup, and on a Nokia Virtual Firewall for Check Point VSX standalone gateway. The remaining sections show how to implement certain features, such as confederations and route dampening.
Examples of BGP Configuration in a VRRP Setup

The following two examples show how to configure BGP in a VSX cluster, that is, on a VRRP pair: with an external router and a VS with a VS and no EVR
141
In these examples, you use Check Point Provider-1 GUI to configure interfaces and IP addresses as well as an EVR and a VS before you configure BGP using Network Voyager. You must also modify the Provider-1 MDS to enable BGP. For more information, see Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
Example 1: BGP Configuration in a VRRP Setup with an EVR and a VS

In this example, you configure: a BGP peer on the EVR a BGP peer on the VS the VS and EVR as BGP peers an external router as a BGP peer with a VS, which sits behind the EVR
Configuring a BGP External Peer on the EVR
Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the EVR, which in this example as the Example screen shot of Network Voyager below shows, is vs1. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in the AS number text box for the EVR, enter 100. Click Apply. 6. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the EVR, which in a VSX cluster is the VRRP address. In this example, as the screen shot shows, the IP address is 10.1.10.100 Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the peer, which in this example is 200. In the Peer group type drop-down list, select EXTERNAL. Click Apply. An entry for the AS200 external peer group appears on the Network Voyager configuration page for the EVR, as the Example screen shot shows. 8. In the Add remote peer IP address text box, enter the IP address of the peer, which in this example, is 1.2.3.4. Click Apply. An entry for the peer IP address appears on the Network Voyager configuration page. 9. If the EVR is connecting to the peer through a VRRP interface, as in this example, click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface. Click Apply. 10. Click Save to make your changes permanent.
142
BGP
BGP Configuration of EVR
Configuring a BGP External Peer on the VS
Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as Example the screen shot of Network Voyager below shows, is vs2. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in the AS number text box for the VS, enter 100. Click Apply.
143
6. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the VS, which is the IP address of the wrp interface that connects the VS to the EVR. In this example, that IP address is 20.20.20.100, as the Example screen shot shows. Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the external peer, which in this example is 200. In the Peer group type drop-down list, select EXTERNAL. Click Apply. An entry for the AS external peer group appears on the Network Voyager configuration page for the VS, as the screen shot shows. 8. In the Add remote peer IP address text box, enter the IP address of the external peer, which in this example is 192.168.40.10. Click Apply. An entry for the peer address appears on the Network Voyager configuration page. 9. If the VS is connecting to a peer through a VRRP interface, click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface. Click Apply. 10. Click Save to make your changes permanent.
144
BGP
BGP Configuration of VS
Configuring the EVR and the VS as Internal BGP Peers
Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as Example Network Voyager screen below shows is v2. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in AS number text box for the VS, enter 100. Click Apply.
145
6. In the Firewall Address for the Nexthop Attribute text box, enter the IP address of the external interface of the VS, which in this example is the IP address of the wrp interface that connects the VS to the EVR. In this example, that IP address is 20.20.20.100, as the screen shot shows. Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the EVR, which in this example is 100. In the Peer group type drop-down list, select INTERNAL. Click Apply. An entry for the AS internal peer group appears on the Network Voyager configuration page. 8. In the Add remote peer IP address text box, enter the VRRP IP address of the external interface of the EVR, which in this example is 10.1.0.100. Click Apply, and the click Save to make your changes permanent.
146
BGP
BGP Configuration of VS as Internal Peer of EVR
9. Click Configuration in the tree view next to the name of the EVR, which in this example, as the Example Network Voyager screen shot below shows, is vs1. 10. Click the BGP configuration link in the Routing section. 11. As the screen shot shows, in the AS number text box for the EVR, enter 100. Click Apply. 12. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the EVR, which in a VSX cluster, is the VRRP address. In this example, as the Example screen shot shows, the IP address is 10.1.10.100 Click Apply. 13. In the Peer Autonomous system number text box enter the AS number of the VS, which in this example is 100.
147
In the Peer group type drop-down list, select INTERNAL. Click Apply. An entry for the AS internal peer group appears on the Network Voyager configuration page. 14. In the Add remote peer IP address text box, enter the IP address of the external interface of the VS, which is the IP address of the wrp interface that connects the VS to the EVR. In this example that IP address is 20.20.20.100. Click Apply, and then click Save to make your changes permanent.
BGP Configuration of EVR as internal Peer of VS
148
BGP
Configuring an External Router as BGP Peer of a VS, which sits behind the EVR
You can configure an external router, that is a router in the external network, as a BGP peer of a VS that sits behind the EVR. However that external router must use as the peer IP address the main IP address of the VS. This IP address, which the address of the external interface that points to the EVR is the same IP address you configure as the Firewall Address for Nexthop Attribute. The nexthop address must always be the IP address assigned to the external interface of the VS. This address is used in BGP updates. In the example for how to configure a BGP peer on a VS, that IP address is 20.20.20.100. For more information, see Configuring a BGP External Peer on the VS on page 143.
Example 2: BGP Configuration in a VRRP Setup with a VS Only

In this example you configure a BGP peer on the VS. As the Example Network Voyager screen shot below shows, in this example you configure an external peer for the VS and you must configure as the next hop address, the IP address of the external interface of the VS, which in a VRRP setup is the external VRRP IP address. Perform the following procedure on each member of the VSX cluster, that is, the VRRP pair. 1. Initiate a Network Voyager session. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the VS, which in this example, as Example the screen shot of Network Voyager below shows, is vs2. 4. Click the BGP link in the Routing section. 5. As the screen shot shows, in the AS number text box for the VS, enter 100. Click Apply. 6. In the Firewall Address for Nexthop Attribute text box, enter the IP address of the external interface of the VS, which is the IP address of the wrp interface that connects the VS to the EVR. In this example, that IP address is 20.20.20.100, as the Example screen shot shows. Click Apply. 7. In the Peer autonomous system number text box, enter the AS number of the peer, which in this example is 200. In the Peer group type drop-down list, select EXTERNAl. Click Apply. An entry for the AS external peer group appears on the Network Voyager configuration page for the VS, as the screen shot shows. 8. In the Add remote peer IP address text box, enter the IP address of the peer, which in this example is 192.168.40.10. Click Apply. An entry for the peer address appears on the Network Voyager configuration page. 9. If the VS is connecting to a peer through a VRRP interface, click on in the Virtual Address field to advertise the VRRP virtual IP address on this interface. Click Apply.
149

BGP Configuration of VS
Examples of BGP Configuration on a Standalone Gateway

The following two examples show you how to configure BGP on a Nokia Virtual Firewall for Check Point VSX standalone gateway. This means that VRRP is not configured. The following examples show how to configure a standalone gateway with an EVR and a VS with a VS and no EVR
150
BGP
In these examples, you use Check Point Provider-1 GUI to configure interfaces and IP address as well as an EVR and a VS before you configure BGP using Network Voyager. You must also modify the Provider-1 MDS to enable BGP. For more information, see Enabling BGP on Nokia Virtual Firewall for Check Point VSX on page 130.
Example 1: BGP Configuration in Standalone Setup With an EVR and a VS

In this example, you configure a BGP peer on the EVR a BGP peer on the VS the VS and EVR as BGP peers. BGP configuration of a Nokia Virtual Firewall for Check Point VSX standalone gateway is similar to that of a VSX cluster, except that you complete configuration only on a single gateway for the EVR and each VS because VRRP is not configured.
Configuring a BGP peer on the EVR
Complete the same procedure to configure the BGP external peer on the EVR for a VRRP setup. However, for a standalone setup, you only need to configure the EVR on a single gateway. For more information, see Configuring a BGP External Peer on the EVR on page 142.
Configuring a BGP peer on the VS
Complete the same procedure to configure the BGP external peer on the VS for a VRRP setup. However, for a standalone setup, you only need to configure each VS on a single gateway. For more information, see Configuring a BGP External Peer on the VS on page 143.
Configuring the EVR and VS as Internal BGP Peers
Complete the same procedure to configure the EVR and VS as internal BGP peers for a VRRP setup. However, for a standalone setup, you only need to configure the EVR and each VS as internal BGP peers on a single gateway. For more information, see Configuring the EVR and the VS as Internal BGP Peers on page 145.
Example 2: BGP Configuration in a Standalone Setup with a VR and No EVR

In this example you configure a BGP external peer on a VS BGP configuration of a Nokia Virtual Firewall for Check Point VSX standalone gateway is similar to that of a VSX cluster, except that you complete configuration only on a single gateway for the EVR and each VS because VRRP is not configured.
151
Configuring a BGP peer on the VS
Complete the same procedure to configure the BGP external peer on the VS for a VRRP setup. However, for a standalone setup, you only need to configure each VS on a single gateway. For more information, see Configuring a BGP External Peer on the VS on page 143.
BGP Neighbors Example

BGP has two types: internal and external. Routers in the same autonomous system that exchange BGP updates run internal BGP; routers in different autonomous systems that exchange BGP updates run external BGP. In the diagram below, AS100 is running IBGP, and AS200 and AS300 are running external BGP.
AS100 Nokia Platform A .1 .1 IBGP 10.50.10 Nokia Platform B .2 .2 IBGP 170.20.1 Nokia Platform C .1 .1
EBGP 129.10.21 .2 Nokia Platform D AS200
EBGP 172.17.10 .2 Nokia Platform E AS300

00331
Configuring IBGP on Nokia Platform A

1. Configure an Ethernet interface. 2. Configure an internal routing protocol such as OSPF or configure a static route to connect the platforms within AS100 to each other. For more information see Configuring OSPFor Creating a Static Route. 3. Click the Virtual Systems tab. 4. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 5. Click the BGP link in the Routing section. 6. Enter a router ID in the Router ID text box. The default router ID is the address of the first interface. An address on a loopback interface that is not the loopback address (127.0.0.1) is preferred. 7. Enter 100 in the AS number text box. 8. Enter 100 in the Peer autonomous system number text box. 9. Click INTERNAL in the Peer group type drop-down list; then click Apply. 10. Enter 10.50.10.2 in the Add remote peer IP address edit box; then click Apply.
152
BGP
11. Configure an inbound route filter for AS 100 according to BGP Route Inbound Policy Example.
Configuring IBGP on Nokia Platform B

1. Configure the interface as in Configuring an Ethernet Interface. 2. Configure an internal routing protocol such as OSPF or configure a static route to connect the platforms in AS100 to each other. For more information see Configuring OSPFor Creating a Static Route. 3. Click the Virtual Systems tab. 4. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 5. Click the BGP link in the Routing section. 6. Enter a router ID in the Router ID text box. The default router ID is the address of the first interface. An address on a loopback interface that is not the loopback address (127.0.0.1) is preferred. 7. Enter 100 in the AS number edit box. 8. Enter 100 in the Peer autonomous system number text box. 9. Enter 10.50.10.1 in the Add remote peer IP address text box; then click Apply. 10. Enter 170.20.1.1 in the Add remote peer IP address text box; then click Apply. 11. Configure an inbound route filter for AS100 according to BGP Route Inbound Policy Example.
Configuring IBGP on Nokia Platform C

1. Configure the interface as in Configuring an Ethernet Interface. 2. Configure an internal routing protocol such as OSPF or configure a static route to connect the platforms in AS100 to each other. For more information, see Configuring OSPFor Creating a Static Route. 3. Click the Virtual Systems tab. 4. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 5. Click the BGP link in the Routing section. 6. Enter a router ID in the router ID text box. The default router ID is the address of the first interface. An address on a loopback interface that is not the loopback address (127.0.0.1) is preferred. 7. Enter 100 in the AS number text box. 8. Enter 100 in the Peer autonomous system number text box. 9. Click INTERNAL in the Peer group type drop-down list; then click Apply. 10. Enter 170.20.1.2 in the Add remote peer IP address text box; then click Apply.
153
11. Configure an inbound route policy for AS100 according in BGP Route Inbound Policy Example.
Configuring Nokia Platform C as an IBGP Peer to Nokia Platform A

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Enter 10.50.10.1 in the Add remote peer IP address text box; then click Apply.
Configuring Nokia Platform A as an IBGP Peer to Nokia Platform C

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Enter 170.20.1.1 in the Add remote peer IP address text box; then click Apply.
Configuring EBGP on Nokia Platform A

1. Configure an Ethernet the interface on Nokia Platform A. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 4. Click the BGP link in the Routing section. 5. Enter 200 in the Peer autonomous system number text box. 6. Click EXTERNAL in the Peer group type drop-down list; then click Apply. 7. Enter 129.10.21.2 in the Add Remote Peer IP Address text box; then click Apply. 8. Configure route redistribution policy according to BGP Route Redistribution Example. 9. Configure an inbound route filter according to BGP Route Inbound Policy Example.
Configuring EBGP on Nokia Platform C

1. Click the Virtual Systems tab of Platform C. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Enter 300 in the AS number text box.
154
BGP
5. Click EXTERNAL in the Peer group type drop-down list; then click Apply. 6. Enter 172.17.10.2 in the Add remote peer IP address text box; then click Apply. 7. Configure route redistribution policy according to BGP Route Redistribution Example. 8. Configure an inbound route filter according to BGP Route Inbound Policy Example to allow Nokia Platform C to accept routes from its EBGP peer.
Configuring EBGP on Nokia Platform D

1. Configure an Ethernet interface on Nokia Platform D. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 4. Click the BGP link in the Routing section. 5. Enter a router ID in the Router ID text box. The default router ID is the address of the first interface. An address on a loopback interface that is not the loopback address (127.0.0.1) is preferred. 6. Enter 200 in the AS number text box. 7. Enter 100 in the Peer autonomous system number text box 8. Click EXTERNAL in the Peer group type drop-down window; then click Apply. 9. Enter 129.10.21.1 in the Add remote peer IP address text box; then click Apply. 10. Configure route inbound policy according to BGP Route Inbound Policy Example. 11. Configure route redistribution policy according to BGP Route Redistribution Example. 12. Configure an inbound route filter according to BGP Route Inbound Policy Example.
Configuring EBGP on Nokia Platform E

1. Configure an Ethernet interface on Nokia Platform E. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 4. Click the BGP link in the Routing section. 5. Enter 300 in the AS number edit box. 6. Enter 100 in the Peer autonomous system number text box. 7. Click EXTERNAL in the Peer group type drop-down list; then click Apply. 8. Enter 172.17.10.1 in the Add remote peer IP address edit box; then click Apply. 9. Configure route inbound policy according the BGP Route Inbound Policy Example. 10. Configure route redistribution policy according to BGP Route Redistribution Example. 11. Configure an inbound route filter according to BGP Route Inbound Policy Example.
155
Verification
To verify that you configured BGP neighbors correctly, log on to Network Voyager and click the Monitor link next to the instance name you configured, click the BGP link in the Routing Protocols section, and then click the neighbor link. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
Path Filtering Based on Communities Example

Note To filter BGP updates based on peer AS numbers, see Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number.
To 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 advertise, no subconfed, or none. 1. Click the Advanced BGP options link. 2. Click on in the Enable Communities field, then click Apply. 3. Follow the steps described in the Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number example. 4. Enter the community ID or the name of one of the special attributes in the Community ID/ Special community text box, then click Apply. 5. Click on button in the Redistribute All Routes field or enter specific IP prefixes to redistribute as described in the Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number example, then click Apply.
156
BGP
BGP Multi Exit Discriminator Example

Multi Exit Discriminator (MED) values are used to help external neighbors decide which of the available entry points into an AS is preferred. A lower MED value is preferred over a higher MED value.
AS100 Nokia Platform A Nokia Platform B Nokia Platform C AS200
EBGP AS4 EBGP Nokia Platform D

00339
In the above diagram, MED values are being propagated with BGP updates. This diagram shows four different configurations. Configuring Default MED for Nokia Platform D Configuring MED Values for all Peers of AS200 Configuring MED Values for each External BGP Peer for Nokia Platform D Configuring MED Values and a Route Redistribution Policy on Nokia Platform D
Configuring Default MED for Nokia Platform D

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Configure EBGP peers in AS100 and AS200 according to the BGP Neighbors Example. 5. Click the Advanced BGP Options link on the main BGP page. This action takes you to the Advanced Options for BGP page. 6. In the Miscellaneous settings field, enter a MED value in the Default MED edit box; then click Apply. 7. Click Save to make your changes permanent. This MED value is propagated with all of the BGP updates that are propagated by Nokia Platform D to all of its EBGP peers in AS100 and AS200.
157
Configuring MED Values for all Peers of AS200

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Configure EBGP peers in AS100 and AS200 according to the BGP Neighbors Example. 5. Click Advanced BGP Options link on the main BGP page. This action takes you to the Advanced Options for BGP page. 6. Go to the configuration section for 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 value.
Note Setting an MED value for all peers under the local AS overwrites the default MED setting of the respective internal peers.
Configuring MED Values for each External BGP Peer for Nokia Platform D
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Configure EBGP peers in AS100 and AS200 according to the BGP Neighbors Example. 5. Click the link for the peer IP address for Nokia Platform A under AS100. 6. Enter 100 in the MED sent out text box. 7. Click on in the Accept MED from external peer field; then click Apply. 8. Click the link for the peer IP address for Nokia Platform B under AS100. 9. Enter 200 in the MED sent out text box. 10. Click on in the Accept MED from external peer field; then click Apply. 11. Click the link for the peer IP address for Nokia Platform C under AS200. 12. Enter 50 in the MED sent out text box. 13. Click on in the Accept MED from external peer field; then click Apply. 14. Click Save to make your changes permanent. 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 value of 200) as the entry
158
BGP
point to AS100 while it propagates routes to AS100. Similarly, this configuration propagates routes with an MED value of 50 to AS200, although no multiple entry points exist to AS200.
Configuring MED Values and a Route Redistribution Policy on Nokia Platform D

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the BGP link in the Routing section. 4. Configure EBGP peers in AS100 and AS200 according to the BGP Neighbors Example. 5. Click the Route Redistribution link the Routing section. 6. Click the BGP link in the Redistribute to BGP section. 7. Enter 100 in MED edit box next to the Enable redistribute bgp routes to AS100 field. 8. Enter necessary information for route redistribution according to the BGP Multi Exit Discriminator Example; then click Apply. 9. Click Save to make your changes permanent. Setting an MED value along with route redistribution 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 redistribution overwrites the MED value for the external BGP peer for Nokia Platform D.
Verification
To verify that you configured BGP MED values correctly, run the following command in CLI.
show instance <instance name> route
For more information about this command, see the Nokia IPSO CLI Reference Guide. Note that IPSO 5.0 does not support BGP CLI commands to configure or monitor the routing protocol for a routing instance, that is, virtual system. You must use Network Voyager to configure and monitor BGP for a virtual system. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
159
Changing the Local Preference Value Example

AS100 Nokia Platform A 20.10.5.1/24 20.10.10.2/24 EBGP 20.10.5.2/24 AS676 Nokia Platform C
IBGP AS342
20.10.10.1/24 20.10.5.1/24 Nokia Platform B EBGP 20.10.15.2/24 Nokia Platform D

00332
Local preference is used in IBGP sessions to indicate the preference for an external route. The route with the highest local preference value is preferred. This example shows how to configure routes learned using Nokia Platform A to have a higher local preference value over Nokia Platform B, which has a default local preference value of 100. First, configure an IBGP link between Nokia platforms A and B as in Configuring IBGP on Nokia Platform A on page 152. Then complete the procedure below to set the local preference value of IBGP Peer Platform A. Setting the Local Preference Value for IBGP Peer Platform B 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on Autonomous System Number link. 5. Enter 512 (or any unique number in the range of 512 to 1024) in the Import ID text box. 6. Enter 100 in the AS text box. 7. Enter 200 in the LocalPref text box. 8. Click Apply. 9. Click Accept in the all routes from BGP AS 100 field; then click Apply. 10. Click Save to make your changes permanent.
160
BGP
BGP Confederation Example

AS65527 Confed 65525 Nokia Platform A .1 192.168.35 .2 Nokia Platform B .2 .2 AS65528 Confed 65525 Nokia Platform D .1 192.168.45 .2 Nokia Platform C AS65525
192.168.30
192.168.40 AS65524 Confed 65525
Nokia Platform E
.1
.1
To external AS
00333
In the above diagram, all the routers belong to the same Confederation 65525. Nokia platform A and Nokia platform B belong to routing domain ID 65527, Nokia platform C and Nokia platform D belong to routing domain ID 65528, and Nokia Platform E belongs to routing domain ID 65524. In this example, you configure Nokia platform B and Nokia platform C as members of Confederation 65525 and as members of separate routing domains within the confederation. You also configure each platform as confederation peers to Nokia platform E, which has a direct route to the external AS.
Configuring Platform C
1. Set up the confederation and the routing domain identifier. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65525 in the Confederation text box. f. Enter 65528 in the Routing domain identifier text box; then click Apply. 2. Create confederation group 65524. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP.
161
c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65524 in the Peer autonomous system number text box. f. Click CONFEDERATION in the Peer group type drop-down list; then click Apply. Define properties for the above group. g. Click on in the all field. h. Click on in the All Interfaces field; then click Apply. i. Enter 192.168.40.1 in the Add a new peer text box; then click Apply. 3. Create confederation group 65528. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Enter 65528 in the Peer autonomous system number text box. e. Click CONFEDERATION in the Peer group type drop-down list; then click Apply. Define properties for the above group. f. Click on in the all field. g. Click on in the All Interface field; then click Apply. h. Enter 192.168.45.1 in the Add a new peer text box; then click Apply. 4. Define BGP route inbound policy by using regular expressions for any AS path and from any origin. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Based on ASPath Regular Expressions link. e. Enter 1 in the Import ID text box and enter .* in the ASPATH Regular Expression text box; then click Apply. f. Click on in the Import all routes from AS path field; then click Apply. 5. Define route redistribution. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the Route Redistribution link in the Routing section. d. Click the BGP link in the Redistribute to BGP section.
162
BGP
e. Click 65528 in the Redistribute to Peer AS drop-down list. f. Click 65524 in the From AS drop-down list; then click Apply. g. Click on in the Enable redistribution of routes from AS 65524 into AS 65528 field; then click Apply. h. Click on in the all BGP AS 65524 routes into AS 65528; then click Apply. i. Click Save to make your changes permanent.
Configuring Platform B
1. Set up the confederation and the routing domain identifier. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65525 in the Confederation text box. f. Enter 65527 in the Routing domain identifier text box; then click Apply. 2. Create confederation group 65524. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65524 in the Peer autonomous system number text box. f. Click CONFEDERATION in the Peer group type drop-down list; then click Apply. Define properties for the above group. g. Click on in the all field. h. Click on in the All Interfaces field; then click Apply. i. Enter 192.168.30.1 in the Add a new peer text box; then click Apply. 3. Create confederation group 65527. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Enter 65528 in the Peer autonomous system number text box. e. Click CONFEDERATION in the Peer group type drop-down list; then click Apply.
163
Define properties for the above group. f. Click on in the all field. g. Click on in the All Interface field; then click Apply. h. Enter 192.168.35.1 in the Add a new peer text box; then click Apply. 4. Define BGP route inbound policy by using regular expressions for any AS path and from any origin. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure BGP. c. Click the BGP link in the Routing section. d. Click the Based on ASPath Regular Expressions link. e. Enter 1 in the Import ID text box and enter .* in the ASPATH Regular Expression text box; then click Apply. f. Click on in the Import all routes from AS path field; then click Apply. 5. Define route redistribution. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the Route Redistribution link in the Routing section. d. Click the BGP link in the Redistribute to BGP section. e. Click 65528 in the Redistribute to Peer AS drop-down list. f. Click 65524 in the From AS drop-down list; then click Apply. g. Click on in the Enable redistribution of routes from AS 65524 into AS 65527 field; then click Apply. h. Click on in the all BGP AS 65524 routes into AS 65528; then click Apply. i. Click Save to make your changes permanent.
164
BGP
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.
AS65525
Nokia Platform A
AS65526
Nokia Platform B .1 .1 192.168.20
IBGP Route reflector
.2
192.168.10 EBGP
.1 192.168.30
Client .2 Nokia Platform D
00334
.2 Client
Nokia Platform C
In the above diagram, router Nokia Platform A is on AS 65525, and routers Nokia Platform B, Nokia Platform C, and Nokia Platform D are in AS 65526. This example shows how to configure Nokia Platform B to act as a route reflector for clients Nokia Platform C and Nokia Platform D. You then configure platforms C and D as IBGP peers to platform D, as the example shows. Finally, you 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 the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Enter 65526 in the AS number text box; then click Apply. 2. Create an external peer group. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65525 in the Peer autonomous system number text box. f. Click EXTERNAL in the Peer group type drop-down list; then click Apply.
165
3. Enter the peer information. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 192.168.10.2 in the Add remote peer ip address text box under the AS65525 external group; then click Apply. 4. Create an internal group. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 65526 in the Peer auto autonomous system number text box. f. Select INTERNAL in the Peer group type drop-down list; then click Apply. 5. Configure parameters for the group. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Click on in the all field. This option covers all IGP and static routes. f. Click on in the All Interfaces field; then click Apply. 6. Enter the peer information. a. Click the Virtual Systems tab. b. Click Configuration in the tree view next to the name of the routing instance you want to configure. c. Click the BGP link in the Routing section. d. Click the Advanced BGP Options link. e. Enter 192.168.20.2 in the Add remote peer ip address text box under the AS65526 routing group. f. Select REFLECTOR CLIENT from the Peer type drop-down list; then click Apply. g. Click the Virtual Systems tab. h. Click the BGP link in the Routing section.
166
BGP
i. Click the Advanced BGP Options link. j. Enter 192.168.30.2 in the Add remote peer ip address text box under the AS65526 routing group. k. Select REFLECTOR CLIENT from the Peer type drop-down list; then click Apply.
Configuring Platform C as IBGP Peer of Platform B

1. Click the Virtual Systems tab of Platform C. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the BGP link in the Routing section. 4. Enter a router ID in the Router ID text box. The default router ID is the address of the first interface. An address on a loopback interface that is not the loopback address (127.0.0.1) is preferred. 5. Enter 65526 in the AS number text box. 6. Enter 65526 in the Peer autonomous system number text box. 7. Click INTERNAL in the Peer group type drop-down list; then click Apply. 8. Enter 192.168.20.1 in the Add remote peer IP address text box; then click Apply. 9. Click Save to make your changes permanent.
Configuring Platform D as IBGP Peer of Platform B

1. Click the Virtual Systems tab of Platform C. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the BGP link in the Routing section. 4. Enter a router ID in the Router ID text box. The default router ID is the address of the first interface. An address on a loopback interface that is not the loopback address (127.0.0.1) is preferred. 5. Enter 65526 in the AS number text box. 6. Enter 65526 in the Peer autonomous system number text box. 7. Click INTERNAL in the Peer group type drop-down list; then click Apply. 8. Enter 192.168.30.1 in the Add remote peer IP address text box; then click Apply. 9. Click Save to make your changes permanent.
167
Configuring BGP Route Inbound Policy on Platform B

1. Click the Virtual Systems tab of Platform B. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on Autonomous System Number link. 5. Enter 512 in the Import ID text box and enter 65526 in the AS edit box; then click Apply. 6. Click accept in the all BGP routes from AS 65526 field; then click Apply. 7. Enter 513 in the Import ID edit box and enter 65525 in the AS edit box; then click Apply. 8. Click accept in the all BGP routes from AS 65525 field; then click Apply. 9. Click Save to make your changes permanent.
Configuring Redistribution of BGP Routes on Platform B

Complete this procedure to redistribute BGP routes to BGP that select a different AS. This is equivalent to configuring an export policy. In this example, as the diagram shows, platform B, which is part of AS 65526, is an EBGP peer to platform A, which belongs to AS 65525. 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Route Redistribution link in the Routing section. 4. Click the BGP Routes Based on AS link in the Redistribute to BGP section. 5. Select 65526 in the Redistribute to Peer AS drop-down list and select 65525 in the From AS drop-down window. 6. Click on in the Enable redistribute BGP routes from AS 65525 into AS 65526 field; then click Apply. 7. Click accept in the all BGP ASPATH 65525 routes into AS 65526 field; then click Apply. 8. Select 65525 in the Redistribute to Peer AS drop-down list and select 65526 in the From AS drop-down list. 9. Click on in the Enable redistribute BGP routes from AS 65526 into AS 65525 field; then click Apply. 10. Click accept in the all BGP ASPATH 65526 routes into AS 65525 field; then click Apply. 11. Click Save to make your changes permanent.
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.
168
BGP
Communities are used to simplify the BGP inbound and route redistribution 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 numbercommunity ID combination.
To restrict incoming routes based on their community values, see Path Filtering Based on Communities Example. To redistribute routes that match a specified community attribute, append a community attribute value to an existing community attribute value, or both.
Note The examples that follows is valid only for redistributing routes from any of the specified routing protocols to BGP. For example, configuring community-based route redistribution policy from OSPF to BGP automatically 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 propagate to the redistribution policy for the interface routes into BGP.
1. Follow the steps in the Redistributing OSPF to BGP Example. 2. Match the following ASes with the following community IDsAS 4 with community ID 1 (4:1), AS 5 with community ID 2 (5:2), AS with no exportby entering the AS values in the AS text box and the community IDs in the Community ID/Special community text box; then click Apply.
Note Matching an AS with the no export option only matches those routes that have all of the preceding AS number and community ID values.
3. To append an AS number and community ID combination 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 box; then click Apply. 5. Match AS with no advertise; then click Apply.
Note Matching an AS with the no advertise option appends the community attribute with the values described in step 2. Thus, all of the routes with the community attributes set to 4:1, 5:2, and no export are redistributed with the appended community attributes 4:1, 5:2, no export, 6:23, and no advertise.
169
EBGP Load Balancing Example: Scenario #1

Loopback interfaces are used to configure load balancing for EBGP 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 route redistribution 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 Platform B has a loopback address of 5.6.7.8.
AS100 Nokia Platform A 129.10.1.1
Loopback 1.2.3.4
AS200 Nokia 129.10.1.2 Platform B 129.10.2.2

Loopback 5.6.7.8
129.10.2.1
00335
Configuring a Loopback Address on Platform A

1. Configure an Ethernet interface. 2. Click the Interfaces link on the Configuration page. 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 an Ethernet interface. 2. Click the Interfaces link on the Configuration page. 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 a Static Route on Platform A

1. Click the Static Routes link in the Routing section. 2. Enter 5.6.7.8 in the New static route text box to reach the loopback address of Platform B.
170
BGP
3. Enter 32 in the Mask length edit box; then click Apply. 4. Enter 129.10.2.2 in the Additional gateway edit box; then click Apply. 5. Enter 129.10.1.2 in the Additional gateway edit box; then click Apply.
Configuring a Static Route on Platform B

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. Enter 1.2.3.4 in the New static route text box to reach the loopback address of Platform A. 5. Enter 32 in the Mask length text box; then click Apply. 6. Enter 129.10.2.1 in the Additional gateway edit box; then click Apply. 7. Enter 129.10.1.1 in the Additional gateway text box; then click Apply.
Configuring an EBGP Peer on Platform A

1. Configure an EBGP peer on Platform A as in BGP Neighbors Example. 2. Enter 1.2.3.4 as the local address on the main BGP configuration page. Click Apply. 3. Configure the inbound and route redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action takes you the page that lets you configure options for that peer. 5. In the Nexthop field, click on next to EBGP Multihop to enable the 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 BGP Neighbors Example. 2. Enter 5.6.7.8 as the local address on the main BGP configuration page. 3. Configure the inbound and route redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action takes you the page that lets you configure options for that peer. 5. In the Nexthop field, click on next to EBGP Multihop to enable the 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.
171
EBGP Load Balancing Example: Scenario #2

Configuring a Loopback Address on Platform A
1. Configure an Ethernet interface. 2. Click the Interfaces link on the Configuration page. 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 an Ethernet interface. 2. Click the Interfaces link on the Configuration page. 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 the OSPF link in the Routing section. 2. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.1.1; then click Apply. 3. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.2.1; then 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 the OSPF link in the Routing section. 2. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.1.2; then click Apply. 3. Select the backbone area in the drop-down list for the interface whose IP address is 129.10.2.2; then 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 BGP Neighbors Example. 2. Enter 1.2.3.4 as the local address on the main BGP configuration page. 3. Configure the inbound and route redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action takes you the page that lets you configure options for that peer.
172
BGP
5. In the Nexthop field, click on next to EBGP Multihop to enable the 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 Nokia Platform B as in BGP Neighbors Example. 2. Enter 5.6.7.8 as the local address on the main BGP configuration page. 3. Configure the inbound and route redistribution policies. 4. Click the link for specific peer you configured in Step 1. This action takes you the page that lets you configure options for that peer. 5. In the Nexthop field, click on next to EBGP 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 and the range is 1 to 255. Click Apply.
Verification
To verify that you have configured load balancing correctly, run the following command in CLI:
show instance <vsid> route
For more information about this command, see the Nokia IPSO CLI Reference Guide. Note that IPSO 5.0 does not support BGP CLI commands to configure or monitor the routing protocol for a routing instance, that is, virtual system. You must use Network Voyager to configure or monitor BGP for a virtual system. For additional verification, log onto Network Voyager, click the Monitor link next to the instance name you configured, click the BGP link in the Routing Protocols section, and then click the neighbor link. For more information about monitoring BGP using Network Voyager, see the Displaying Routing Protocol Information in the Nokia Network Voyager documentation.
Adjusting BGP Timers Example

1. Configure a BGP neighbor as in the BGP Neighbors Example. 2. Click the link for the peer IP address to configure peer-specific parameters. 3. Enter a value in seconds in the Holdtime text box.
173
Holdtime indicates the maximum number of seconds that can elapse between the receipt of successive keepalive or update messages by the sender before 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 Keepalive text box; then click Apply. BGP does not use any transport-protocol-based keepalive mechanism to determine whether peers are reachable. Instead, keepalive messages are exchanged between peers to determine whether the peer is still reachable. The default value is 60 seconds. 5. To make your changes permanent, click Save.
TCP MD5 Authentication Example

AS100 Nokia Platform A 10.10.10.1/24 EBGP 10.10.10.2/24 AS200 Nokia Platform B
00336
Configuring TCP MD5 Authentication on Nokia Platform A

1. Configure an Ethernet interface. 2. Click the BGP link in the Routing section. 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 Peer group type drop-down list; then click Apply. The following steps configure an EBGP peer with MD5 authentication 7. Enter 10.10.10.2 in the Add remote peer ip address text box; then click Apply. 8. Click the 10.10.10.2 link to access the BGP peer configuration page 9. Select MD5 as the authentication type from the AuthType drop-down list; then click Apply. 10. Enter the MD5 shared key (test123 for example) in the Key text box; then click Apply.
174
BGP
Configuring BGP Route Redistribution on Nokia Platform B

1. Configure an Ethernet interface. 2. Click the BGP link in the Routing section. The following three steps enable BGP 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. 6. Click EXTERNAL in the Peer group type drop-down list; then click Apply. The following steps configure an EBGP 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 authentication type from the AuthType drop-down list; then click Apply. 10. Enter the MD5 shared key (test123 for example) 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 stability of flapping routes. The value of this matrix increases as routes become more unstable and decreases as 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 the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the BGP link in the Routing section. 4. Click the Advanced BGP Options link. 5. Enable weighted route dampening by clicking on in the Enable weighted route dampening field; then click Apply. The following fields are displayed:
175
Field Suppress above
Default value 3
Units of measurement Number of route flaps or approximate value of the instability metric Same as above Same as above Seconds Seconds Seconds
Reuse below Max flaps Reachable decay
2 16 300
Unreachable decay 900 Keep history 1800
6. Enter any changes in the text boxes that correspond to the appropriate fields, then click Apply.
Verification
To verify that you have configured route dampening correctly, run the following command in CLI.: show instance <vsid> route For more information about this command, see the Nokia IPSO CLI Reference Guide. Note that IPSO 5.0 does not support CLI commands for configuring or monitoring BGP for a routing instance, that is, virtual system. You must use Nokia Network Voyager to configure and to monitor BGP for a virtual system. For more information about how to monitor BGP using Network Voyager, see the Displaying Routing Protocol Information section in the Nokia Network Voyager documentation.
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 weight value is not 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 implementation of weight value differs from that of other vendors.
If the weights are the same, prefer the path 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).
176
Static Routes
If the origin codes are the same, prefer the path with the lowest MED attribute (if MED is not ignored). If the paths have the same MED, prefer the external path 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 address, as specified by the BGP router ID.
Static Routes
Static routes (also known as statics) are routes that you manually configure in the routing table. Static routes do not change and are not dynamic (hence the name). Static routes cause packets addresses to the destination to take a specified next hop. Static routes allow you to add routes to destinations that are not known by dynamic routing protocols. Static routes can also be used in providing a default route. Static routes consist of the following: Destination Type Next-hop gateway Static routes can be one of the following types: Normal A normal static route is one used to forward 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 route discards packets that match the route for a given 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.
Static Routes on Nokia Virtual Firewall for Check Point VSX Gateway
The Check Point GUI sets static routes on a Nokia Virtual Firewall for Check Point VSX gateway. If you configure a static route using either Network Voyager or the CLI, it is not persistent across all policy installations or when you reboot the appliance. If you check the Propagate Route to EVR option in the Check Point Provider-1 GUI when configuring a VS, the GUI installs a static route for that IP address or subnet in the EVR. For an IP address, the static route points to the main IP address of the VS. For a subnet, the static route points to the VLAN subnet of the VS.
177
The Check Point GUI installs a default route in each VS that points to the EVR. You can use Network Voyager to override that default route. For more information, see Configuring Gateway to Ignore Default Route on page 86.
Configuring a Default Route

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure a default route. 3. Click the Static Routes link in the Routing section. 4. To enable a default route, click on in the Default field; then click Apply. 5. Select the type of next hop the static route will take from the Next Hop Type drop-down list. 6. Select the gateway type of the next hop router from the Gateway Type drop-down list.
Note Gateway Address specifies the IP address of the gateway to which forwarding packets for each static route are sent.
Note If you are configuring a default route between a virtual system and a virtual router, you must specify the Gateway Type as LOGICAL NAME and then select the wrp interface between the virtual system and virtual router as the logical gateway. Use a logical gateway only if the next hop is reachable by a point-to-point interface and the IP address of the gateway is unknown.
7. Click Apply. 8. If you specified: Gateway Type as ADDRESS, enter the IP address of the default router in the Gateway text box Gateway Type as LOGICAL NAME, select the logical interface from the selection box. Click Apply. 9. To disable a default route, click off in the Default field; then click Apply. 10. To make your changes permanent, click Save.
178
Static Routes
Creating a Static Route

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to create a static route. 3. Click the Static Routes link in the Routing section. 4. Enter the network prefix in the New Static Route text box. 5. Enter the mask length (number of bits) in the Mask Length text box. 6. Select the type of next hop the static route will take from the Next Hop Type drop-down list. 7. Select the gateway type of the next hop router from the Gateway Type drop-down list.
Note Gateway Address specifies the IP address of the gateway to which forwarding packets for each static route are sent.
Note If you are configuring a default route between a virtual system and a virtual router, you must specify the Gateway Type as LOGICAL NAME and then select the wrp interface between the virtual system and virtual router as the logical gateway. Use a logical gateway only if the next hop is reachable by a point-to-point interface and the IP address of the gateway is unknown.
8. Click Apply. 9. If you specified: Gateway Type as ADDRESS, enter the IP address of the default router in the Gateway text box Gateway Type as LOGICAL NAME, select the logical interface from the selection box. Click Apply. 10. To make your changes permanent, click Save.
Setting the Rank for Static Routes

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. You are now in the Static Routes page. Click the Advanced Options link. 4. To set the rank for each static route you have configured, enter a value in the Rank text box.
179
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. 5. Click Apply, and then click Save to make your changes permanent.
Configuring Multiple Static Routes

The implementation allows you to add and configure many static routes at the same time.
Note You cannot configure a logical interface through the quick-add static routes option.
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. 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 information on static route types, see BGP. 5. 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. Use the following format: IP address/mask length next hop IP address The IP addresses must be specified in a dotted-quad format ([0 to 255]).[0 to 255].[0 to 255].[0 to 255]) 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 6. Press ENTER after each entry you make for a static route. 7. Click Apply. The newly configured additional static routes appear in the Static Route field at the top of the Static Routes page.
Note The text box displays any entries that contain errors. Error messages appear at the top of the page.
180
Static Routes
Adding and Managing Static Routes Example

The figure below shows the network configuration for the example.
Nokia Platform B
26.66/30 26.69/30
OSPF 24.45/30 Nokia Platform A 26.2/24 Default Static Routes Corporate WAN Static Routes Nokia Platform C
26.70/30
OSPF
26.73/30
26.74/30
Nokia Platform D
24.0/24
22.1/22
Network Prefix: 192.168.0.0
Internet
Remote PCs
00345
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 WAN is between Nokia platform B and Nokia platform C, and no routing occurs on this link. Use static routes so that the remote PC LAN can have Internet access. Static routes apply in many areas, such as connections to the Internet, across corporate WANs, and creating routing boundaries between two routing domains.
Creating and Removing Static Routes

For the preceding example, one static default route to the Internet is created through 192.168.22.1/22, and a static route is created across the corporate WAN to the remote PC LAN across 192.168.26.68/30. Creating a static default route 1. Use Network Voyager to connect to Nokia Platform A. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure. 4. Click the Static Routes link in the Routing section. 5. Click on in the Default field; then click Apply. 6. In the gateway text box enter: 192.168.22.1; then click Apply. You should now have one static default route in your routing tables on Nokia Platform A. For the rest of the network to know about this route, you must redistribute the static route to OSPF. After you complete this task, any gateway connected to Nokia Platform B has the default route with 192.168.22.1 as the next hop in the routing tables. Any packet not destined for the 192.168.22.0/ 22 net is directed towards 192.168.22.1.
181
Creating a static route (non-default) 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. In the New Static Route text box enter: 192.168.24.0. 5. In the Mask Length text box enter: 24. 6. In the Gateway text box enter: 192.168.26.70; then click Apply. If you have configured OSPF or RIP on your remote office network, you now have connectivity to the Internet. Disabling a static route 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. Click off for the route you want to disable; then click Apply.
Backup Static Routes

Static routes can become unavailable if the interface related to the currently configured gateway is down. In this scenario, you can use a backup static route instead. To 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 the gateways that belong to the interface are deleted from the list of next-hop selections. Backup static routes are useful for default routes, but you can not use them for any static route.
Creating a Backup Static Route

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section.
Note This example assumes that a static route has already been configured and the task is to add backup gateways.
182
Route Aggregation
4. Enter the IP address of the gateway in the Additional gateway text box. 5. 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 Priority edit boxes are displayed. To add more backup static routes, repeat steps 3 and 4. 6. To make your changes permanent, click Save.
Deleting a Backup Static Route

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. Click off for the backup static route to delete; then click Apply. 5. To 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 advertises. The aggregates are activated by contributing routes. For example, if a router has many interface routes subnetted from a class C and is running RIP 2 on another interface, the interface routes can be used to create an aggregate route (of the class C) that can then be redistributed into RIP. Creating an aggregate route reduces the number of routes advertised using RIP. You must take care must be taken when aggregating 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 routes must be provided. A contributing route is defined 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 contributing routes, but at least one of the routes must be present to generate an aggregate. Aggregate routes are not used for packet forwarding by the originator of the aggregate route, only by the receiver. A router receiving a packet that does not match one of the component routes that led to the generation of an aggregate route responds with an ICMP network unreachable message. This message prevents packets for unknown component routes from following a default route into another network where they would be continually forwarded back to the border router until their TTL expires.
183
Creating Aggregate Routes

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to create an aggregate route. 3. Click the Route Aggregation link in the Routing section. 4. Enter the prefix for the new contributing route in the Prefix for new aggregate text box. 5. Enter the mask length (number of bits) in the Mask Length field; then click Apply. The mask length is the prefix length that matches the IP address to form an aggregate to a single routing table entry. 6. Scroll through the New Contributing Protocol list and click the protocol to use for the new aggregate route; then click Apply. 7. Click on in the Contribute All Routes from <protocol> field. 8. (Optional) If you want to specify a prefix, fill in the address and mask in the New Contributing Route from <protocol> field; then click Apply. 9. To make your changes permanent, click Save.
Removing Aggregate Routes

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to remove an aggregate route. 3. Click the Aggregation link in the Routing section. 4. Click off for the aggregate route disable; then click Apply. 5. To make your changes permanent, click Save.
184
Route Aggregation
Route Aggregation Example

The figure below shows the network configuration for the example.
Nokia Platform B
Nokia Platform C
24.46/30
24.49/30
24.50/30
24.53/30 24.54/30
Backbone Area all routers are running OSPF
Network Prefix: 192.168.0.0

24.45/30 Nokia Platform A 26.2/24
Nokia Platform D
Advertise 192.168.24.0
Backbone running RIPv1
00344
26.1/24
In the preceding figure Nokia Platform B, Nokia 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 figure. Configure route aggregation of 192.168.24.0/24 from the OSPF side to the RIP side. 1. Initiate a Network Voyager session to Nokia Platform A. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure. 4. Click the Route Aggregation link in the Routing section. 5. Enter 192.168.24.0 in the Prefix for new aggregate text box. 6. Enter 24 in the Mask Length edit box; then click Apply. 7. Click OSPF2 in the New Contributing Protocol drop-down list; then click Apply. 8. Click on in the Contribute all matching routes from OSPF2 field; then click Apply. 9. Click DIRECT in the New Contributing Protocol drop-down list; then click Apply. 10. Click on in the Contribute All Matching Routes from direct field; then click Apply. 11. Click TOP. 12. Click the Route Redistribution link in the Routing section. 13. Click the Aggregates Routes link in the Redistribute to RIP section. 14. Click on radio button in the Export all aggregates into RIP field; then click Apply.
185
Note If the backbone is running OSPF as well, you can enable aggregation only by configuring the 192.168.24.0 network in a different OSPF Area.
Route Rank
The route rank is the value that the routing subsystem uses to order routes from different protocols to the same destination. You cannot use rank to control the selection of routes within a dynamic interior gateway protocol (IGP); this is accomplished automatically by the protocol and is based on the protocol metric. You 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 route has only one rank associated with it, even though rank can be set at many places in the configuration. The route derives its rank from the most specific route match among all configurations. The active route 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 protocolsBGP and aggregatesallow for routes with the same rank. To choose the active route in these cases, a separate tie breaker is used. This tie breaker is called LocalPref for BGP and weight for aggregates.
Rank Assignments
A default rank is assigned to each protocol. Rank values range from 0 to 255, with the lowest number indicating the most preferred route. The table below summarizes the default rank values.
Preference of Interface routes OSPF routes Static routes IGRP routes RIP routes Aggregate routes Default 0 10 60 80 100 130
186
Route Rank
Preference of OSPF AS external routes BGP routes
Default 150 170
Setting Route Rank

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Route Options link in the Routing section. 4. Enter the route rank for each protocol; then click Apply. These numbers do not generally need to be changed from their defaults. Be careful when you modify these numbers; strange routing behavior might occur as a result of arbitrary changes to these numbers. 5. To 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 network configuration for the example:
26.66/30
26.65/30
Nokia Platform B
26.69/30
26.70/30
Nokia Platform C
26.73/30 26.74/30
Nokia Platform A
26.61/24
Nokia OSPF Backbone RIP to OSPF Border 26.78/28
Nokia Platform D
26.77/28
26.1/24 0.0.0.0/0 24.0/24 22.0/24 UNIX Hosts with Routed Enabled
Hub
RIP Network
Corporate Net
26.79/28
26.80/28
00337
In the preceding figure, the top part of the network is running OSPF and the bottom part of the network is running RIP. Nokia Platform D learns network 192.168.22.0 from two routing protocols: RIP from the bottom of the network, and OSPF from the top of the network. When
187
other hosts want to go to 192.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 available route to reach the destination. To configure the routing preferences: 1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Routing Options link in the Routing section. 4. Enter 10 in the OSPF edit box. 5. Enter 40 in the RIP edit box; then click Apply. This configuration makes the OSPF route the preferred route. To make the RIP route be the preferred route, enter 40 for OSPF and 10 for RIP.
Setting Rank for Static Routes

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Static Routes link in the Routing section. 4. Click the Advanced Options link. 5. Select the route for which to set the rank. 6. Set the rank to the value that you want; then click Apply. 7. To make your changes permanent, click Save.
Route Redistribution
Route redistribution allows routes learned from one routing protocol to be propagated to another routing protocol. This is necessary when routes from one protocol such as RIP, IGRP, OSPF, or BGP need to be advertised into another protocol (when two or more routing protocols are configured on the same router). Route redistribution is also useful for advertising static routes (for example, the default route) or aggregates into a protocol.
Note Route metrics are not translated between different routing protocols.
When you leak routes between protocols, specify routes that are to be injected and routes that are to be excluded. In the case where the prefix is redistributed, you can the metric to advertise.
188
For each prefix that is to be redistributed or excluded, the prefix is matched against a filter. The filter is composed of a single IP prefix and one of the following modifiers: normal, exact, refines, and range. The default modifier is normal. Normal matches any route that is equal to or more specific than the given prefix. Exact matches a route only if it equals the IP address and mask length of the given prefix. Refines matches a route only if it is more specific than the given prefix. Range matches any route whose IP address equals the given prefixs IP address and whose mask length falls within the specified mask length range. A sample route redistribution examples follow.
Note The Route Redistribution link contains over thirty possible route redistribution options.
BGP Route Redistribution Example

Route redistribution allows you to redistribute routes from one autonomous system into another autonomous system.

00339
Configuring BGP Route Redistribution on Nokia Platform D

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 1. Click the Route Redistribution link in the Routing section. 2. Click the BGP Routes based on AS link 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.
189
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.
Redistributing a Single Route

1. To restrict route redistribution 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 Type drop-down list; then click Apply. This procedure enables redistribution of route 100.2.1.0/24 from AS 4 to AS 100. No other routes are redistributed.
Redistributing All Routes

1. To allow all routes to redistributed, click Accept next to All BGP AS 4 routes into AS 100 field. 2. Click Apply.
Redistributing RIP to OSPF Example

In this example, Nokia Platform A is connected to a RIP network 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 running routed.
190
Note routed is a utility that runs by default on most Unix workstations. This utility listens to RIP network updates and chooses a default route based on what is advertised. This process eliminates the need for static routes and provides route redundancy. Because routed does not send route updates, it is called a passive RIP listener. This subnet (192.168.26.64/28) is categorized as a stub network, meaning that a particular subnet does not send RIP routing updates.
26.66/30 26.65/30 Nokia Platform A 26.61/24
Nokia Platform B
26.69/30
26.70/30
Nokia Platform C
26.73/30 26.74/30
Nokia OSPF Backbone RIP to OSPF Border 26.78/28
Nokia Platform D 26.77/28
26.1/24 0.0.0.0/0 24.0/24 22.0/24 UNIX Hosts with Routed Enabled
Hub
RIP Network
Corporate Net 26.79/28 26.80/28

00337
Redistributing Routes from RIP to OSPF External

Routes are redistributed from the corporate RIP network to the Nokia OSPF network through Nokia Platform A.
Note Make sure that the Corporate net RIP router is advertising RIP on the interface connected to the Nokia network. It must be receiving and transmitting RIP updates. Nokia does not currently support the notion of trusted hosts for authentication of RIP routes.
1. Connect to Nokia Platform A using Voyager. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure.
191
4. Click the Route Redistribution link under the Routing section. 5. Click the RIP link under the Redistribute to OSPF External section. 6. To redistribute all routes, click Accept in the All RIP routes into OSPF External field. (Optional) To change the cost metric for RIP Routes into OSPF Externals, enter the new cost metric in the Metric text box, then click Apply. 7. To prevent 192.168.22.0/24 and other more specific routes from being redistributed into OSPF External, define a route filter to restrict only this route as follows: a. To 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 type drop-down list. This specifies to prefer routes that are equal to or more specific than 192.168.22.0/24. c. Click Apply. The filter is fully configured.
Redistributing Routes from OSPF to RIP

Routes are redistributed from the Nokia OSPF network to the Corporate RIP Network. 1. Use the Voyager connection to Nokia Platform A you have from Redistributing Routes from RIP to OSPF External. 2. Click the Virtual Systems tab. 3. Click Configuration in the tree view next to the name of the routing instance you want to configure. 4. Click the Route Redistribution link under the Routing section. 5. Click the OSPF link in the Redistribute to RIP section. 6. To export all OSPF routes into RIP, click Accept in the All OSPF routes into RIP field; then click Apply. (Optional) To change the cost metric for RIP Routes into OSPF Externals, enter the new cost metric in the Metric text box; then click Apply. 7. If you do not want to export all OSPF routes into RIP, click Restrict and define a route filter to advertise only certain OSPF routes into RIP. 8. Assume that Nokia Platform B has another interface not shown in the diagram and that it has two additional OSPF routes: 10.0.0.0/8 and 10.1.0.0/16. To exclude all routes that are strictly more specific 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 route. a. To 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 type drop-down list. This specifies that you want routes that are strictly more specific than 10.0.0.0/8.
192
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

AS4 26.66/30 26.65/30 Nokia Platform A 26.61/24 EBGP AS100 26.1/24 Nokia Platform E EBGP AS200 26.77/28 Nokia Platform F
00338
Nokia Platform B
26.69/30
26.70/30
Nokia Platform C
26.73/30 26.74/30
Nokia OSPF Backbone
Nokia Platform D 26.77/28
Nokia Platform A is running OSPF and BGP and its local AS is 4. Nokia Platform E of AS 100 and Nokia Platform A of AS 4 are participating in an EBGP session. Nokia Platform F of AS 200 and Nokia Platform D of AS 4 are also participating in an EBGP session.
Nokia Platform A
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Route Redistribution link in the Routing section. 4. Click the OSPF link in the Redistribute to BGP section. 5. To redistribute OSPF routes into peer AS 100, select 100 from the Redistribute to peer AS drop-down list, then click Apply. 6. (Optional) Enter the MED in the MED text box; then click Apply. 7. (Optional) Enter the local preference in the LocalPref text box, then click Apply. 8. To redistribute OSPF routes, enter the IP prefix in the New IP prefix to redistribute text box and the mask length in Mask length text box; then click Apply.
193
Inbound Route Filters

Inbound route filters allow a network administrator to restrict or constrain the set of routes that a given routing protocol accepts. The filters let an operator to include or exclude ranges of prefixes from the routes that are accepted into RIP, IGRP, OSPF and BGP. These filters are configured in the same way as the filters for route redistribution. An administrator can specify two possible actions for each prefix. These actions are either to accept the address into the routing protocol (with a specified rank), or to exclude the prefix. You can specify the type of prefix matching that should be done for filter entries in the following ways:. 1. Routes that exactly match the given prefix; that is, have the same network portion and prefix length. 2. Routes that match more specific prefixes but do not include the given prefix. For example, if the filter is 10/8, then any network 10 route with a prefix length greater than 8 matches, but those with a prefix length of 8 do not match. 3. Routes that match more specific prefixes and include the given prefix. For example, if the filter is 10/8, then any network 10 route with a prefix length greater than or equal to 8 matches. 4. Routes that match a given prefix with a prefix length between a given 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.
Configuring IGP Inbound Filters

1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Filter Inbound RIP Routes link.
Note All other IGPs are configured in exactly the same way.
5. In the All Routes Action field, click either accept or restrict. If you select accept, routes can be rejected individually 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 length in the appropriate fields. 6. If you set All Routes to accept and click Apply, the Rank field is displayed. In the Rank field you can specify the rank to a value that all routes should have. The range of values is 1 to 255.
194
7. Enter the appropriate IP address and mask length in the New Route to Filter and Mask Length fields; then click Apply. A new set of fields is displayed adjacent to the newly entered IP address and mask length. 8. Click on or off to enable or disable filtering of this route. 9. From the Match Type field drop-down list, select NORMAL, EXACT, REFINES, or RANGE. 10. In the Action field, click Accept or Restrict to determine what to do with the routes that match the given filter. 11. In the Rank field, enter the appropriate value, and then click Apply. 12. If this completes your actions for this route filtering option, click Save. 13. If this does not complete your actions for this route filtering option, begin again at step 6.
BGP Route Inbound Policy Example

You can selectively accept routes from different BGP peers based on a peer autonomous system or an AS path regular expression.

00339
Configuring Route Inbound Policy on Nokia Platform D Based on an Autonomous System Number
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on Autonomous System Number link. 5. Enter 512 in the Import ID edit box. Import ID specifies the order in which the import lists are applied to each route. The range for filters based on AS numbers is from 512 to 1024. 6. Enter 100 in the AS text box; then click Apply.
195
This is the AS number from which routes are to be filtered. 7. (Optional) Enter more values in the Import ID and AS text boxes to configure more inbound policies based on autonomous system numbers; then click Apply.
Note By default, all routes originating from the configures ASes are accepted.
You can accept or reject all routes from a particular AS by enabling the accept or restrict option next to the All BGP routes from AS field. 1. You 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 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. 2. To 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. 3. Select refines in the Match type drop-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.
Configuring Route Inbound Policy on Nokia Platform D Based on ASPATH Regular Expressions
1. Click the Virtual Systems tab. 2. Click Configuration in the tree view next to the name of the routing instance you want to configure. 3. Click the Inbound Route Filters link in the Routing section. 4. Click the Based on ASPATH Regular Expressions link. 5. 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 511. 6. Enter a regular expression that identifies a set of ASes that should be matched with the SPATH sequence of the route:
100|200
This sequence accepts all routes whose ASPATH sequence contains 100 or 200 or both. 7. Select one of the origin options from the Origin drop-down list; then click Apply.
196
These options detail the completeness of AS path information. An origin of IGP indicates that an interior routing protocol-learned route was learned from an interior routing protocol and is most likely complete. An origin of EGP indicates the route was learned from an exterior routing protocol that does not support AS paths, and the path is most likely incomplete. When the path information is incomplete, an origin of incomplete is used. 8. Enter a new route filter. In this 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. To configure this filter, enter 10.0.0.0 in New IP prefix to import edit box, and 8 in Mask length edit box; then click Apply. 10. Select refines in the Match type drop-down list. This specifies routes that are strictly more specific than 10.0.0.0/8. 11. Finally, click restrict in the Action field. This specifies to discard the routes that match this prefix. 12. Click Apply. The filter is fully configured.
BGP AS Path Filtering Example

BGP updates restrict the routes a router learns or advertises. You can filter these updates based on ASPATH regular expressions, neighbors (AS numbers), or community IDs. To filter BGP updates based on ASPATH regular expressions, see Configuring Route Inbound Policy on Nokia Platform D Based on ASPATH Regular Expressions. The following examples, however, give a more detailed description of how to create ASPATH regular expressions.
ASPATH Regular Expressions

1. To accept routes that transit through AS 3662, enter the following ASPATH regular expression in the ASPATH Regular Expression text box:
(.* 3662 .*)
Select ANY from the Origin drop-down list; then click Apply. 2. To accept routes whose last autonomous system is 3662, enter this ASPATH regular expression in the ASPATH Regular Expression text box:
(.* 3662)
Select ANY from the Origin drop-down list; then click Apply. 3. To accept routes that originated from 2041 and whose last autonomous system is 701, enter the following ASPATH regular expression in the ASPATH Regular Expression text box:
2041 701
Select ANY from the Origin drop-down list; then click Apply.
197
4. To accept SPRINT (AS number 1239) routes that transit through AT&T (AS number 7018) or InternetMCI (AS number 3561), enter the following ASPATH regular expression in the ASPATH Regular Expression text box:
(1239 .* 7018 .*) | (1239 .* 3561 .*)
Select ANY from the Origin drop-down window; then click Apply. 5. Click Save to make your changes permanent.
BOOTP/DHCP Relay
BOOTP/DHCP Relay extends Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) operation across multiple hops in a routed network. In standard BOOTP, all interfaces on a LAN are loaded 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/DHCP Relay offers the following advantages over standard BOOTP/DHCP: You can provide redundancy by configuring an interface on the Nokia system to relay client configuration requests to multiple servers. With this setup, configuration requests are relayed to all the listed servers simultaneously. You can provide load balancing by configuring multiple interfaces on the Nokia system to relay client configuration requests to different servers. It allows you to centrally manage client configuration across multiple LANs. This is particularly useful in large enterprise environments. The IPSO implementation of BOOTP Relay is compliant with RFC 951, RFC 1542, and RFC 2131. BOOTP Relay supports Ethernet 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 configured for BOOTP Relay receives a boot request, it forwards the request to all the servers in its server list. It does this after waiting a specified 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 lowest numeric IP address specified for the interface.
Configuring BOOTP/DHCP Relay

You can use Network Voyager to enable BOOTP/DHCP Relay on each interface. If the interface is enabled for relay, you can set up a number of servers to which to forward BOOTP/DHCP requests. Enter a new IP address in the New Server text box for each server. To delete a server, turn it off. Table 11 describes the parameters that you can configure for BOOTP/DHCP relay.
198
BOOTP/DHCP Relay
Table 11 BOOTP/DHCP configuration parameters

Parameter Primary IP Description If you enter an IP address in the Primary IP text box, all BOOTP/DHCP requests received on the interface are stamped with this gateway address. This can be useful on interfaces with multiple IP addresses (aliases). Specifies the minimum number of seconds to wait for a local configuration server to answer the boot request before forwarding the request through the interface. This delay provides an opportunity for a local configuration 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 request is forwarded. If no local server is present, set the time to zero (0). Enables forwarding of BOOTP/DHCP requests to a configuration server. You can configure relay to multiple configuration servers independently on each interface. Configuring different servers on different interfaces provides load balancing, while configuring multiple servers on a single interface provides redundancy. The Server IP Address cannot be an address belonging to the local machine.
Wait Time
New Server
To enable BOOTP/DHCP relay on an Interface 1. Click BOOTP/DHCP Relay under Configuration > Router Services in the tree view. 2. Select On for the interface on which you want to enable BOOTP/DHCP. 3. Click Apply. Additional fields appear. 4. (Optional) Enter values for one or more of the following parameters, described in Table 11, above. Primary IPEnter the IP address to use as the BOOTP/DHCP router address. Wait TimeEnter the minimum client-elapsed time (in seconds) before forwarding a BOOTP/DHCP request. New ServerEnter the IP address of the BOOTP/DHCP configuration server to which to relay BOOTP/DHCP requests. 5. Click Apply. 6. Repeat to relay BOOTP/DHCP requests to more than one server. 7. Click Save to make your changes permanent. To disable BOOTP/DHCP relay on an interface 1. Click BOOTP/DHCP Relay under Configuration > Router Services in the tree view. 2. Select Off for the interface on which you want to disable BOOTP/DHCP. 3. Click Apply to disable the interface.
199
When you click Off, then Apply, the BOOTP/DHCP 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.
200
10
Configuring Security and Access
Role-Based Administration
When you add a new user, you must assign roles to the user to provide access privileges. Role-based administration (RBA) allows IPSO administrators to create and use separate roles. With RBA, an administrator can allow users to access specific features by including the features in a role and assigning the role to users. Each role can include 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 feature also provides improved auditing capabilities. To assign a set of access permissions to a user, create a role that specifies levels of access to features you want to include, then assign this role to the relevant user. You can also specify which access mechanisms (Network Voyager or the CLI) are available to the user when you assign a role to the user.
Managing Roles
To 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: adminRoleGives the user read/write access to every feature on the system. monitorRoleGives the user read-only access to every feature on the system.
Note When you assign a role containing access to a feature to a user, the user gets access to the configuration pages for that feature but not to the monitor pages for that feature. To provide access to the monitor pages, you must include the monitor privilege for that feature in the role definition.
To add or edit a role 1. Select one of the following: To add a role, click Add Role under Configuration > Security and Access > Role Based Administration in the tree view.
201
10
To edit a role, click Manage Roles under Configuration > Security and Access > Role Based Administration in the tree view, then click the name of the role.
Caution Because a user with read/write permission to the Users feature can change the password of any user, including the admin user, you should be cautious in assigning roles that contain this permission.
2. If applicable, select a role type from the Role Type drop-down list. You might see only one selection, System, meaning that this role will apply to this machine only. 3. If you are adding a role, enter a name in the Role Name text box. The role name can be any combination of letters and numbers, but it must start with a letter. You cannot edit the name of an existing role. 4. Add features by moving them to the RW (Read/Write) or RO (Read Only) columns, depending on the permission level you want to give to this role. Remove the features by moving them back to the Available 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 cannot use Cluster Voyager or the CLI.
5. Click Apply. 6. Click Save to make your changes permanent. To 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 the role. 3. Click Apply. 4. Click Save to make your changes permanent.
Note You cannot delete the adminRole, clusterAdminRole, or monitorRole default roles.
202
Authentication, Authorization, and Accounting (AAA)
Assigning Roles and Access Mechanisms to Users

To give a user permissions for various features, assign the role or roles that contain the feature permissions to the user. You can also specify whether a user can use Nokia Network Voyager and the CLI by assigning access mechanisms to the user from the Assign Roles to User page. When you create a role, you associate a role type. The role types are: SystemA system role assigned to a user provides the user with access to the associated features on this machine only. ClusterA cluster role assigned to a user provides the user with access to the associated features on every node in the cluster. To assign roles and access mechanisms to users 1. Click Assign Role to Users under Configuration > Security and Access > Role Based Administration in the tree view. 2. Click the name of the user to which you want to assign roles. The Assign Roles to User page appears. 3. Assign roles to a 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 You cannot change the roles assigned to the Admin, Cluster Admin, or Monitor users.
4. If you assign a cluster role to a user, you must also assign them the domain value that matches the appropriate cluster ID. 5. Click Apply. 6. Click Save to make your changes permanent.

The AAA component of the system manages user access to the appliance. Generally, AAA includes Authentication (identifying a user), Authorization (determining what a user is permitted to do), and Accounting (tracking some aspects of a user's activity).
Nokia IPSO implements Pluggable Authentication Modules (PAM), an industry-standard framework for authenticating and authorizing users. Using PAM, authentication, account management, and session management algorithms are contained in shared modules that you configure on your appliance.
Note Generally, AAA uses the terms authentication, authorization, and accounting while PAM uses related, but not quite identical, terms authentication, account management, and
203
10
session management. In particular, note that accounting is not the same as account management.
Configuring AAA Service Modules

To configure a new AAA service on your appliance, you configure a service module that is then shared by applications which need to invoke authentication, account management, or session management algorithms. When you create or modify a service module profile, you specify the service profile it will use. Each service profile is composed of the authentication profiles, account management profiles, and session profiles that it uses. For each type of profile (authentication, account management, and session), you can specify multiple service profiles using stacking. Names of service modules and profiles can be composed of alphanumeric and underbar (_) characters.
Note Nokia strongly recommends that you adopt a naming convention.
The following service modules are included by default and cannot be deleted: httpd login other snmpd sshd However, you can modify any of these service modules by modifying the service profiles it uses, or by modifying the authentication, account management, or session profiles that are likewise used by a service profile. You cannot delete services or profiles if they are referenced by other definitions. For example, if the service my_service uses the profile my_profile, you cannot delete my_profile until you delete my_service. You can delete both a service and any or all of its profiles at the same time. To configure a service module 1. Click AAA under Configuration > Security and Access in the tree view. 2. You can use an existing session profile, modify an existing session profile, or create a new one. The session profile contains information about how to assign IP addresses to sessions. a. If you are creating a new session profile, scroll down to the Session Profile table and enter a name profile in the New Sess. Profile text box. The name must not match the name of any existing session profiles. b. Select the profile type from the drop-down list for the new session profile, or for an existing session profile.
204
Select from the following types: PERMITDoes nothing, always returns success. (pam_permit.so.1.0 module) UNIXLogs a message to indicate that a session has started or stopped. Checks whether the password is still valid. (pam_unix_sess.so.1.0 module)
Note These modules reside in the /usr/lib directory.
c. Select a value from the Control drop-down list. For information on control types, see Table 12 on page 207. d. Click Apply. 3. You can use or modify existing account management or authentication profiles or create new ones: a. Scroll to the Account Management Profile Configuration section or the Authentication Profile Section. b. Modify the existing profile by using the associated drop-down lists, or, if you are creating a new profile, enter a name in the New Profile text box that does not match any existing profile names. c. Select the profile type from the drop-down list. For Account Management profiles, the choices are PERMIT and UNIX, described in step 2, above. For Authentication profiles, the choices are described in Table 13 on page 208. d. Select control type from the drop-down list. For information on the control types, see Table 12 on page 207. e. Click Apply. 4. You can use or modify an existing service profile or define a new one. Service profiles describe the characteristics of the PAM service module, by referencing specific Authentication, Accounting and Session profiles. a. Scroll to the Service Profile Configuration Section. b. If you are creating a new service profile, enter a name in the Service Profile text box that does not match any existing service profile names. If you are modifying an existing service profile, enter the name of the profile you want to modify. c. Enter names of existing authorization, account, and session profiles which you want this service profile to use. Leave any of these text boxes blank if the service requirements do not include them. You can include multiple services of any type (authentication, account management, or session).
205
10
Note Profiles are invoked in the order that they appear in the relevant list (top to bottom). When you add profiles, they are added to the end of the list. To change the order, delete the profiles that are out of order and add them back in the desired order.
d. Click Apply. 5. Modify an existing service module: a. Enter the name of the service profile that you want the service module to reference in the Profile text box. b. Click Apply. 6. Click Save to make your changes permanent.
Note If multiple authentication servers are configured for the same user, the roles for the user should be identical on all the servers. If the roles are different, the role assigned in the last server (the one lowest in the list) will be used.
To delete a service module or service profile 1. Click the Delete check box for the module or profile you want to delete. 2. Click Apply. 3. Click Save to make your changes permanent.
Note You cannot delete a profile that is used by a service module or another profile. You also cannot delete any of the default service modules or profiles.
To remove a profile from a service profile To remove a profile (authentication, accounting, or session) from a service profile, perform this procedure: 1. Select the authentication, accounting, or session profile in the appropriate service profile. 2. Click the Delete check box for the service profile. 3. Click Apply. 4. Click Save to make your changes permanent.
206
Note The authentication and accounting profiles that begin with tally and nonuse are used by certain Password and Account Management features and are required for the features to work.
Table 12 describes the profile control types used to determine how the results of multiple authentication, accounting, or session algorithms are handled and when multiple items are defined in the auth. profile, acct. profile or session profile lists for a given Service Profile, a feature known as stacking. (You specify lists of algorithms by defining multiple entries under the Auth. Profile, Acct. Profile, and Session Profile columns of a Service Profile). Values other than required are effective only when the service requires more than one profile.
Table 12 Profile Control Types
Type Required Description The result is retained and the next algorithm is invoked. If the algorithm is at the end of the list, the result is combined with the results of previous algorithms such that any failure result causes failure to be reported. A result of failure is reported immediately and no further algorithms are invoked. If the algorithm is at the end of the list, the result is reported immediately. 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 algorithm is discarded. If a previous algorithm has reported failure or the result of this algorithm is failure, the next algorithm is invoked. If the algorithm is at the end of the list, the result is reported immediately. A result of failure is ignored and a result of success is retained. The next algorithm is always invoked. If the algorithm is at the end of the list, a result of success is reported. Used in Auth. Profiles only. It is the same as sufficient, except that a result of 'authentication error' for this algorithm is reported immediately and no further algorithms are invoked. This type is intended for use with algorithms that access remote servers and where the modules have different result codes for 'authentication error' and 'server not reachable'.
Requisite
Sufficient
Optional
nokia-serverauth-sufficient
207
10
Table 13 describes the authentication algorithms that are available in the drop-down list when you create a new authentication profile.
Table 13 Authentication Profile Types
Type HTTP Description Logs a message to indicate that a session has started or stopped. Authenticates the user and verifies the user name and password. Module: pam_httpd_auth.so.1.0 Does not do any authentication. Is considered to succeed when invoked. Module: pam_permit.so.1.0 A client/server authentication system which offloads authentication processing and some other management functions from the IPSO system to a RADIUS server. Defined in RFC2865. Requires additional configuration, as described in Configuring RADIUS on page 209." Module: pam_radius_auth.so.1 Performs one task: if the user ID is 0, it returns success. It can be used to allow password-free access to some services for root. Caution: This module can bypass password checking, which in some cases might be undesirable. Module: pam_rootok_auth.so.1.0 Allows root logins only if the user is logging in on a secure TTY. Module: pam_securetty_auth.so.1 Implements the S/Key algorithm. The user provides the one-time pass phrase, which is used to authenticate the user by using the password database. Module: pam_skey_auth.so.1.0 Authenticates the SNMP packets from a user (Management Station). When an SNMP user is added in the system through Network Voyager, 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 agent local store by this module. This information is then used to authenticate the packets. Module: pam_snmpd_auth.so.1.0 A client/server authentication system, which offloads authentication processing and some other management functions from the IPSO system to a RADIUS server. Requires additional configuration, as described in Configuring TACACS+ on page 212. Module: pam_tacplus_auth.so.1.0 Maintains a count of attempted accesses and resets count on success. Module: pam_tally_auth.so.1.0 Uses the local password database to authenticate the user. When the user enters user name and password, this module is called to authenticate the user. Module: pam_unix_auth.so.1.0
PERMIT
RADIUS
ROOTOK
SECURETTY
SKEY
SNMPD
TACPLUS
TALLY
UNIX
208
Note Modules are located in the /usr/lib directory.
Configuring RADIUS
RADIUS (Remote Authentication Dial-In User Service) is a client/server authentication software system that supports remote-access applications. This service allows an organization to maintain user profiles in a centralized database that resides on an authentication server. A host contacts a RADIUS server, which determines who has access to that service. IPSO will accept users configured on a RADIUS server even if there is no corresponding local account on the Nokia system (assuming that you configure the RADIUS server and IPSO appropriately). See Configuring Nonlocal RADIUS Users on page 211 for more information. You can configure RADIUS as an AAA module so that your appliance functions as a RADIUS client. Nokia systems do not include RADIUS server functionality. You can configure your appliance to contact more than one RADIUS server. If the first server in the list is unreachable, the next RADIUS server in the priority ranking is contacted to provide the functionality. You can remove a server at any time by checking the Delete check box next to the row for the server you want to remove. In the following procedure, these names are used for purposes of example: Auth Profile is called RADIUS_http_authprofile. Service profile is called RADIUS_prof_httpd. Username is nokiaadmin. To configure RADIUS client on your appliance 1. Click AAA under Configuration > Security and Access in the tree view. 2. Create an authorization profile called RADIUS_httpd_authprofile: a. Scroll to the Auth. Profile section. b. Enter RADIUS_httpd_authprofile in the New Auth. Profile text box. c. Click the Type drop-down list and select RADIUS. d. Select a control type from the drop-down list. For descriptions of profile control types, see Table 12 on page 207. e. Click Apply and click Save to make your changes permanent. The name of the RADIUS authentication profile appears in the Auth. Profile table. A link labeled Servers also appears in the same row. 3. Specify the RADIUS servers this client will use: a. Scroll to the Service Profile section and click the Servers link for the profile you just created. The AAA RADIUS Authorization Servers Configuration page appears.
209
10
b. Enter values in the following fields: PriorityEnter a unique integer to indicate the priority of the server in the Priority text box. There is no default. You must enter a value in the Priority text box. You can configure multiple servers for a profile, and the priority value determines which server to try first. A smaller number indicates a higher priority. Host addressEnter the IP address of your RADIUS server. RADIUS supports only IPv4 addresses. Port numberEnter the port number of the UDP port to contact on the server host. The default is 1812, which is specified by the RADIUS standard. The range is 1 to 65535.
Caution Firewall software often blocks traffic on port 1812. To ensure that RADIUS packets are not dropped, make sure that any firewalls between the RADIUS server and IPSO devices are configured to allow traffic on UDP port 1812.
SecretEnter the shared secret used to authenticate the authorization profile between the RADIUS server and the local client. Enter a text string without a backslash. You must also configure this same value on your RADIUS server. For more information see RFC 2865. 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. Timeout (optional)Enter the number of seconds the system waits for a response after contacting the server. The default value is 3. Depending on your client configuration, if the client does not receive a response, it retries the same server or attempts to contact another server. Max Tries (optional)Enter the maximum number attempts to contact the server. The default is 3. If all of the attempts do not make a reliable connection within the timeout period, the client stops trying to contact the RADIUS server.
Note The maximum tries value includes the first attempt. For example, a value of 3 means the client makes two additional attempts to contact the RADIUS server after the first attempt.
c. Click Apply. d. Click Save to make your changes permanent. e. To configure additional RADIUS authentication profiles, repeat this procedure to configure additional RADIUS authentication profiles. You must configure a RADIUS authentication server for each profile even if you associate the new profile with a server that you previously configured for an existing RADIUS authentication profile.
210
4. Create a service profile: a. Scroll to the Service Profile section. b. Enter the following values in the appropriate text boxes: Service profileEnter RADIUS_prof_httpd. This is the name of the authorization profile you created in step 2. Acct. ProfileEnter base_httpd_acctprofile. Session ProfileEnter base_httpd_sessprofile. c. Click Apply, then click Save to make your changes permanent. 5. Associate the service module httpd with the RADIUS_prof_httpd profile. 6. Click Users under Configuration > Security and Access, and create a user called nokiaadmin with UID=0 and home directory of /var/emhome/nokiaadmin. This user is shown for purposes of example; you can also use any other locally-configured user. 7. Configure the nokiaadmin user and password on your RADIUS server. 8. Test Network Voyager access by using the RADIUS login ID nokiaadmin.
Configuring Nonlocal RADIUS Users

To allow access by nonlocal users (users defined on a RADIUS server but not defined on the Nokia system), you must configure the RADIUS server and Nokia system appropriately. To configure a RADIUS server for nonlocal IPSO users 1. Copy the file nokiaipso.dct (for Steel-Belted RADIUS servers) or dictionary.nokia (for free RADIUS servers) to your RADIUS server. These files are in /etc on the Nokia system. 2. Define the user roles by adding the following Nokia vendor-specific attribute (VSA) for the appropriate users in your RADIUS user configuration file:
Nokia-IPSO-User-Role = "role1[:domain1;domain2;..],role2[:domain1:
For example:
Nokia-IPSO-User-Role = "foorole, barrole" Nokia-IPSO-User-Role = "foorole:foodomain, barrole" Nokia-IPSO-User-Role = "foorole:foodomain;bardomain, barrole:foodomain;bardomain" Note Make sure the role names match existing roles in the IPSO system.
3. Specify whether the Nokia users should have superuser access to the IPSO shell by adding the following VSA:
Nokia-IPSO-SuperUser-Access = <0|1>
211
10
in which 0 provides nonsuperuser access 1 provides superuser access To configure a Nokia system for nonlocal users 1. On your Nokia system, create the roles that are to be assigned to the nonlocal users. 2. Create an authentication profile of type RADIUS and set the control level to sufficient. 3. Add the new authentication profile to each appropriate service profile. 4. Make the RADIUS authentication profile the first authentication mechanism for each appropriate service by deleting the other authentication profiles for each service and then adding them back again. The other profiles are then added after the RADIUS authentication profile. See step 4 on page 205 for information about adding an authentication profile to a service. See To remove a profile from a service profile on page 206 for more information about deleting an authentication profile from a service. 5. For critical users, you should configure the Nokia system to allow access even if the RADIUS server is unavailable: a. Create local accounts for these users. b. If necessary, add a local authentication profile after the RADIUS profile for all the service profiles. To log in as a superuser If the Nokia Superuser VSA is set to 1 for a nonlocal user, they can log into the IPSO shell with superuser privileges if they perform the following procedure: 1. Log into the system using command line. 2. The default shell is the IPSO CLI., enter
shell -
3. To access the IPSO shell, enter

sudo /usr/bin/su -
The user now has superuser privileges
Configuring TACACS+
The TACACS+ (Terminal Access Controller Access Control System) authentication protocol allows a remote server that is not part of IPSO to authenticate users on behalf of the IPSO system. IPSO will accept users configured on a TACACS+ server even if there is no corresponding local account on the Nokia system (assuming that you configure the TACACS+ server and IPSO appropriately). See Configuring Nonlocal TACACS+ Users on page 214 for more information.
212
All data sent to the TACACS+ server are encrypted. IPSO supports TACACS+ for authentication only, and not for accounting. Challenge-response authentication, such as S/Key, over TACACS+ is not supported. You can configure TACACS+ support separately for various services. The Network Voyager service is one of those for which TACACS+ is supported and is configured as the httpd service. When TACACS+ is configured for use with a service, IPSO contacts the TACACS+ server each time it needs to check a user password. If the server fails or is unreachable, the password is not recognized and the user is not allowed access. Before you change the Network Voyager configuration, confirm any new configuration. To configure TACACS+ servers for a single authentication profile 1. Click AAA under Configuration > Security and Access in the tree view. 2. Create a TACACS+ authorization profile: a. Scroll to the Auth. Profile Section. b. Enter a name in the New Profile text box which does not match any existing profile names. c. From the profile type drop-down list, select TACPLUS. See Table 13 on page 208 for descriptions of the profile types. d. Select a control type from the drop-down list. For descriptions of control types, see Table 12 on page 207. e. Click Apply, and then click Save to make your changes permanent. The name of the TACACS+ authentication profile appears in the Auth. Profile table. A link labeled Servers also appears in the new row. 3. Configure one or more TACACS+ servers for the authentication profile you created: a. In the Auth. Profile table, click the Servers link in the row for the TACACS+ authorization profile you configured in step 2. The AAA TACACS+ Authorization Servers Configuration page appears. b. Enter values in the following text boxes: PriorityEnter a unique integer to indicate the priority of the server in the Priority text box. There is no default. You must enter a value in the Priority text box. You can configure multiple servers for a profile, and the priority value determines which server to try first. A smaller number indicates a higher priority. Host addressEnter the IP address of the TACACS+ Server. TACACS+ supports only IPv4 addresses. Port numberEnter the port number of the TCP port to contact on the server host. The default is 49, which is specified by the TACACS+ standard. The range is 1 to 65535. SecretEnter the shared secret used to authenticate the authorization profile between the TACACS+ server and the local client. You must also configure this same value on your TACACS+ server. Enter a text string without a backslash.
213
10
Timeout (optional)Enter the number of seconds to wait for a response after contacting the server. Depending on your client configuration, if the client does not receive a response, it retries the same server or attempts to contact another server. The default value is 3. c. Click Apply, and then click Save to make your changes permanent. 4. Repeat step 2 to configure additional TACACS+ authentication profiles. You must configure a TACACS+ authentication server for each profile even if you associate the new profile with a server that you previously configured for an existing TACACS+ authentication profile. 5. Repeat step 3 of this procedure to configure additional AAA TACACS+ authentication servers for existing TACACS authentication profiles. 6. Associate the service module httpd with the name of the TACACS+ authorization profile that you created in step 2.
Configuring Nonlocal TACACS+ Users

To allow access by nonlocal users (users defined on a TACACS+ server but not defined on the Nokia system), you must configure the TACACS+ server and Nokia system appropriately. To configure a TACACS+ server for nonlocal IPSO users 1. Define the following IPSO-specific service in your TACACS+ server:
service = nokia-ipso { Nokia-IPSO-User-Role = "role_name_on_IPSO" Nokia-IPSO-SuperUser-Access = <0|1> } Note Make sure the role name matches an existing role in the IPSO system.
In
Nokia-IPSO-SuperUser-Access = <0|1>
0 provides nonsuperuser access 1 provides superuser access 2. Configure the appropriate user accounts in the TACACS+ server. The following is an example:
#key = password group = ipso-admin { service = nokia-ipso { Nokia-IPSO-User-Role = "adminRole" Nokia-IPSO-SuperUser-Access = 1 } }
214
#IPSO admin users user = admin { member = ipso-admin login = cleartext changeme } user = Landon { member = ipso-admin login = cleartext changeme } #Cluster administrator role for cluster ID 100 group = cluster-admin { service = nokia-ipso { Nokia-IPSO-User-Role = "ClusterRole:100" Nokia-IPSO-SuperUser-Access = 1 } } #Cluster administrator users user = cadmin { member = cluster-admin login = cleartext changeme } user = Mia{ member = cluster-admin login = cleartext changeme }
To configure a Nokia system for nonlocal users 1. On your Nokia system, create the roles that are to be assigned to the nonlocal users. 2. Create an authentication profile of type TACACS+ and set the control level to sufficient. 3. Add the new authentication profile to each appropriate service profile. 4. Make the TACACS+ authentication profile the first authentication mechanism for each appropriate service by deleting the other authentication profiles for each service and then adding them back again. The other profiles are then added after the TACACS+ authentication profile. See step 4 on page 205 for information about adding an authentication profile to a service. See To remove a profile from a service profile on page 206 for more information about deleting an authentication profile from a service.
215
10
5. For critical users, you should configure the Nokia system to allow access even if the TACACS+ server is unavailable: a. Create local accounts for these users. b. If necessary, add a local authentication profile after the TACACS+ profile for all the service profiles. To log in as a superuser If TACACS+ allows a nonlocal user superuser access, the user must also perform the following procedure to obtain superuser privileges in the IPSO shell: 1. Log into the system using command line. The default shell is the IPSO CLI. 2. Enter
shell
to access the IPSO shell. 3. Enter

sudo /usr/bin/su -
The user now has superuser privileges.
216
11
Policy-Based Routing
Policy-based routing (or Advanced Routing in Check Point terminology) allows classification of traffic beyond regular destination-based routing policies. Policy-based routing entries provide an extended set of selectors to classify traffic: Ingress interface Source network Destination network The following graphic shows a configuration where Policy Based Routing is required:
vsx1
VS1
IVR MVS
EVR
VS2
In this configuration, single or multiple interfaces can be used to connect multiple customer networks without VLANs. Network traffic is routed by the internal virtual router (IVR) to the appropriate customer virtual system according to the destination IP address. Additionally, the IVR can forward traffic to VS1 or VS2 based on IP source and destination as well as incoming interface information. For this example, an entry is configured on an IVR. Policy-based routes are configured through Nokia Network Voyager.
Note Policy-based routing is not supported on the IP2250 or IP2255.
217
11
Note When you add routes for Policy Based Routing, use either the Nokia Network Voyager GUI or the Check Point GUI for all configuration changes, not both. If you configure routes with both GUIs, the Nokia Network Voyager routes may be deleted after reboot.
1. Access the specific instance, in this case IVR:
2. Follow the link to Policy-Routes
3. Define the specific parameters required:
Define the source network including the mask length. By default it is 0.0.0.0/0. Define the destination network including the mask length. By default it is 0.0.0.0/0. At least a source or destination must be defined.
218
If the ingress interface is relevant to the entry, select it from the pull-down list. Otherwise, use the default: Any. The next hop can be the address or the logical point-to-point interface between virtual system instances. Several next hops can be defined with different priorities.
Note For a route between a VS and a VR (IVR or EVR), you must specify the next hop type to be logical and then select the wrp link between the VS and VR.
For multiple next hops, each one must have a unique priority value. The next hop with a smaller priority value, and which is reachable or active, is selected. In the case of next-hop IP address, if the IP is not directly reachable, next hop is considered unreachable. In the case of next-hop interface, if the interface is turned off or an IP address is not configured on it, it is considered to be inactive. If none of the next hops are reachable or active, all of the packets that match the policy route are rejected. Regular static route is not applied.
Note Policy-based route entries take precedence over regular routing entries.
Note In virtual routing instances, a change of priority is reflected only for new connections if SecureXL acceleration is enabled.
A limited version of policy-based routing configuration is available through the Check Point GUI. If you choose to use Check Point configuration, be aware of the following limitations: Ingress interface information cannot be defined. Multiple next-hop entries for the same subnet are not supported. Only logical interfaces are supported as next hop, not IP addresses. Policy-based routes can only be defined for virtual router instances. Policy-based routes cannot be modified once created and applied to the gateway.
219
11
220
12
Configuring Automatic Backup and Restore
Automatic Backup and Restore gives you the ability to create backups of your VSX VRRP pair so that you can rebuild the gateway pair quickly after the loss of either member. You can also enable automatic backup using vsx_config. See Using the VSX Configuration Utility. Complete the configuration of Automatic Backup in the following order: 1. Create SSH certificates for both VRRP pairs. See Creating SSH Certificates for Automatic Backup 2. Configure Automatic Backup.See Enabling and Configuring Automatic Backup
Enabling and Configuring Automatic Backup

1. In Nokia Network Voyager, navigate to the configuration page. 2. Click Auto Backup (Between VRRP nodes). 3. Click the Yes radio button. 4. In the Auto Backup Transfer Method drop-down list, select how the backup file will be transferred. See Table 11 for information on the transfer methods. 5. Enter the VRRP peer IP address that will be used to transfer the backup to the remote node in the text box. 6. In the Backup Time of the day drop-down lists, select the hour and minutes to begin the backup process. It is best to select a time when the system is not busy. 7. Click Apply. 8. Click Save to make your changes permanent Table 14describes the auto back transfer methods:
221
12
Table 14 Transfer Methods

Method Nokia Proprietary Description Invokes the client which will transfer the backup to the remote VRRP pair. This method does not require user ID and password. You must specify a firewall rule that allows the VRRP pair to connect on port 44332. For more information on how to configure firewall rules, see your Check Point documentation. Transfers the backup files to the remote VRRP pair using SSH. You must exchange certificates for the VRRP pair before you enable auto backup. For more information on how to configure SSH, see your Nokia Network Voyager documentation.
SSH Certificate
Creating SSH Certificates for Automatic Backup

The following procedure enables automatic backup to work without the necessity to exchange passwords. 1. Click Configuration in the tree view. 2. Click SSH (Secure Shell). 3. Click Allow access using public key authentication. 4. Click Goto the key pairs page link. 5. Click View/Create Identity Keys for User, when <user> is the user for which you are trying to generate the identity file. By default only admin and monitor users are present on the box. 6. Select RSA v2 or DSA identity for the user. 7. Select the key size.
Note Do not select the password option. This would require you to manually input a pass word and that would break the automatic backup and restore functionality.
8. Click Apply. This will generate the public keys. 9. Follow steps 1 through 8 for VRRP 2. 10. Navigate to Home page. 11. Click SSH (Secure Shell). 12. Click Goto the authorized keys page link.
222
Restoring System Configuration
13. In VRRP 1, copy the public key generated in Step 8 and paste it into the authorized keys page of VRRP 2. While performing the above actions, be aware of the following: Paste the DSA public key in the DSA section only. Paste the RSA v2 key in the RSA v2 section only. The keys are displayed in two different formats (OpenSSH and SSH2). Make sure you are pasting them in the correct sections. 14. Click Apply. 15. Click Save to make your changes permanent. 16. Follow Steps 10 through 15 for VRRP 2. 17. To check that the key exchange is working, do the following: From the command line type: ssh <user>@<host> <vrrp-host> If the key exchange is successful, you will not be prompted for a password. If you are prompted for a password, you must reconfigure the SSH certificates.
Restoring System Configuration

On the failed pair of a VRRP pair, do the following: 1. Install IPSO 5.0 or above, and during system configuration choose to restore from the autobackup. 2. Reboot the system. Or 1. Install IPSO 5.0, complete the configuration. 2. Reboot the system. 3. From a console connection, type newsystem -f and choose Restore from the backup when prompted.
223
12
224
Helpful Commands and Tips
This appendix describes Commands that you might find useful How to use Nokia Network Voyager to back up and restore the Nokia Virtual Firewall for Check Point VSX gateway Configuration and troubleshooting tips For information about known limitations and workarounds, see the Release Notes for Nokia Virtual Firewall for Check Point VSX NGX R65.
Entering Commands from the Nokia Virtual Firewall for Check Point VSX Gateway
You can enter the commands in this section from the command prompt on the VSX gateway. To ping the interfaces on a virtual system (VS), use the following command:
# ping -z vs<number> <destination IP>
For example:
ping -z vs1 10.10.10.1
If you do not know the VS number, use the fw vsx stat -v command to display information about the VSs configured on your gateway. To view the flow table configured on the gateway, use the following command:
# netstat -F
To erase the existing Nokia IPSO configuration without removing the Check Point modules, use the following command:
newsystem -r
After you enter newsystem -r, reboot the system with the following command:
reboot
Reactivate the Check Point packages after the reboot by using Nokia Network Voyager or the CLI.
225
Virtual System Commands

Use the commands in this section to obtain information and configure virtual systems. You can view or configure only one virtual system instance at a time. To view information about the current virtual system, enter the following command:
vsx get
To set the environment to a new virtual system, enter the following command:
vsx set -vs <vs number>
To get a policy file from the $FWDIR\conf directory and replace the current running policy with it, use the following command:
fw fetch -f Note You need to be in the appropriate VS instance.
Firewall Commands
Use the following commands to find out information about the VSX gateway and virtual systems:
fw vsx stat -v
Displays status information for the VSX gateway

fw -vs <vsid> getifs
Displays the interface list for the given VS.

fw monitor -vs <vsid> -e "ip-p=1,accept" fw monitor -vs <vsid>
Display packets that pass through the given VS. For more information about these commands and other firewall commands, see Command Line Reference section of the Check Point VPN-1 Power VSX NGX R65 guide.
SecureXL Commands:
Use the following commands to view or configure SecureXL:
fwaccel -vs <vsid> stat
Backup and Restore

You can use Nokia Network Voyager to back up and restore the Nokia Virtual Firewall for Check Point VSX gateway configuration and other critical files.
226
Backup and Restore
By default, the backup contains all of the configuration (/config), cron (/var/cron), etc (/var/etc), and IPSec files (/var/etc/IPSec). Export versions of Nokia IPSO do not include IPSec files. You can choose to back up the home directories, which are stored in the /var/admin and /var/monitor directories and the log files, which are stored in the /var/logs directory. You can also choose to back up the Check Point VPN-1 Power VSX NGX R65 package. To perform a restore: The gateway must have the same versions of the Check Point packages and Nokia IPSO that are in the backup file. The configuration for the gateway in the management server must be intact and unchanged. To create a backup file manually 1. Click Virtual Systems tab. 2. Click Configuration for the Default instance. 3. Click the Configuration Backup and Restore link in the System Configuration section. 4. In the Manual Backup section, enter a file name in the Backup File Name text box.
Note If you do not enter a name, the backup file is not created.
5. Select whether you want to back up the admin and monitor home directories and the log file directory. 6. Select the Check Point VPN-1 Power (fw) package for back up. 7. Click Apply. 8. Wait for the backup to complete. (The browser status line will report that the page is done.) 9. Click Save to save your backup configuration choices. The backup file is in /var/backup. You can upload this file to any FTP server. You can also schedule regular backups. For more information, see the Nokia Network Voyager Reference Manual. To restore backup file from a remote server
Warning Restoring from a backup file overwrites your existing files.
227
Warning Make sure that you have enough disk space available on your Nokia appliance before restoring files. If you try to restore files and you do not have enough disk space, you risk damaging the operating system.
1. Perform a fresh installation of the IPSO image and Check Point packages. Do not configure anything. See Performing a Fresh Installation on page 45 for how to perform a fresh install.
Note The system must be running the same version of the operating system and the same packages as those of the backup file.
2. From the Nokia Network Voyager home page, click the System Configuration link and then the Backup and Restore link. 3. Find the Restore from Remote section on the page and enter the required FTP information. 4. Click Apply. 5. A list of available files in the directory you specify appears. Select the backup files you want to restore. 6. Click Apply. 7. Wait for the restore to complete, which may take some time. (The browser status line will report that the page is done.) 8. Do not click Save. Ignore any Unsaved changes will be lost messages. 9. Click the Reboot link at the bottom of the page and wait for the system to reboot.
Note You must reboot your system after restoring from backup files.
10. Verify that the previous configuration has been restored with the fw vsx stat -v command.
EVR Default Policy Behavior

The EVR does not inspect packets that are not destined for it. The EVR by default has an any-any drop policy. The EVR accepts packets based on the implied rules only, such as management SIC connections.VRs (and the EVR is a private case of a VR) enforce their security policy only on packets that are destined to themselves (dst_ip or src_ip is the IP of VR).
228
Removing Customers from Provider-1
Packets that are destined to other network entities, for example VSs, are passed as is to the IP stack and forwarded uninspected. With SecureXL the packets after the first are wrp-jumps or cut-through over the VR directly to the VS. The inspection and policy enforcement is done on the VSs for the forwarded packets, assuming they are forwarded to a VS and no internal network is directly connected to the EVR.
Removing Customers from Provider-1

Do not use the mdsremove_customer script. To remove a customer, use mdscmd deletecustomer or mdscmd deletecma as specified in the Provider-1 Users Guide
Client Authentication Is Not Supported

VSX does not support client, session, or user authentication.
Configuring an Extreme Switch

To configure an Extreme switch to work with Nokia Virtual Firewall for Check Point VSX gateway, use the following tips: Create a VLAN with protocol IP and specify the 802.1Q Tag (1 - 4095): for example, 10. Specify the tagged ports (connected to IP1260 security platforms) and untagged ports (normally connected to a host) to this VLAN. Add all the ports in to the default VLAN (VLAN 1). Default VLANs normally match all protocols.
Re-establishing Trust on Provider-1

To reset the SIC and enter the new SIC that you set in cpconfig, launch SmartDashboard, double-click VSX gateway, and click the communication button. Once you establish trust and reload the VSX gateway from Provider-1, the SIC does not retrieve the default policy. You must push the default policy from the MDS server. Use the following command to push the default policy:
mdsenv <cma name> fwm load policy_name (MDS_Default.W) target name (name of VSX gateway displayed with vsx stat -v)
For example:
fwm load MDS_Default.W HILO_VSX gateway
This procedure does not work for EVRs and VSs. If you need to re-establish trust, you must delete and recreate the EVRs and VSs. Note that the MDS_Default.W file is in /opt/CPfw1-V26/ conf directory: either change directories (cd) into that directory and run the fwm load command, or specify the path in the command.
229
Also, after you establish trust with the SIC, instead of pushing the default policy, you can push an ANY, ANY, ANY Accept policy and reload the VSX gateway.
Note For backup and restore options, please see the Check Point documentation.
230

VSX5000-InstlGuide N450000590r001

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VSX5000-InstlGuide N450000590r001

Uploaded by

Copyright:

Available Formats

Nokia Virtual Firewall for Check Point VSX NGX R65 Installation and Configuration Guide

Part Number N450000590 Rev 001 Published June 2008

About This Guide

Conventions This Guide Uses

Log error 12453 bold monospace font

The words enter and type

Preparing the Network

Obtaining Check Point Licensing

Obtaining Check Point Licensing

Configuring Virtual Switches

Note Virtual switches do not support ADP acceleration.

Configuring Virtual Switches

Creating a Virtual Switch Group

Creating Virtual Ethernet Interfaces

Creating Virtual Ethernet Interfaces

Adding Virtual Ethernet Interfaces to a Virtual Switch

Deleting a Virtual Switch Group

Configuring Virtual Switches

Deleting Virtual Ethernet Interfaces

Planning a VRRP HA Environment

Planning a VRRP HA Environment

Hardware Platform Planning

Firewall Synchronization Interface

Topology and IP Planning

Examples of Supported VSX Cluster Configurations

Examples of Supported VSX Cluster Configurations

Example 1: DMI and EVR Configuration

Planning a VRRP HA Environment

Figure 1 DMI and EVR Configuration

EVR VIP 10.50.50.75

172.16.1.50 Provider-1 MDS eth-s1p4

VS3 EXT VIP 10.10.30.75 eth4

Virtual Links Physical Links

Private Internal Network 10.88.88.0/24 00057

Table 2 summarizes the interfaces shown in Figure 1.

Examples of Supported VSX Cluster Configurations

Table 2 DMI and EVR Configuration

Example 2: DMI and VSW Configuration

Planning a VRRP HA Environment

Figure 2 DMI and VSW Configuration

172.16.1.50 Provider-1 MDS eth-s1p4

VS3 EXT VIP 10.10.30.75 eth4

Virtual Links Physical Links

Private Internal Network 10.88.88.0/24 00057

Table 2 summarizes the interfaces shown in Figure 1.

Examples of Supported VSX Cluster Configurations

Table 3 DMI and EVR Configuration

Example 3: DMI, EVR, and IVR Configuration

Planning a VRRP HA Environment

Figure 3 DMI, EVR, and IVR Configuration

VSX EVR VS2

eth-s1p2 IVR VIP 192.168.50.100

VS3 EXT VRRP IP 10.10.30.75 EVR VIP 10.50.50.75

VSX EVR VS2

VS3 EXT WRP IP 10.10.30.75

Virtual Links Physical Links

Private Internal Network 10.88.88.0/24 00063

Table 4 summarizes the interfaces shown in Figure 3.

Examples of Supported VSX Cluster Configurations

Table 4 DMI, EVR, and IVR Configuration

Example 4: DMI and No Virtual Router Configuration

Planning a VRRP HA Environment