Monday, December 3, 2018

Cross Vcenter NSX with OSPF

References:

Cross Vcenter NSX Design Guide
 
Intra area routes versus inter area routes


 
In one of the earlier posts, we have covered running OSPF in NSX domain.

Here we try to cover running OSPF in a Cross Vcenter NSX setup.

In the above topology:
1. There are two NSX managers.
Primary NSX manager in site 1
And secondary NSX manager in site 2
This is a Active/Passive model.

2. One vcenter in site 1 and the other in site 2

3. Universal Distributed Logical Router UDLR is connected to edges in primary & secondary site using a single Transit logical switch.

4. There are two edges in site 1 and additional two edges in site 2

5. The edges are connected to physical routers as shown above.

6. The physical routers are OSPF Area Border Routers interfacing with OSPF backbone area 0.

7. Totally NSSA area configuration is applied in this setup.
The Area Border Routers are injecting a default route automatically into the NSX domain.

8. Only one Universal Transport Zone can be created to span both the sites.

9. Universal Distributed Logical Router UDLR spans both the sites and allows connecting workloads from both the sites.
The status of UDLR in primary site is 'deployed' while in the secondary site it is 'active'.

10. Universal Distributed Firewall spans both the sites.

11. Universal Controller Cluster is deployed in Site 1

12. Universal objects can be created only from the Primary NSX Manager.
If there is a need to deploy additional UDLR, then this has to be done from Primary NSX Manager only. In this case the UDLR will consume resources (compute, memory and storage) of Site 1

13. UDLR control VM will reside in Site 1 and will establish OSPF peering with NSX edges from both sites 1 and 2.

14. Site 1 is preferred for ingress/egress traffic because the OSPF cost is increased for links between Site 2 physical routers and Site 2 NSX edges.

More traffic flows are discussed in traffic flow section below.


 ===============================================

Let's map this NSX topology with Cisco routers and explore the routing tables on devices.




Subnet 192.168.1.0/24 is connected to router UDLR.

And we check the route lookup for 192.168.1.0 on routers:
1. Core2
2. Core1
3. Physical Router 1 of Site 2
4. Edges of site 1 and site 2

Note the route lookup for 192.168.1.0/24 on Site 2 router 1 prefers the route towards NSX edges in the same site, site 2.
This is despite increasing the OSPF cost on the links connecting Site 2 physical routers and Site 2 NSX edges.
This is because OSPF prefers intra area routes as compared to inter area routes.




Above output shows that OSPF metric is increased to 120 via Site 2 physical routers.





Route for 192.168.1.0/24 on Core2
 Next hop from Core 2 for subnet 192.168.1.0/24 is Core 1 because of lower OSPF cost between site 1 physical routers and Site 1 NSX edges.



Route for 192.168.1.0/24 on Core 1

Route for 192.168.1.0/24 on Site2 Router 1



Route for 192.168.1.0/24 on Site 1 Edge

Route for 192.168.1.0/24 on Site2 Edge

Default route on UDLR

==================================================

Traffic flows


UDLR follows the default route

If there are other services/customers connected to the physical routers of Site 2, then such traffic will not go via Site 1. Instead be routed towards local NSX edges in Site 2 because intra area routes are preferred as compared to inter area routes.



Ingress from Core WAN to App Tier LS
 

Monday, November 19, 2018

Vrealize Network Insight 3.8 Installation


References:

VRNI Architecture:

Installation Guide:


This installation is broken down into two parts:
- One for platform &
- The other for Collector aka Proxy.

During the deployment of OVA for Platform & Proxy, you will use Thin Provision as the virtual disk format.

1. The first step with regards to Vrealize Network Insight installation is to deploy the OVA for Platform & initialize the Platform.

Once deployed, power on the VM and get to the console access of the platform VM.

Here run the setup command.



 And enter the passwords for SSH user and CLI user.


As shown in the picture above, enter parameters related to network configuration:
- IP address
- Netmask
- Default gateway
- DNS
- & enter the name for domain search


Enter NTP server IP address.







Next, we will open up a browser and go to https://vrni_platform_ip 
In my case, it is https://192.168.110.99
Enter the license keys
And click on validate.


Once licensed and validated, you will next generate shared secret which will be used for Collector aka Proxy VM.





2.Collector aka Proxy deployment & initialization.

When you deploy the OVA for Proxy, you will need the shared secret as outlined in the previous step.

Next, get to the console of Proxy VM and initialize as outlined below.








You can now login to the Platform and enter credentials.




Thursday, August 23, 2018

NSX Edge Load Balancer - One Arm Mode




In the topology above, NSX edge load balancer is deployed in one arm mode.
NSX edge load balancer has a single layer 3 interface which is connected to Distributed Logical Router via a logical switch.
This logical switch is dedicated for Load Balancing Tier.

There is also a Web Tier hosting web servers and these web servers are connected to Distributed Logical Router via Web Tier logical switch.
Pool members corresponding to the virtual server are both residing on this Web Tier Logical switch.

The routing topology of this whole setup has already been covered in this post here.


The single vnic of NSX Edge Load Balancer has primary IP address as 172.16.20.100 / 24
The single vnic of NSX Edge Load Balancer also has secondary IP addresses assigned to it as below
Secondary IP 1 – 172.16.20.101
Secondary IP 2 – 172.16.20.102
We will be using one of these secondary IP addresses to create a virtual server.

=========================================

Configuration:

We will first enable the load balancer service on NSX Edge Services Gateway.
Enable Load Balancer Service


Application Profile
Application profile is created then and the details are as below
Application profile name - HTTPS
Application profile type – HTTPS
Certificate – For this lab setup, we have used a self-signed certificate.

Server Pool
Server pool is created as below
Pool name – pool
Algorithm – Round robin
Members – Virtual Machine web-01a, tcp/80
Members – Virtual Machine web-02a, tcp/80


Virtual Server

Virtual server is created using the secondary IP address and the virtual server details are as below
Virtual Server IP – 172.16.20.101
Virtual Server port – 443
Application Profile – HTTPS
Server pool name – pool

====================================


A management station is residing on the physical network with IP address as 192.168.110.10
We have also taken packet captures on the NSX Edge Load Balancer interface for below communications

  • Communication between the management station and the virtual server 172.16.20.101, tcp port 443
  • Communication between NSX Edge Load Balancer and the pool members.  


    Comm. between Mgmt. Station & Virtual Server


    Comm. between load balancer & pool members

















It is worth noting that in the case when a secondary IP address 172.16.20.101 is assigned to single vnic of NSX Edge Load Balancer & the secondary IP address is used to create virtual server, the load balancer uses the primary IP address 172.16.20.100 to establish a connection between itself and the pool members.

Both the above packet captures are done at the same time while trying to access the web page at https://172.16.20.101
NSX Edge Load Balancer is working as a reverse proxy and from the packet captures, it is evident that there are two different TCP connections -
  1. One between initiator and load balancer 
  2. The other between load balancer and pool member
============================================================

NSX Edge Load Balancer supports below features:

1. SSL Offload
2. SSL Bridging
3. HTTP Profile with ‘insert X-Forwarded-For’
4. Cookie based persistence as well as source IP based persistence is supported.
5. Redirection from http to https
6. Multiple ciphers can be used.
7. Load balancing algorithms which are supported are:
  • Round robin
  • IP Hash
  • Least connection
  • URI
  • HTTPHEADER
  • URL 
=============================================================

Some very useful resources:

NSX Admin Guide
https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/nsx_64_admin.pdf

NSX Reference Design Guide
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf