I don't think any of that is possible with NSX-T.
What are you trying to accomplish? You could have your segments connected to the T0 with no T1 and have the T0 peer with the Palo Alto.
No mauriciomorim, I would like to have multiple segment connected to a T1 DR and then make a BGP peering with this T1 and an upstream VM Appliance FW/Router through another segment in order to not use T0 SR.
Replacing T0 SR by third party perimeter VM gateway is due to additional features provided by this VM that the T0 SR should not be able to provide.
And also avoid reaching the 80 T0 limitation and juste having the 2000 T1 limitation.
You cannot connect a T1 directly to some other element. That is explicitly stated on section 4.7.2 - Unsupported Topologies in the design guide available here: VMware® NSX-T Reference Design
If you need other services not supported on the NSX routers itself look at using service insertion.
What is the problem with the T0 limitation? What kind of design and scale are you looking at doing?
The goal is to have a Distributed Router per customer Trust Zone (trafic allowed between segments) in order to avoid multiple zone on same T1 DR and make micro segmentation rule sprawl.
But with the max 80 T0 , it will be possible to create max 80 Trust Zone.
A group of Trust Zone will make a tenant. IP overlap is allowed between tenants so I can't share segments between tenants on the same T1 DR.
You confirm that for now a NSX-T T1 LR can only be "upstream" peered to a NSX-T T0 LR. The transit GENEVE segment and peering configuration between both is automatically managed by NSX-T.
A NSX-V DLR can be "upstream" peered to an NSX-V ESG and another virtual appliance. The transit segment between both need to be a VXLAN one.
But that's ok, I can use T1 DR > T0 Perimeter SR > 3rd Party Perimeter FW at the first time. But only 80 according to NSX 2.4 limitations.
This design is to make sure I can use DR inside a trust zone. If NSX is not able to reach +80 Trust Zones, I will use another tech when I will reach these 80 trust zones (few years).
My solution allow technical changes if necessary in the futur.
As for scaling beyond the current 80 T0 router limit there is always work on increasing scale in new versions. NSX-T 2.5 was announced this week at VMworld and when it goes GA configmax tool will be updated accordingly. It might be possible that this number increases. If the number doesn't increase by the time you actually grow the environment and reach its max the option is to scale out to a new NSX instance.
Thanks Mauricio for this feedback.
I'm not at VMworld and the solution is actually at the RFP /Solution Architecture state so for my own forecast, NSX-T should be at version 3.0+ GA when the 80 T0 limit will be reached
The solution to add another NSX-T instance is not fine since all compute ressources must be available for a trust zone/tenant.
But that's fine my design is more accurate now with our reflection.