VSX design help

[oli139405]

Hi CheckMates,

1. Architecture

• Platform: R81.20 VSX cluster (two appliances).
• Upstream edge: Cisco CSR owned by the carrier.
• Public block: public_IP/26. The carrier will send the whole /26 to one next-hop; they do not want to create a second sub-interface / VLAN.
• Management: out-of-band eth0 on a physical switch → Smart MDSM.

2. Two design options

  Our proposal  Customer request

CSR↔VSX hand-off	Two VLANs • VLAN 100 → VR (routes /26 to VS1-VSn) • VLAN 101 → VS0 (/32 for admin VPN)	One VLAN only • VR owns the whole /26, including the /32 for admin VPN
Admin remote-access	Terminates on VS0 over VLAN 101	Has to terminate on VS0, but through VR over same VLAN
Status	Works fine	Warp link created between VR and VS0, but traffic never reaches VS0; cannot pick VS0 as next-hop for the /32 route

The two diagrams are attached for clarity.

3. What we have tested

• Created VR → assigned the /26 to its external interface.
• Added VS1…VS6, each gets a /32 (or /29) from the /26 — those routes are built automatically via warp links, OK.
• Added a warp link to connect VS0 to the VR (unnumbered).
• Tried to add a static host route <VS0-public>/32 → VS0 inside the VR.
  Problem: VS0 never appears in the drop-down list; CLI (set static-route) complains it is an “invalid next hop”.
• Result: admin VPN can’t establish, SmartConsole can’t reach VS0.

4. Questions for the community

1. Is there a supported way to make VS0 reachable through the same VR, without asking the carrier for a second VLAN?
2. If not, can each Virtual System expose its own “management interface” that SmartConsole could use directly (so the admin VPN could land on the customer’s VS instead of VS0)?
3. Any hidden trick (e.g. numbered warp, PBR, loopback) that would let me route that single /32 back to VS0 while the rest of the /26 stays in the VR?

5. Why we hesitate

• Check Point docs say only VS0 should communicate with the Management Server, and that traffic must not traverse another VS.
• The customer is pushing hard to keep one interconnect on the CSR.

Has anyone solved a similar “single /26 – need admin VPN on VS0” constraint before?
Appreciate any pointers, even if the answer is “you really do need the second VLAN”.

Thanks!

[PhoneBoy]

Not sure this is possible in Legacy VSX.
VSnext (available in R82+) might support this since the routing is configured directly in Gaia OS versus in SmartConsole. 

[oli139405]

Thanks, PhoneBoy.
That matches what I’m seeing in the docs: in R81.20 “legacy” VSX only VS0’s interface can talk to the Management Server; management traffic can’t be hair-pinned through a member VS or a VR. The guide is explicit — “Only VS0 can communicate directly with the Management Server” and non-DMI designs are deprecated .
Because of that restriction, a single /26 delivered to a VR can’t also terminate the Remote-Access VPN on VS0 without some extra L2/L3 breakout (second VLAN, loopback, etc.).
I’ll lab the same design on an R82 “VSnext” image where routing is native in Gaia and report back.

[emmap]

There is no need to have network connectivity between VS0 and the member VSs in order to manage them in legacy VSX, all network comms between the VSs and the management servers go to/from the VS0 IP address that seems to be on Eth0 in your diagram. With that said, what is the problem you are trying to solve here?

[oli139405]

The issue isn’t the VS → SMS traffic (that always egresses via VS0, no problem).
The obstacle is the administrator’s path into VS0:

1. The carrier hands us a single public /26.
2. We assign that entire /26 to a Virtual Router (VR) in front of the tenant VSs.
3. Remote-access VPN users still have to land on VS0 first so they can receive an Office-Mode IP, reach the management network on eth0, and then launch SmartConsole/SMS.

With only one interconnect (VR ↔ CSR) VS0 never sees the VPN’s public /32, so IKE negotiations fail.
If I add a second VLAN dedicated to VS0 the VPN works, but the customer wants to avoid creating that extra segment. I haven’t found a legacy-VSX workaround (no loopback /32, proxy-ARP, or similar trick), hence the question.

[Bob_Zimmerman]

NOTE: The following is an incredibly bad idea and should never be done in a real environment!

It's technically possible using dynamic routing. You have VS0 distribute a /32 route for itself, and you have the router instance pick it up. That said, in most topologies where I have seen this requested, it would be an existential threat to the environment. If any change to the router goes sideways, you could lose access to the box, and might not be able to restore it.

You could similarly connect both the router and VS0 to a switch context, and give them the public addresses on the warps. This does turn the public block into a broadcast domain, so you lose the use of some addresses.

[Martijn]

Hi,

From your information it sounds to me option 1 is DMI (Dedicated  Management Interface) and option 2 is non-DMI.
Non-DMI is not supported anymore.

In Legacy VSX, VS's do not have a management interface. Policy installs are done via VS0.
The same for SSH access. Connect to VS0 en switch to the context of the VS.

Clish: set virtual-system <ID>
Expert: vsenv <ID>

Martijn

[oli139405]

Exactly.

• Option 1 (two VLANs) — VS0 on a DMI VLAN, VR on a data VLAN → works fine but adds an extra sub-interface on the CSR.
• Option 2 (single VLAN) — non-DMI; public /26 on the VR only. VS0 has no IP on that link so Remote-Access VPN to VS0 fails.

The R81.20 guide confirms that non-DMI is “deprecated and not supported” and that management traffic must hit VS0 directly.