NSX-V 6.2 with Palo Alto for NSX for multi-VC environments

[rikherlaar]

Hi forum,

I have a customer already running NSX on multi-VC across two DC's today. Their ask is to implement PAN for NSX for both locations. I have implemented this for single VC environments and seem to recall there's a one to one relationship between NSX manager and Panorama. Can I assume I can register Panorama with multiple NSX managers (primary and secondaries) ? Is this documented somewhere ?

Many thanks in advance -

Rik

[mebogrr]

Rik,

You are remembering correctly; there is a one-to-one relationship between a NSX manager and Panorama. In the instance you are describing, assuming you have a NSX manager at each location, you will need to attach a unique Panorama instance to each one. At present, you cannot attach a single Panorama instance to multiple NSX managers.

Even in the case of cross-vcenter operations (with a primary NSX manager and one or more secondary), you will still need a unique instance of Panorama at each site in order to make this work.

Michael

[rikherlaar]

Thanks for confirming Michael. Much appreciated.

I would hazard a guess this is not yet fully validated/tested yet by VMW or PAN ?

Kind regards

Rik

[mebogrr]

Would you mind clarifying? I'm not sure what you are asking exactly.

I can say with certainty that the solution at hand is to deploy a Panorama instance at each site where an NSX manager resides (presuming you'll be deploying 1000-HVs via NSX). Customers choosing to do this are left with the pain of duplicating Panorama policies between each instance. However, there's really nothing to stop someone from having those Panorama instances spun up to only support the installation of the 1000-HVs, and then going into each 1000-HV and pointing it to your, for lack of a better word, "production" Panorama where the firewall rules you wish to utilize exist. In this scenario, you'd lose the ability to generate dynamic address groups based on the NSX security groups, so it depends on how important that function is to your environment.

Michael

[rikherlaar]

Hi Michael,

Happy to clarify a few things;

1> Deployment is in production - and is setup for Multi-Site and Multi-VC ( each location has local and universal VC inventory)

2> NSX managers operate in primary/secondary mode (not standalone)

3> My concern was around registering with <and> a primary <and> a secondary NSX Manager~  because to the best of my knowledge (which could be off base somewhat) , the secondary NSX manager is passive and synced with the primary for Universal components and active and not synced for Local attributes.

I seem to infer from your reply we would need to register a separate Panorama instance at site A and site B registering with primary NSX mgr in Sita-A and with the secondary NSX-mgr in site B - (to enable them to deploy 1000-HV instances on local clusters as indeed all clusters are local to the respective sites).

Once registered with the local-significant Panorama's - I could then point them to a sort of upper level Panorama instance which could manage objects in a universal fashion.

I'm sure this will at some point become more/better "integrated" (for the lack of a better word) ?

Kind regards

/Rik

[YvesHertoghs]

Rik,

Great to see you down here btw 🙂

The secondary NSX Manager is only secondary from the perspective of the Universal Objects.  He still manages local NSX objects, including the Panorama integration. 

As Michael was already saying, both NSX managers need to have their own Panorama registered, and the admin has to manually replicate policies amongst both instances.

Note that local policies can be applied to Universal objects , although there is the pain of manual syncing.

Yves

[mebogrr]

Yes, you'd require a Panorama instance at each site where an NSX manager resides.

As Yves was stating, while you may be using Universal constructs, for the Network Introspection piece (which is used to "punt" traffic to the deployed PAN 1000-HVs), you would be utilizing local rules. In fact, as of today you cannot create Universal Network Introspection rules. You would need to connect a unique Panorama instance to each NSX manager, and then utilize that local NSX instance to deploy 1000-HVs, as well as create local Network Introspection rules.

You are also correct that only Universal objects are synced between the NSX managers. You'd need local security groups, etc, on each NSX manager in order to perform the Network Introspection.

As far as Panorama goes, the base recommendation would be to duplicate your policies, as needed, between the two Panorama instances. You'd have to do this by hand, or you could even script something like this. The scenario I was describing (pointing the 1000-HVs to a "master" Panorama), if you wanted, is applicable as well, although you'd certainly lose the ability to parse NSX security objects via dynamic address groups.

I've heard rumors that Palo Alto is working to make it where Panorama can connect to multiple NSX managers, but as of now, that doesn't exist. Other vendors, like Checkpoint, have gotten around this limitation via utilizing different integration methods.

Michael

[rikherlaar]

I think I got it 😉

Many thx guys!

Rik