[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [FW1] Monitored Circuit Configuration on Nokia
Mark, Please take no offense, but if it is that easy, then I would rather use a rainfinity or stonebeat solution. Mark Hall/St Louis/IBM wrote: > > - -----Original Message----- > > From: [email protected] > > [mailto:[email protected]]On Behalf Of Mal > > Herring > > Sent: Thursday, February 15, 2001 9:31 AM > > To: 'Tim Anderson'; '[email protected]' > > Subject: RE: [FW1] Nokia vs. NT > > > From what I know - No Load balancing unless you configure ½ hosts on one > and > > other ½ to other fw, and fail-over with VRRP has caused me load of grief > so > > I am looking to use the Monitored Circuit solution - should anyone have > any > > knowledge on this - please mail me. > > > regards > > > mal > > Well, this isn't an absolute guide, but a basic so you can get monitored > circuit working correctly. This example assumes that you're using two > firewalls that are mirror images of each other...: > > 1) Count the # of interfaces with VIRTUAL addresses that you plan to use > (i'll use 6 for our example). Make sure your delta is higher than this > number. I'm going to assume you are using fewer than 14 interfaces. ;-) > 2) For each interface with a VIRTUAL address, check the 'monitored > circuit' radio buton, and then apply the page. > 3) Define a router ID for each virtual address. Note: This ID *MUST* be > unique per network segment. This router id is used to generate the MAC > address for the virtual address. This address will be 0:0:5e:0:1:xx where > xx is the hex value of the router ID#. This is WHY you can't have more > than 1 set of firewalls sharing a VRID on a single network segment, > otherwise they'll BOTH try to pick up and forward the packets. In fact, > we found a problem when we shared a VRID# that forwarding didn't work > correctly, and two firewalls on the same management station both received > the same packet - one accepted, one dropped. got confusing in the logs. > ;-) > 4) Once this is done, simply multiply your # of interfaces by something > like 15 and add some number. This also must be less than 255 (it's a one > byte field). I recommend adding something like 15. With the 6 interface > example, my primary's priority will be 100. Fill out the field per > interface with the virtual address, the primary's priority, and a hello > interval of 1 (failover within 3 missed hellos, or 3 seconds). For the > secondary, its priority should be somewhat less than the primary's, and > higher than a single interface's delta. Remember the multiply by 15 > earlier? That's the delta we'll use, and the priority for the secondary > should be higher than this, let's use 95. If you're using more than 15 > interfaces, 15*15 is higher than 255, so you may need to add a 'negative' > number to drop the highest end to less than 255. What this will do when > they all subtract from your priority I don't know. =-) > 5) for each monitored interface, let's use a delta of 15, and select one > of the other monitored interfaces (i.e. interfaces 4 on 3, 3 on 4, 3 on 5, > 3 on 6, 3 on 7, 3 on 8), then apply. For the secondary, you cannot use 0 > as a delta, use 1, but do the same thing. > 6) apply each other monitored interface to each monitored interface with > the appropriate deltas. When any interface on the firewall goes down, > since every other interface monitors the one that went down, they'll > cascade shutdown, meaning NONE of your monitored interfaces will be 'up' > in the priority calculation, resulting in a value of 10. Then, the > secondary will have a higher priority, and will take over the virtual > addresses. This is how it should work. So interface 3 should end up > monitoring 4, 5, 6, 7, 8. and so on. > Don't forget to add a firewall rule to allow multicast traffic from all > physical and virtual addresses to talk to 224.0.0.18 with a service type > other named VRRP with a match of: ip_p=0x70. > 7) Then click on the "VRRP monitor" link at the bottom of the VRRP page. > The primary should be ALL master, and the secondary should be ALL backup. > If any don't match correctly on the secondary, those interfaces can't > communicate. Try pinging the physicals between them to make sure they > work. If it all works, you can 'bounce' the nokia, and the other one will > pick it up in 3 seconds. If you IF down an interface, it will fail all > over to the other machine. We've had some problems with FW1 working right > after doing this though. > > Oh, one other important thing, remember you CANNOT ping or talk to the > virtual at all, but you will see its entry in your ARP tables on other > systems, and if it's working right, the packets will pass through. i.e. > you can ping through it, telnet through it, whatever your rules allow. > > Hope this helps. :-) > > Mark Hall <>< > CheckPoint Certified Security Engineer > Certified AIX System Administrator > > Mailstop S306 2182 > IBM Global Services - Network Services > 325 J.S. McDonnell Boulevard > Hazelwood, MO 63042 > Voice:Fax:> > This message contains an average of 73% post-consumer electrons. > > ================================================================================ > To unsubscribe from this mailing list, please see the instructions at > http://www.checkpoint.com/services/mailing.html > ================================================================================ ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|