Nokia Standard Document Template

IPSO BETA TESTING NES Will Jones

Apr 2004

OSPF Routing with IPSO 3.8 Clustering

1 (32)


2 (32)

Apr 2004

Table Of Contents 1. Introduction .........................................................................................................................................4 1.1 Equipment List..............................................................................................................................4 1.2 Software List.................................................................................................................................4 2. Topology .............................................................................................................................................5 Figure 1 Network Topology.........................................................................................................................5 2. IPSO Interface Information .....................................................................................................................6 Figure 2 Interface Configuration Screen .....................................................................................................6 2.1 ARP ..............................................................................................................................................7 Figure 3 ARP Entries ..................................................................................................................................7 Figure 4 Accepting Multicast ARP Replies .................................................................................................7 2.2 Cluster Configuration....................................................................................................................8 Figure 5 Clustering Setup ...........................................................................................................................8 Figure 6 Creating IPSO Cluster ..................................................................................................................8 Figure 7 Cluster Status (uninitialized) .........................................................................................................8 Figure 8 Disabling Firewall Monitoring ......................................................................................................10 Figure 9 Cluster Master ............................................................................................................................10 Figure 10 Cluster Member ........................................................................................................................11 2.3 Clusters and Switched Ethernet Networks .................................................................................12 Figure 11 Stuck In Joining State ...............................................................................................................12 Figure 12 Interrogating /var/log/messages ...............................................................................................13 Figure 13 Switch Configuration (VLANs) ..................................................................................................13 Figure 14 Router ARP Entries ..................................................................................................................14 Figure 15 Adding Static ARP to Router ....................................................................................................14 Figure 16 Router ARP Table after Static ARP addition ............................................................................14 Figure 17 Finding the ClusterMac Address...............................................................................................15 2.4 Monitoring the Cluster ................................................................................................................16 Figure 18 Accessing Cluster Voyager.......................................................................................................16 Figure 19 Cluster Voyager Initial Screen ..................................................................................................17 Figure 20 Cluster Monitor Status Page.....................................................................................................18 3. Configuring Ospf within a cluster ......................................................................................................19 Figure 21 OSPF Configuration within Cluster Menu .................................................................................19 Figure 22 Adding Interfaces to Areas .......................................................................................................20 Figure 23 Cisco OSPF Configuration........................................................................................................20 Figure 24 Obtaining OSPF Neighbour Information ...................................................................................21 Figure 25 Checking for “Hello” packets on Cisco Router ..........................................................................21 Figure 26 Setting Up a Trace File for OSPF Debugging on IPSO ............................................................22 Figure 27 Output of IPSRD.LOG Tracefile................................................................................................22 3.1 Understanding the OSPF Mesh..................................................................................................23 Figure 28 OSPF Mesh (Never a Full Mesh!).............................................................................................23 4. Configuring ospf within checkpoint NG AI R55 .................................................................................25 Figure 29 CPCONFIG from within IPSO ...................................................................................................25 Figure 30 Creating Gateways and Gateway Clusters ...............................................................................26 4.1 Gateway Cluster Object..............................................................................................................26 Figure 31 Popluating the Gateway Cluster ...............................................................................................26 Figure 32 Cluster Only Retains Certain Information of the Firewall Gateway...........................................27 Figure 33 Gateway Cluster HA .................................................................................................................27 Figure 34 Adding the SYNC Nets (Dynamic)............................................................................................28 Figure 35 Cluster Topology Information (Dynamic) ..................................................................................29 4.2 OSPF In the Rulebase................................................................................................................30 Figure 36 OSPF In the Rulebase..............................................................................................................30


3 (32)

Apr 2004

Figure 37 SmartMap Representation of Topology ....................................................................................30 Testing with ng ai running .........................................................................................................................31 Figure 38 Show OSPF neighbour (Before and After Firewall is turned on without OSPF rule) ................31 Figure 39 Valid OSPF Communication seen in the FW Log .....................................................................31 Figure 40 Full Failover Test ......................................................................................................................32


4 (32)

Apr 2004

