Advertisement
Q01866402
Q01870563
Q01871072
Q01871983
Q01872414
©2007-2008 Nortel Networks Limited
NSF allows a maximum of 6 SFDs in a cluster. As per the design, first four SFDs
would be treated as 'Master" while the remaining two would be treated as "Slaves".
Slave SFDs cannot become MIP in case the MIP owner is down/not reachable.
They always wait for a MIP to start the services. This is done so as to limit the MIP
election process in case of a failure.
All the cluster members talk over a dedicated port which is taken outside the purview
of Check Point rule base. SSI bypass feature takes care of handling the
communication between the cluster members.
However, during the MIP fail-over process, the slave SFDs send broadcast packets
to enquire about another MIP owner in the network. And the SSI bypass feature was
not handling the broadcast traffic. So this traffic is handled by Check Point and if
there's no explicit rule to allow it, the packets would be dropped.
As the CP module is dropping these broadcast packets, the slave SFDs are unable to
reach MIP owner, which results in its failure to join the cluster.
The issue is solved in the release 4.2.3 by letting these broadcast packets handled
properly without the need for any explicit Check Point rule.
Accelerator goes to ACCEL-OFF state when more than 128 static arp entries are
added. Accelerator can only support up to 128 static arp entries, but there was no
validation on the SFD not to allow more than 128 entries. When the faulty
configuration is pushed to the accelerator, it results in accel off state.
This issue is resolved in the release 4.2.3 by adding a validation on the maximum
number of added static arps.
Consider a network with two hosts (host1 and host2) with same IP address. When
traffic flows from either of these hosts across the NSF, accelerator stores an ARP
entry with host1 Ip address and host2 mac address. If a user now adds a static ARP
entry for the same host1 Ip address but with host2's MAC address, configured static
MAC address should get preference while forwarding the traffic.
But traffic on host1 continues and host2 cannot be reached. This is caused due to an
error in the static arp handling.
The issue is fixed in the release 4.2.3 by properly updating the SP arp cache with the
added static arp.
The /var/tmp/sensors file does not rotate after reaching the max file limit. The issue
is resolved in the release 4.2.3.
Upgrade from BBI to 4.2.2_R65 from any lower version fails since the newly added
Check Point's HFA-02 for R65 has increased the package size to more than 200MB.
The maximum upload file size from BBI is set to 160MB, which is far less than the
actual size of the 4.2.2 package.
This issue is resolved in the release 4.2.3 by setting the maximum allowable size of
the package to 300MB from previous 160 MB.
4
Advertisement
