Configuring dynamic routing in clustered VSX

[Vladimir]

I have run in to the situation where dynamic routing should be implemented on virtual systems in a clustered VSX environment. Can someone tell me if it should be done only on VS' on active cluster member and it will be automatically replicated, or should it be setup on each instance of VS?

Thank you,

Vladimir

[Kaspars_Zibarts]

Oh dear... Last time I heard about VSX +DR was total disaster. I think customer ditched CP in favour of Juniper at the end. But that was a while ago, think it was R67 VSX

[Vladimir]

Well, they have it running now and it's been stable for years. Nothing too complicated: OSPF stub zones and passive interfaces facing hosts.

I am looking at making alterations to their environment and am looking at moving some of their stuff to a bridge-mode VS', but there are still some systems that need to receive the routes from the rest of the infrastructure.

Unfortunately, unless I am not looking in the right places, there is nothing in documentation specifically applicable to clustered systems and dynamic routing. Just references to the Advanced Routing documentation that describing the methods from a single system perspective only.

[Ni_c]

We were running OSPF on one of our production 61K in VSX with no high availability. However we need to configure DR separately on each cluster member. Have a look at here

Check Point VSX R80.10 (for future PDF publishing) Administration Guide 

[Vladimir]

May be it's just improper wording, but it says:

"You can also configure dynamic routing separately on each cluster member."

This can be interpreted as not being mandatory.

It can also refer to the dynamic routing on VS0 only.

I am trying to determine if I must configure dynamic routing on all instances of Virtual Systems located on all cluster members, or doing it on a single one running on Active cluster member is sufficient.

[XBensemhoun]

Hi Vladimir,

I have implemented with success OSPFv2 on 23600 VSX Cluster ; no issue.

Each instance has been configured (duplicate configuration on each VSX Gateway for the same VS id) ; start with the Secondary node and then the Primary in order to avoid cluster issues. Cloning group should help about synchronization of needed configuration but I do not use it.

Just : take care regarding OSPF Point-to-Point network (sk116500‌).

[Vladimir]

Thank you!

Vladimir Yakovlev

973.558.2738

vlad@eversecgroup.com

[Alex_Rozhko]

Hi Xavier,

can you elaborate: did you have OSPF on VSX(s) or VSs running on VSX?

[XBensemhoun]

We do not use context 0 as a 'firewall' but only all others context (VSid = 1, 2, ...) so we use OSPF on all our VS.

To be more descriptive:

In the following case:

1. there is one dedicated bond for each VS (bond.1 for VS id 1, bond.2 for VS id 2, ...)
2. there is one vlan (example : id 1001) to communicate with core switch ; such interface will be the External
3. the area backbone range is 192.168.0.0/16
4. off course if you have a cluster : same configuration should be applied on both nodes members
5. the cost and priority is set on this example to 100 and 200

We have the following configuration applied at the creation process of any VS:

VSXHost:1> show configuration ospf

show instance 1 configuration ospf

set ospf area backbone on

set ospf interface bond1.1001 area backbone on

set ospf interface bond1.1001 hello-interval 1

set ospf interface bond1.1001 dead-interval 3

set ospf interface bond1.1001 cost 100

set ospf interface bond1.1001 priority 200

set ospf interface bond1.1001 authtype md5 key 2 secret ****

set ospf area backbone range 192.168.0.0/16 on

set virtual-system 2
Context is set to vsid 2

VSXHost:2> show configuration ospf

show instance 2 configuration ospf

set ospf area backbone on

set ospf interface bond1.1002 area backbone on

set ospf interface bond1.1002 hello-interval 1

set ospf interface bond1.1002 dead-interval 3

set ospf interface bond1.1002 cost 100

set ospf interface bond1.1002 priority 200

set ospf interface bond1.1002 authtype md5 key 2 secret ****

set ospf area backbone range 192.168.0.0/16 on

...

And then, any time you create an interface, you add on the VSXHost the following line (here : for a vlan 12 on the VS id 2):

set ospf interface bond2.12 area backbone on
set ospf interface bond2.12 priority 1
set ospf interface bond2.12 passive on

[genisis__]

What is the recommended approach to configure OSPF and BGP on checkpoint vsx (redistribute into BGP)?  Why would you not want to use a virtual router in favour of configuring the DR directly on the VS?

I assume a firewall rule would also be required to ensure the VS is allowed to establish adjacency with neighbours as well.