1. INTRODUCTION This paper investigates the necessary requirements for configuring OSPF routing between an IPSO 3.8 Cluster and multiple Cisco Routers. The topology design is based on a Campus network where several departmental routers are connected to a switched Ethernet backbone. At the central office location, a pair of Nokia IP350 appliances configured as a cluster act as the Designated Router for the OSPF cloud, whilst also providing additional firewalling capabilities. The paper initially walks through the steps required to build an IPSO Cluster over a switched Ethernet, and then tackles the stages necessary to configure and deploy an OSPF backbone.

1.1 Equipment List The equipment list used for this design is as follows: o

2x Nokia IP350 Firewalls

o

2x Cisco 3500XL Switches

o

3x Cisco 2600 Routers

1.2 Software List The software versions used for this design is as follows: o

Nokia IPSO 3.8 Beta 26

o

Cisco IOS 12.2(8)T5 (Router IOS)

o

Cisco IOS 12.0(5.4)WC(1) (Switch IOS)


5 (32)

Apr 2004

2. TOPOLOGY The diagram below illustrates the Campus design used for this testing. The OSPF network comprises of 3x 2600 routers and 2x IP350 firewalls. In order for departmental connectivity, each router and the FW cluster (cluster) has been configured with an interface in Area 0 (campus backbone) whilst advertising its own internal network (area 1,2,3 and 4). Each network is confined to its own Layer 2 broadcast domain utilising 4 VLANs (10 = Outside, 20 = Inside, 30 = Primary Cluster, 40 = Secondary Cluster). Figure 1 Network Topology

10.10.10/24

Inside Net

11.11.11/24

Area 2 (Stub)

Inside Net

Inside Net 12.12.12/24

Area 3 (Stub) Cisco 2610

LINK

ETHERNET 0

RTA

Area 4 (Stub)

ACT

Cisco 2610 CONSOLE

AUX

LINK

ACT

ETHERNET 0

Cisco 2610 CONSOLE

AUX

RTC

172.16.16/24 Campus OSPF Area 0 (Ethernet)

.3

FW-A

.1

.2

Primary Cluster Network 192.168.250/29

Secondary Cluster Network 192.168.150/29

Inside Network 192.168.10/24 Area 1 (Stub)

LINK

ACT

ETHERNET 0

.20

RTB

.10

FW-B

.30

CONSOLE

AUX


6 (32)

Apr 2004

2. IPSO INTERFACE INFORMATION Figure 2 illustrates the Voyager Interface Configuration screen. As the two IP350 firewalls are to be clustered we must remember to designate two interfaces for Cluster Protocol and firewall state information to travel on. It is advisable to use discreet networks to carry this information as you would not want unnecessary protocol traffic to be carried on your data networks. In this design, eth3 and 4 are to be used for Primary and Secondary Cluster networks. When the firewall software is configured, the Secondary Cluster network will be the network that also carries the firewall sync traffic. It may well be beneficial to apply a Logical Name to the interfaces at this stage. This may well help any future troubleshooting. To do this, simply click on the respective interface name (i.e. Eth1c0) under the “Logical” column, and alter the name accordingly. Figure 2 Interface Configuration Screen


7 (32)

Apr 2004

2.1 ARP After the interfaces have been configured, from the Voyager main menu select “Arp” from the Interface Configuration section. Once in this screen notice that the interfaces will be listed along with their corresponding MAC Address. By default IPSO does not accept Multicast ARP replies; however, because you will be creating a Cluster between the two IP350s you will need to turn on “Accept multicast ARP replies”. If you don’t do this, you will be unable to form a cluster as the unicast IP address of the Cluster resolves to a multicast MAC address. Figure 3 ARP Entries

Figure 4 Accepting Multicast ARP Replies


8 (32)

Apr 2004

2.2 Cluster Configuration After configuring the Interfaces and the Arp multicast setting, from the main menu select “Clustering Setup”. Enter your Cluster ID along with your designated CADMIN password. Your Cluster ID can be any number between 0-65535, and you will use it when configuring any Cluster members (as they will need to connect to the relevant cluster). The CADMIN (Cluster Admin) user is the user designated to administer any Cluster configuration. Once your Cluster is up and functioning you can log into the Cluster with these credentials. Figure 5 Clustering Setup

Figure 6 Creating IPSO Cluster

Once applied, the following screen will show the newly created Clusters’ Status. Figure 7 Cluster Status (uninitialized)


9 (32)

Apr 2004

Cluster Status page (cont’d)

