Splat Pro Ospf

[maurox]

Does anyone have any OSPF configuration experience with SPLAT NGX?
I tried to implement that, but , in cluster load sharing enviroment , I don't understand if it is normal that only one member has the routing table with the OSPF route learned via OSPF...
The routing configuration is the same on both modules and if I stop one member the other learn the routes.
Is this normal ?
I think no because in Load sharing all the memeber must have the route....but maybe there are some news feauters that adjust this...

Any Idea ?

Thanks ,
Maurox

[mpagliuzzi]

No it's not normal. Have you enable OSPF on both cluster's gateways ?
bye
MicheleP

[maurox]

As you can see from my previous message , the routing configuration is the same ; the issue was solved adjusting the multicast mac address configuration on the switch.

the problem now ( and for this we disabled the ospf configuration) is that when one module ( module2) goes down ( rebooting a node or stopping the daemons ) there are routing problems on the other ( module1) both when it ( module2) goes down both when it( module2) becomes up.

Is the same for you (if you have an OSPF config..)
Regards
Maurox

[chillyjim]

Stupid queston first, you do have the license for ClusterXL?

Next question, are you using SecureXL?

But you are correct, in a ClusterXL all gateways should learn the routes. Are you in "new mode" or "Pivot"/unicast Mode?

[maurox]

We have the licenses and yhe SecureXL enabled.
The configuration is with load sharing in multicast mode.
Please note that the problem wasn't on the dynamic routes :
after some test we see that they works ; only one member has the entire dynamic routes table , but the second module learn them by the first and all works fine ( in the lab without all the Dynamic routes but with some routes to test the OSPF) .

The problems , in production, and with a lot of routes learned via OSPF, were generated when we tried to reboot( or stop the fw/cpha daemon ) one of the modules:
nothing works for approximately 20 seconds when one of the members goes down and when it becomes active there were problems for other 20 seconds....

[baboo]

Hi Maurox

I think we're having the same problem.
During the fail-over to the standby-node there's an interrupt of 73 seconds.

If we trigger a failover (cpstop on active-node(gate3) ) the fail-over succed (to gate4), but the sync-interface on the node that became active (gate4) goes to "down". Which results in a topology change I think.
If we do that the other way (cpstop on the active-node gate4 to fail-over to gate3) the state of the sync-interface keeps "up".

I dont know if this is just related to the standby-clustering or also to the load-sharing. Can you verify this ?

We're also having troubles with the policy-installation. (see the other thread)
Do you also have problems with the policy-installation?

Regards, Manuel

[maurox]

Hi Baboo,
unfortunately I can't verify what you asked because dor the moment we are working with static routes and OSPF is disabled.
For the other question , when we tried to implement ospf in our cluster , we didn't have any problems with policy installation.
Best regards,
maurox