Additionally I assume that none of the DR configurations are actually stored in the management database, so if we had to rebuild the VSX gateway, its important that these configuration as captured per VS and put back on after (Assuming no virtual router is used).

[emmap]

Unti recently, virtual routers were not supported on a VSLS deployment, so for many it was not an option to use them. It would still be an unnecessary layer 3 hop to add to many networks in order to deploy dynamic routing, so generally would be avoided. 

Yes, firewall rules are required for dynamic routing, depending on protocol. sk39960 has details here.

Correct, DR configuration is not stored on the management server so care should be taken to store this configuration separately, in a build sheet or wherever other baseline gateway configuration is stored. 

[genisis__]

Thanks, so I assume virtual routers are now supported from R81.x?  If so is this the preferred method to use?  I assume if you have many VS's and each VS requires a VR, then this actually is an additional over ahead to consider ie. resource usage on the appliances.

[emmap]

Virtual routers are supported in VSLS deployments as of R81, but I still wouldn't suggest that one should be deployed between every VS and the rest of the network where dynamic routing is required, standard VSs are perfectly capable of performing reasonable dynamic routing duties while firewalling. If you were in a situation with a lot of changes happening in the routing table or peers appearing and disappearing then that might be a different story.

[genisis__]

Thanks.

In the VS itself is there the concept of a loopback IP which is used as the router id for adjacency, and if there is would this be preferred to use, not sure how that would affect topology though ie. in Smartconsole.

[emmap]

No loopbacks on virtual devices, an interface IP (the IP configured in SmartConsole) must be used. 

[genisis__]

OK so went to add a new OSPF area into an existing VS.  Simply templated what was there, but neighbour did not come up.  We have added the peer IPs to the firewall rules so we know this is not being blocked.

It almost feels like the routed daemons hung and only processing what's there.  Will do some more investigation.

example:

set virtual-system <10>
set ospf instance default area <0.1.2.3> on
set ospf instance default area <0.1.2.3> nssa on
set ospf instance default interface <eth1.123> area <0.1.2.3> on
set ospf instance default interface <eth1.123> subtract-authlen on
set ospf instance default interface <eth1.123> authtype cryptographic key 30 algorithm md5 secret <ABC123>
save config

I've confirmed that hello packets are entering the VS, however nothing is being sent out for this new area.

[Chris_Atkinson]

What does the interface level config on the other device look like? Things like point-to-point mode aren't supported.

[genisis__]

managed to get it working without authentication as a test, so we now know our root cause.

I'm sure there is a way to debug this type of issue.

[Maarten_Sjouw]

Don't forget that you also need the OSPF Multicast to be allowed, 224.0.0.5 and 224.0.0.6

Other point, make sure the MTU is the same on your interface and on the next hop.

We are running OSPF on all VSs in our Maestro VSX setup that runs in the core of our network.

[genisis__]

Rule is in place to allow access to 224.0.0.5/6.  MTU size I believe is default and also note that other OSPF instances are working across the same trunked interface.

[Bob_Zimmerman]

Keep in mind, the router ID is just a 32-bit number, not an IP address. It doesn't have to belong to any interface on the system.

To get dynamic routing on a cluster to work how most people want it to, you should specify the same router ID on both members and enable graceful restart.

[genisis__]

Is there a format difference between a router and GAIA for the OSPF area id, or should this exactly the same (I think it should be the).

[Bob_Zimmerman]

I'm not as familiar with non-backbone OSPF areas in GAiA. I know with gated on SecurePlatform, the OSPF area was represented in dotted decimal form like an IP address. I believe Cisco accepts that representation, but converts it to a simple 32-bit integer in the config. I'm not sure what Juniper and other vendors do.

Converting between dotted decimal and integer form is annoying, but pretty simple. To go from dotted decimal to integer, multiply the first byte by 2^24, second byte by 2^16, third byte by 2^8, then add all three of those values plus the value of the fourth byte. To go from integer to dotted decimal, the first byte is the the whole part of integer divided by 2^24, second byte is the whole part of integer mod 2^24 divided by 2^16, third byte is the whole part of integer mod 2^16 divided by 2^8, fourth byte is integer mod 2^8.

If GAiA allows you to specify OSPF area IDs as just integers, I would do that for simplicity. OSPF area IDs aren't actually IP addresses either.