The Cluster Status page is where you need to enter all information necessary for forming your Cluster. Within the first section of the page, select “Multicast” for the Cluster Mode option and select “Up” for the “Cluster State” (do not select apply/save yet). From the second section (Interface Configuration) click the “Yes” radial for all interfaces (we want to add all of them into the cluster). For each network you need to assign a Cluster IP Address (this is a unicast IP address that has a multicast MAC address). In this design, the physical interfaces for FW-A all have IP addresses which end in .1 whilst .2 has been assigned to the physical interfaces for FW-B. The Cluster IP address for each interface will be .3


10 (32)

Apr 2004

The final part of this screen entails temporarily disabling the monitoring of the Firewall/VPN daemon. Disabling this daemon is necessary whilst configuring IPSO as at this stage, the firewall software has yet to be configured. It is imperative to have IPSO configured correctly before beginning any firewall software configuration; not only that, but the Cluster will not start with this monitoring enabled whilst the software is not loaded. Figure 8 Disabling Firewall Monitoring

Once all these settings have been entered, select apply and then save. You will see the screen as illustrated in Figure 4. Notice that the Cluster Protocol State shows a green circle showing that it is up, along with indicating that it is the Cluster Master Node. Figure 9 Cluster Master


11 (32)

Apr 2004

Now login to the other IPSO firewall, configure the interfaces/arp, and then select Clustering Setup from the main menu. Enter the Cluster ID that you wish to join (the one you just created on the Master), along with the CADMIN password, then enter the IP address of the Cluster Master (as you would have already entered all your interface configuration information into the second IPSO firewall, IP connectivity between the two should now be possible). For example, eth1c0’s IP address on the Master is 172.16.16.1, so enter this in the “Cluster Member Address” field. Now select “Join existing IPSO cluster”. Figure 10 Cluster Member

From the Cluster Status page, you should now see that the Cluster Protocol State has again changed to green, whilst this appliance indicates that it has joined the Cluster as a member.


12 (32)

Apr 2004

2.3 Clusters and Switched Ethernet Networks A cluster is relatively simple to configure when deployed using a single broadcast/collision domain. For this reason, hubs are often recommended for the Layer 2 interconnectivity within the Cluster domain. However, hubs are very limited in terms of bandwidth and security. In the real world switched networks have become commonplace as they offer far more scalability in terms of bandwidth available per port, port configuration and security features. Common topology designs incorporate VLANs for segregation of Layer 2 broadcast and collision domains. VLANs not only isolate collision domains, but they also confine broadcast and multicast traffic to the origin VLAN. If you wish to use switches as the Layer 2 interconnectivity devices for your network, you need to take into consideration their effect on any broadcast and/or multicast traffic that is required within the network. In our topology we have deployed Cisco 3500XL switches. We would have been unable to establish our Cluster without making a slight alteration to the default switch configuration. If the switches were left in their default state with all networks sharing a single collision and broadcast domain, the Cluster Protocol State would have remained stuck at the “Join” phase. Figure 11 Stuck In Joining State


13 (32)

Apr 2004

Looking at /var/log/messages would show that the Cluster seems to be looping when the Primary Cluster Protocol network tries to join Figure 12 Interrogating /var/log/messages

To get the Cluster to an active state, we need to carry out a few actions on the switch. Firstly, we need to segregate (at Layer 2) the Primary and Secondary Cluster Protocol network. We can do this by assigning each network its own VLAN. In our topology we have assigned VLAN 30 to the Primary Cluster network and VLAN 40 to the Secondary Cluster network. To configure this information on the switch we would enter the following: Figure 13 Switch Configuration (VLANs)


14 (32)

Apr 2004

Certain switches require a static MAC entry to enable the switch to forward packets destined for a multicast MAC address out of multiple switch ports. Remember, all nodes in the Cluster receive every packet sent to the Cluster (although only one will process the packet – determined by the Master), thus the administrator needs to make sure that the switch is able to forward packets destined for the Cluster to all nodes within the Cluster. In testing, it seems that the 3500XL does not need this additional configuration in order to accept ARP replies containing multicast MAC addresses. The 2600 routers each need a static ARP entry added, in order to assign the multicast MAC address to the Cluster IP address. If we take a look at the ARP table prior to this addition we can see that the Cluster IP address (172.16.16.3) has no MAC address assigned to it, thus traffic destined for the Cluster will be not be forwarded. (Look at Resolution 15563 on the Nokia Support Site http://support.nokia.com for an IPSO Clustering and Switches FAQ). Figure 14 Router ARP Entries

To add a static ARP entry into the 2600 enter the following: Figure 15 Adding Static ARP to Router

Now if we take a look at the ARP table we notice that the Cluster IP address has an associated MAC address (the multicast MAC address). Traffic destined to the Cluster will now be successfully forwarded. Figure 16 Router ARP Table after Static ARP addition


15 (32)

Apr 2004

To work out what the multicast MAC address of the Cluster is we can simply check the output of “ifconfig –a” : Figure 17 Finding the ClusterMac Address

From this information we can obtain the “clustermac” for eth1c0 (logical name: Outside) is 1:50:5a:10:10:3 Once the relevant ports have been assigned to their corresponding VLANs, the switches have had the multicast MAC entries added and the corresponding routers have had their ARP tables updated with the Cluster IP information the Cluster will be able to form and actively process traffic.


16 (32)

Apr 2004

2.4 Monitoring the Cluster

To check the state of the Cluster at any time, you can login to the Cluster Voyager. Simply open a browser and enter the IP address of the Cluster. Use the CADMIN credentials when logging into Cluster Voyager. Alternatively you could connect via SSH/Telnet to the Cluster IP address, using the same credentials in order to get a CLI session. Figure 18 Accessing Cluster Voyager


17 (32)

Apr 2004

Notice in the illustration below that after logging into the Cluster Voyager, the screen shows a summary of the members’ active within the Cluster. The first node is generally the Cluster Master, although to further investigate the health of the Cluster we can check by selecting “Monitor”, and from within the Cluster Monitor menu, selecting “Clustering Monitor” Figure 19 Cluster Voyager Initial Screen


18 (32)

Apr 2004

Figure 20 Cluster Monitor Status Page

The Clustering Monitor page is refreshed every several seconds; as such it is a useful tool to be able to check the status of the Cluster at any time.


19 (32)

Apr 2004

3. CONFIGURING OSPF WITHIN A CLUSTER In order to configure OSPF within an IPSO cluster login to the Cluster Voyager, select “Config” and from within Routing Configuration select OSPF. Figure 21 OSPF Configuration within Cluster Menu

Once into the OSPF options screen, you will need to enter a Router ID for your OSPF domain, along with selecting which interfaces/networks will be taking part within the domain. In the topology outlined in this paper, the Backbone (Area 0) connects the 3 departmental 2600 routers with the central location Firewalls across switched Ethernet. Area 0 is confined to VLAN 10, thus OSPF backbone traffic will also be confined to this VLAN. The Router ID on the FW cluster has been set to an arbitrarily high value (222.222.222.222). One would normally assign an IP address to a loopback interface for this purpose. I’ve used a high IP address value for the FW cluster as I want it to remain DR at all times. This is just a contingency value as the interface that connects the FW Cluster to the backbone has an OSPF priority (Election Priority) set to 2, whilst I have set all router interfaces that connect to the backbone with a priority of 0, with the exception of RTA which has a priority of 1. By defining the OSPF Priority value of the interface we are able to define what roles the FW Cluster and routers will play in the backbone OSPF area. In this topology, the FW Cluster is the Designated Router (DR), whilst RTA is the Backup Designated Router (BDR)


20 (32)

Apr 2004

Figure 22 Adding Interfaces to Areas

After entering the RID and backbone area information into the Cluster Voyager, we can then go on to configure each router with the same information. Firstly, we’ll configure the BDR. Figure 23 Cisco OSPF Configuration


21 (32)

Apr 2004

On each router we need to configure an OSPF process, a loopback for each RiD along with any networks that we wish to advertise (refer to xxx for the specific topology information). As each department only has a single exit point to the outside world (out through Area 0), we shall configure their internal networks as Stub areas. This helps reduce the size of the topological database inside the backbone. After configuring an OSPF process (Area 0) on the FW Cluster (DR) and the BDR we need to confirm that both OSPF databases have processed through the various OSPF stages, and are now showing the FW Cluster as DR and RTA as BDR. To confirm this within IPSO, open a CLI session on the Cluster, type “iclid” and enter “show ospf neighbour” (sh ospf nei for short) Figure 24 Obtaining OSPF Neighbour Information

On RTA we enter “show ip ospf neighbour”

If both are communicating correctly the state column should indicate “FULL” on both, whilst on the FW Cluster the Neighbour ID (being RTAs RID) state should indicate that it is the BDR. If both do not get to “FULL” state then the process for debugging begins. First thing to do would be to double check all your parameter settings. Make sure you are correctly advertising the relevant networks to the correct area (by default, IPSO reserves 0.0.0.0 for the backbone). On the router, confirm that you are receiving OSPF hello packets: issue a “debug ip debug ip ospf hello” to check for this Figure 25 Checking for “Hello” packets on Cisco Router


22 (32)

Apr 2004

From within the Cluster Voyager, turn on debugging for OSPF. To do this, from the main menu select “Routing Options”, from the following screen select “All” for OSPF logging. You can also change the size and number of trace files if you so wish. The log file(s) are stored in /var/log with the name IPSRD.LOG Figure 26 Setting Up a Trace File for OSPF Debugging on IPSO

Figure 27 Output of IPSRD.LOG Tracefile

Another option would be to go into “Monitor” from within Cluster Voyager. This would give us an HTTP(S) version of what ICLID would show. Possibly of benefit if we cant get SSH access to the FW Cluster for whatever reason.


23 (32)

Apr 2004

3.1 Understanding the OSPF Mesh Now that we have configured the DR and BDR for the backbone, the final stage is to add the other departmental routers into the domain. As we have already configured and enabled our DR and BDR this task is relatively straightforward. The only difference on these departmental routers is that we want to set their OSPF priority for Area 0 to 0 (zero). By doing this we make sure that neither will ever become the DR/BDR for the backbone. We want this in our topology as we have decided that any external connectivity will only ever come in through either the FW Cluster or RTA. Once we have configured both routers (RTB and RTC) we need to again run through the checks necessary to confirm that they have successfully joined the OSPF domain, and are actively advertising their own local network(s). The major difference we shall see here is that not all routers need to form full adjacencies with the DR and BDR. Let’s look at the adjacencies mesh that we have created for Area 0 Figure 28 OSPF Mesh (Never a Full Mesh!) Campus OSPF Mesh

RTB

RTA

Cisco 2610

LINK

Cisco 2610

ACT

ETHERNET 0

ACT

ETHERNET 0

LINK

CONSOLE

AUX

Cisco 2610 CONSOLE

AUX

LINK

ACT

ETHERNET 0

CONSOLE

AUX

RTC

BDR

DR

Specifically, in the above screenshot we can see that RTC and RTB are showing “2 WAY / DROTHER” state. We can also see that RTA whilst showing “Full” State with all other devices in Area 0, shows DROTHER for RTB and RTC. What is this? This is how OSPF works! If all routers formed adjacencies with all other routers in an Area imagine the potential for the amount of Link State Advertisements (LSA’s). As Area 0 got larger, the problem would get out of control, causing severe degradation of the Ethernet due to the amount of routing protocol traffic on the wire. OSPF avoids this problem by establishing a DR and BDR. Routers in an Area need only form adjacencies with the DR and BDR. Thus, our Campus OSPF Mesh is exactly how we should expect it to be.


24 (32)

Apr 2004

RTA shows “FULL/DROTHER” for its RTB and RTC neighbour connections. This is because it is the BDR so both the other routers have to get to FULL state with it (and the FW Cluster). Its neighbour database also shows that the FW Cluster is the DR. The FW Cluster shows the same as RTA with the exception that it doesn’t state DROTHER for its neighbour connectivity with RTB and RTC (although they are both DROTHERs). It also shows that RTA is the BDR. RTBs neighbour database shows that it knows that the FW Cluster is the DR and that RTA is the BDR. As for its knowledge of RTC, it only lists this as 2WAY/DROTHER. This indicates that it has seen its own IP address in OSPF Hello packets seen from RTC and therefore transitioned from (firstly) the OSPF DOWN state, through the INIT state, and now into the 2-WAY state. After this state, elections are performed, but as both RTB and RTC have their priorities set as 0, neither will take part in this process as neither will ever be either a DR or a BDR within the backbone area.

This concludes the necessary actions required to configure Clustering and OSPF routing within IPSO 3.8. The author appreciates that there are virtually limitless topology options available when implementing OSPF; however this paper is not intended as an OSPF design guide. It is imperative that the entire routing and switching infrastructure, along with the IPSO software is completed, tested and fully functional before beginning any firewall software configuration. The following section covers the actions necessary for configuring Checkpoint NG AI R55 for operation with an IPSO Cluster and OSPF.


25 (32)

Apr 2004

4. CONFIGURING OSPF WITHIN CHECKPOINT NG AI R55 Firstly, it is important to remember that each Cluster node must run exactly the same version of NG. As the IPSO Cluster configuration has already been built, you could check this by simply logging into Cluster Voyager and looking at the home page. Alternatively you could go into “ICLID” and run a “show version” command. Upon running the initial “cpconfig” script it is important to choose the following selections: o o o

Select Enforcement Module only (do not select Enforcement + Management) Choose “Yes” when asked whether to install a CP Clustering product If using IPSO 3.8 and AI R55+ make sure to enable SecureXL

Figure 29 CPCONFIG from within IPSO

Finally, make sure to apply your CP license after which, reboot the appliance. The Management install is pretty much a standard NG install.


26 (32)

Apr 2004

Next, on the Management station create a new Gateway object for each firewall node, after which create a Gateway Cluster object. Figure 30 Creating Gateways and Gateway Clusters

4.1 Gateway Cluster Object For the IP address of this object, use the external Cluster IP address of your topology (in this design, the address used is 172.16.16.3). Next, add both firewall objects you created in the previous step into the Cluster: Figure 31 Popluating the Gateway Cluster


27 (32)

Apr 2004

Notice that upon selecting “ok” to add the member to the cluster you will receive the following Information dialogue box: Figure 32 Cluster Only Retains Certain Information of the Firewall Gateway

Thus, when you create the initial firewall object keep in mind that only the information listed above will be retained when the firewall object is added to the Gateway Cluster. As were running IPSO 3.8 with NG R55+ we can select the following options from “3rd Party Configuration”: Figure 33 Gateway Cluster HA

In fact, to make things easier the options are automatically selected for us after we select “Load Sharing” for the Cluster Operating Mode, and “Nokia IP Clustering” from the 3rd Party Solution drop-down box.


28 (32)

Apr 2004

o

High Availability This would be the option to check if we were running VRRP

o

Support non-sticky connections IPSO clustering does not detect non-sticky connections itself. Instead it relies on the NG synchronization mechanism to do this. Non-sticky connections effectively describe asymmetric routing behaviour.

o

Hide Cluster Members’ outgoing traffic behind the Cluster’s IP address You want the Source IP of any packet leaving the firewall to be that of the Cluster IP address (the Cluster VIP), and not that of the actual physical interface of the firewall which processed the packet.

o

Forward Cluster’s incoming traffic to Cluster Members’ IP addresses Incoming packets destined for the Cluster are sent to the Cluster VIP. However, the Cluster Master then needs to change the destination IP address to that of the firewall it has selected to process the traffic.

On the Synchronization tab, make sure the “Use State Synchronization” check box is ticked, then select “Get” to dynamically extract this information from IPSO Figure 34 Adding the SYNC Nets (Dynamic)


29 (32)

Apr 2004

A word on synchronization… In this design I have stipulated the use of a Primary and Secondary IPSO Cluster Protocol network each having its own interface. As NG has automatically detected both sync networks, it will use both of them to simultaneously carry NG State Sync traffic between the firewall nodes within the Cluster. It is important to remember that if you are thinking of deploying a design that has the potential for heavy throughput (i.e. more than 100Mbps traffic through an interface), then the NG State Sync network interface(s) should also be able to handle this amount of throughput. Secondly, do not use Trunk ports to carry either IPSO or NG State Sync information (NG State Sync wont work over a trunk link anyway). Onto Topology. Another simple tab thanks to the interaction between IPSO and NG. Simply click “Get” in order to populate this section with the Cluster IP addresses for each subnet Figure 35 Cluster Topology Information (Dynamic)

Another new part of this is the “Enable Extended Cluster Anti-Spoofing” checkbox. Basically, when a Cluster node sends packets to another Cluster node it sets the TTL to 255 (highest possible value). This stops potential attacks from the internet as packets reaching the Cluster VIP from the Internet will have a much lower TTL than 255 due to the amount of hops taken to reach the destination (each hop decrements TTL by 1)


30 (32)

Apr 2004

4.2 OSPF In the Rulebase As far as NG AI is concerned, you need to know just one thing about OSPF: o

OSPF sends multicast packets to 224.0.0.5 and 224.0.0.6

Figure 36 OSPF In the Rulebase

The above rule illustrates what is necessary in the rulebase in order for OSPF communication to work between the Cluster and the other OSPF routers. Specifically, a Group object has been created containing the three routers (RTA, RTB and RTC). Secondly, two Host objects have been created each titled according to their requirement (and RFC denomination in this case). The Host objects represent AllSPFRouters (224.0.0.5) and AllDRouters (224.0.0.6). AllSPFRouters This is the multicast address to which all routers send “Hello” packets to. Also all packets originated by the DR and BDR are sent to this address. AllDRouters This is the multicast address to which all routers except the DR and BDR send Link State Updates and Link State Advertisements to. The rule has been created this way in order to save on the amount of rules required. Obviously you could be more specific with your src/dest fields if you wished. With regards to the Service allowed, the rule allows OSPF (ip 89) and icmp for testing. After finalising the basic ruleset, and pushing policy, SmartMap depicts our topology as follows: Figure 37 SmartMap Representation of Topology


31 (32)

Apr 2004

TESTING WITH NG AI RUNNING Once you have created your policy and pushed it to the Enforcement points, the final step is to test connectivity. This is where the initial testing prior to loading NG AI is so important. It is imperative to know that your Clustering and Dynamic Routing are both setup and working correctly before attempting any firewall configuration. Without this prior testing you will not know where to begin any troubleshooting. Firstly, check the output of “show ospf neighbour” from within ICLID (and on each router). If after pushing the policy, you get the following from the ICLID output, you know the rulebase is blocking OSPF packets:

Figure 38 Show OSPF neighbour (Before and After Firewall is turned on without OSPF rule)

Once the Dead timer has elapsed, the entries will be completely removed indicating that as far as the Cluster is concerned, it no longer has any OSPF neighbours. Not good. Upon successful installation of the correct policy, the Neighbour state will again be FULL. Also, the fw log (if logged) will contain allowed entries between the OSPF talkers:

Figure 39 Valid OSPF Communication seen in the FW Log


32 (32)

Apr 2004

The final test is the removal of the Cluster Master whilst a session is active. Specifically, to test this in the topology we have created, we will telnet to a router from a workstation on the inside network, once connected we will initiate a ping back to the workstation and whilst the ping is running, disconnect the Cluster Master’s external interface. In our topology, a telnet connection is initiated from the workstation (192.168.10.11) residing on the Internal network to the Cisco 2600 (RTA) situated on the External network. Once connected, a ping is setup to generate 1000 icmp echo-requests to the workstation on the Internal network. You can see from the screenshot below when the cable was pulled (the two dots in the middle of the exclamation marks), effectively taking down the Cluster Master. As you can tell from this, failover is sub-second, and only 2 of the 1000 icmp echorequests were lost in the transition. With application traffic this would never be noticed. Figure 40 Full Failover Test

One final point to note is that with the introduction of IPSO 3.8 and R55+ there is closer interaction between the OS and the application. Specifically, when creating the Gateway Cluster object certain fields could be dynamically populated simply by clicking the “Get” button. This is the result of a concerted effort to reduce the amount of duplicate administration required with the two environments. As a result, you will also notice that once you have R55+ configured, certain things will be removed from the Cluster Voyager. If you go back into Clustering Setup from the main Cluster Voyager screen you will notice that the Hash Column under Network Configuration no longer exists. Prior to this release their used to be a requirement to manually define the NAT configuration of each network within the cluster. Furthermore, notice that the VPN tunnel fields have also all been removed. Both of these sections are examples of where IPSO and NG are becoming smarter with their administration requirements. Expect to see more of this!

Nokia Standard Document Template - Check Point

Nokia Standard Document Template - Check Point

Suggest Documents