Showing posts with label NSX-T. Show all posts
Showing posts with label NSX-T. Show all posts
,

How to redeploy edge transport node in NSX-T(KB#00106)

 Hello Guys,

We all know that "How to redeploy the edge gateway in NSX-V" or "How to change the form factor of NSX-V edge from small to medium or large" but how many of you knows how to do it in NSX-T?

I am sure, till now few are in assumption that it is not relevant to NSX-T (at least first part) 😊

It is well relevant and we do redeploy edge nodes in NSX-T too. In this post I am giving you the method to not only redeploy it but also to change the form factor very easily. I gone through web before I did it by myself and could see very complicated process to replace the exiting node with the newly deployed node.

That might be relevant in some other scenario but my initial issue or goal was to change the existing edge node form factor from Medium to xLarge. So, I used API and it worked just perfect!.

Here you go.

Step1 - Connect the NSX-T using API. #If you don't know how then use comment box.

Step 2 - Use the API call 

GET https://10.112.152.10/policy/api/v1/transport-nodes    #It will give you the detail of all edge nodes

Step 3 - Pick the ID of target edge node from the output of step 2 and run the command as below

GET https://10.112.152.10/policy/api/v1/transport-nodes/7b60f554-a36f-4c71-9d6c-fddf7826da8a

You will get output something like below



Step 4 - Find the form factor parameter in output of step3. You will see like below-



If you have something else configured here then you will find like MEDIUM or SMALL or LARGE. You can change it as per your requirement and copy the entire output what you got in step 3 and paste in the API tool's body in Raw and JSON format.



Step 5 - Now, use below API call to change the form factor

POST https://10.166.171.198/policy/api/v1/transport-nodes/7b60f554-a36f-4c71-9d6c-fddf7826da8a?action=redeploy

it will start the redeployment and will take around 5-15 minutes or more depending upon your infrastructure.

Background process behind all the task is-

1. It put the target node in maintenance mode

2. Power off and remove the node

3. Deploy the new node with modified form factor or any other modified parameter and power it on

4. Register the node in NSX-T database

5. Configure everything as it was before

6. Exit the maintenance mode from new deployed node


Hopefully you could understand the whole process but if any doubt, please use the comment section. I will try my best to reply.


Thank you.

,

NSX-T | Security

Hi Guys,

I hope that you all are doing well with your beloved ones. Stay Home, Stay Safe, Keep Learning and Keep Growing.

So, In my older posts, I wrote about basic routing setup and a bit about DFW from Policy interface but today I thought to cover-up the same thing from Advance interface with some additional features.

So, let's discuss about below points-

- Distributed Firewall
- Edge Firewall
- Bridge Firewall (This is not available in policy interface) 

Because I will have to cover bridge firewall that's why including below in this post
- ESXi bridge cluster
- L2 bridging

I am sorry but no theory!! VMware has already done a great job on their website. Replicating same text is not a wise thing but yes, here is the excellent notes from VMware Documentation about the same

In this post, I will try to share all practical work. From where exactly in NSX-T, you can apply all these firewall rules from advance interface.

I have created a video, so, go ahead and play below video. Do remember to comment on blog to share how did you find it.

Distributed Firewall - So, it is distributed across the platform and applicable on entire infrastructure but we can decide where we want to apply it either on DFW leve, on Portgroups, on VM etc..Hope there is no doubt but if any then feel free to comment please. Ok, so hit the play button now.



Edge Firewall - Just play below video guys


Bridge Firewall-

This firewall basically is to restrict the traffic between VLAN and vxlan. If you know the L2 bridge  in NSX-V then it would be easier to understand and if you don't know then please read out here

Creating video on this is not feasible for me as of now because I don't have like setup. If I will have any such setup then will surely create one and will share with you guys!!




Thank you,
vCloudNotes
, ,

NSX-T | Getting Started with PowerCLI

Hi Guys,

I am working on PowerCLI for NSX-T and trying to do all the operations as we could do in NSX-V. it is bit different yet simple so I thought to share what I have learned so far. below is a glimpse of the same. 

Also, there is a good article from VMware for the beginners to understand the same. I too learned from here but I was able to do more operations by understanding the given basics in the above link.

Explore it and let me know if you need any assistance with it. 

To connect NSX-T manager in PowerShell

#Connect-NsxtServer -server FQDN\IP


To get NSX-T manager details
function nsxnode{$nodesvc = Get-NsxtService com.vmware.nsx.node
$nodesvc.get()



To get the transport zone name and its relevant id
$tzone = Get-NsxtService com.vmware.nsx.transport_zones
(($tzone.list()).results) | Select display_name, ID


To get the name of all logical switch's name

 $tls = Get-NsxtService com.vmware.nsx.logical_switches
(($tls.list()).results).display_name



To get the name of all logical routers' name
$Tier1 = Get-NsxtService -Name com.vmware.nsx.logical_routers
($Tier1.list()).results.display_name



To create Tier-1 or Tier-0 router
$rname = Read-Host "Tell me the Tier-1 router name to set"
$tier1 = Get-NsxtService -Name com.vmware.nsx.logical_routers
$createt1 = $tier1.Help.create.logical_router.Create()
$createt1.display_name = $rname
$createt1.router_type = "TIER1" #Change it to TIER0 if you want to create Tier0 router
$tier1.create($create1)


To create logical switch
$segments = Get-NsxtService com.vmware.nsx.logical_switches
$createls = $segments.Help.create.logical_switch.create()
$createls.admin_state = "UP"

$createls.transport_zone_id = "Enter ID here"
$createls.display_name = "Enter any name here"

$createls.replication_mode = "MTEP"
$segments.create($createls)


To delete logical switch
$logswitchname = Read-Host "Enter the LS name to delete"
#Delete Logical Switch
$logswitchsvc = Get-NsxtService -Name com.vmware.nsx.logical_switches
$logswitches = $logswitchsvc.list().results
$logswitch = $logswitches | Where-Object {$_.display_name -eq $logswitchname}
$logswitchsvc.delete($logswitch.id)



That's it for now but I will keep on adding in the list. In my next post, you will be seeing like connect LS with tier-0 or tier-1 and connect LS with VM with all IP configuration, etc.



Thank you,
vCloudNotes
, ,

NSX-T | Automation Use Case#1

Hello Guys,

Nowadays, I am trying hands and feet over NSX-T automation. It is a bit different than PowerNSX for NSX-V. You can check a few basic instructions and commands on VMware Documentation but here in this post I would like to go a bit deeper and will try to share some Automation Use Cases which you can refer to your daily operations.

Before proceeding further, I would recommend going through the above link and have some understanding of, how you can connect NSX-T manager in PowerShell and how you connect with services of NSX-T.

I hope you have gone through the above link. So, just to recap that, every action in NSX-T which we do through Powershell is executed by recalling a service name. For example,
 

com.vmware.nsx.node
com.vmware.nsx.transport_zones
com.vmware.nsx.logical_switches

If you want to do any specific task on any specific component, then you must know the relevant service for that component. As I said in the above lines, service com.vmware.nsx.logical_switches is responsible for all operations on logical switches. I hope you are understanding it. If not, then feel free to comment and ask your query.

As you know that I always club all these operations into one operation engine which gives me ease of operating it and at a good pace. So, what I have done is, please see in below video.



I will keep on adding many operations in this engine like getting Tier-0 and Tier-1 router detail etc. I mean a lot of options are there to create in.

If you want to have the benefit from it then please continue visiting the space for more engines like this. In case, anyone wants this basic engine then he\she may comment on my blog and then I will share it free of cost :)



Use Case1:

Whenever I create a segment that should be automatically connected with the Tier-1 router.

Solution:

I am working on it guys and will share it once I am done.

Meanwhile, if you want me to add anything here then your all suggestions are welcome.




Thank you,
vCloudNotes 


































Thanks for your visit. 
vCloudNotes
,

NSX-T | Basic Routing Setup

Hi Folks,

As most of the techie guys knows, who are dealing with cloud technologies and specially dealing with VMware cloud applications that NSX-v will sunset soon.

To replace it VMware has already released NSX-T which provides wider support of cloud technologies, easier implementation and independent design approach.

NSX-v was built only for vSphere environment whereas NSX-T can work with any cloud vendor, for example MS Azure, AWS and even with Openstack.

Now a days, integrating k8s with NSX-T is in trend. I will try to create a post on that as well but in today's post let's see how you can setup basic east-west and north-south routing in NSX-T. It will clear many doubts that you might have like what is T0, T1 router? What is SR and DR? and many more.

So, While explaining and demonstrating it, I will be using below topology.

So, let's see how I did it.

Steps are same as in NSX-v, just look and feel is different. Just remember that

Logical switch in NSX-v is similar to Segment in NSX-T
DLR in NSX-v play similar role as Tier-1 in NSX-T (It run on DR that is distributed router)
ESG in NSX-v play similar role as Tier-0 in NSX-T (It has SR that is service router which connect with physical switch\router)

But yes, architecture and configuration is bit different. There was no SR or DR in NSX-v but we have in NSX-T. However this post is to demonstrate the steps to be taken to setup basic routing in NSX-T from my VM to Tier-0 Gateway router.

So what I have already done in my lab :-
  • All VMs are directly connected with Tier-0 gateway through three segments that LS-db, LS-web and LS-app
  • Right now there is no Tier-1 gateway in my lab.

What I will do is:-
  • I will first create one Tier-1 gateway and will connect it to Tier-0 gateway to maintain the topology as shown above
  • Migrate all segments from Tier-0 to Tier-1 and ensure the connectivity
Create Tier-1 Gateway and connect it with Tier-0 Gateway
    Migrate all segments from Tier-0 to Tier-1 Gateway

    Ensure the connectivity now



    So guys, let me know how you found it. I could create one single big video but that becomes bit boring and lengthy.


    Thank you,
    vCloudNotes


    ,

    NSX-T | Glossary of Components

    I found below useful definition of NSX-T. Thought to share with all.

    Source - VMware Documentation

    Control Plane

    Computes runtime state based on configuration from the management plane. Control plane disseminates topology information reported by the data plane elements and pushes stateless configuration to forwarding engines.

    Data Plane

    Performs stateless forwarding or transformation of packets based on tables populated by the control plane. Data plane reports topology information to the control plane and maintains packet level statistics.

    External Network

    A physical network or VLAN not managed by NSX-T. You can link your logical network or overlay network to an external network through an NSX Edge. For example, a physical network in a customer data center or a VLAN in a physical environment.

    Host Transport Node

    Hypervisor node that has been registered with the NSX-T management plane and has NSX-T modules installed. For a hypervisor host to be part of the NSX-T overlay, it must be added to the NSX-T fabric.

    Edge Transport Node

    Edge node that has been registered with the NSX-T management plane. The Edge Transport Node hosts the NSX Service Routers (SR) that are associated with Tier-0 and Tier-1 routers, including Uplink connectivity to External Networks as well as stateful services such as NAT.

    Profile

    Represents a specific configuration that can be associated with an NSX Edge cluster. For example, the fabric profile might contain the tunneling properties for dead peer detection.

    Gateway Router

    NSX-T routing entity that provides distributed East-West routing. A gateway router also links a Tier-1 router with a Tier-0 router.

    Logical Router Port

    Logical network port which can attach to either a logical switch segment port or a physical network uplink port. Logical Router Ports are also used to connect the LR to SR services such as Network Address Translation (NAT), Load Balancing, Gateway Firewall, VPN etc.

    Segment / Logical Switch

    Segments, called logical switches in previous versions of NSX, are API entities that provide virtual Layer 2 switching for both VM and router interfaces. A segment gives tenant network administrators the logical equivalent of a physical Layer 2 switch, allowing a group of VMs to communicate on a common broadcast domain. A segment is a logical entity that exists independent of the underlying infrastructure and spans many hypervisors. It provides network connectivity to VMs regardless of their physical location, allowing them to migrate between locations without requiring any reconfiguration.
    In a multi-tenant cloud, many segments can exist side-by-side on the same hypervisor hardware, with each Layer 2 segment isolated from the others. Segments can be connected using gateway routers, and gateway routers can provide uplink ports connected to the external physical network.

    Logical Switch Port

    Logical switch attachment point to establish a connection to a virtual machine network interface or a logical router interface. The logical switch port reports applied switching profile, port state, and link status.

    Management Plane

    Provides single API entry point to the system, persists user configuration, handles user queries, and performs operational tasks on all of the management, control and data plane nodes in the system. Management plane is also responsible for querying, modifying and persisting user configuration.

    NSX Controller Cluster

    Deployed as a cluster of highly available virtual appliances that are responsible for the programmatic deployment of virtual networks across the entire NSX-T architecture. NSX Manager and NSX Controller services both exist in the NSX Controller Cluster.

    NSX Edge Cluster

    Collection of NSX Edge node appliances that are logically grouped for high-availability monitoring.

    NSX Edge Node

    Component that provides computational power to deliver IP routing and IP services functions. Service Routers (SR), used for Uplink connectivity and stateful services, are provisioned on Edge node appliances.

    NSX-T Hostswitch or KVM Open vSwitch (OVS)

    Software that runs on the hypervisor and provides physical traffic forwarding. The hostswitch or OVS is invisible to the tenant network administrator and provides the underlying forwarding service that each logical switch relies on. To achieve network virtualization, a network controller must configure the hypervisor hostswitches with network flow tables that form the logical broadcast domains the tenant administrators defined when they created and configured their logical switches.
    Each logical broadcast domain is implemented by tunneling VM-to-VM and VM-to-logical router traffic, using the tunnel encapsulation protocol Geneve. The network controller has a global view of the data center and ensures that the hypervisor hostswitch flow tables are updated as VMs are created, moved or removed.

    NSX Manager

    Management function that exists as a component of the NSX Manager Cluster. In prior versions of NSX, the NSX Manager was a dedicated virtual appliance. As of NSX-T 2.4, the NSX Manager function and Controller Cluster functions are consolidated into a single cluster called the NSX Manager Cluster.

    Open vSwitch (OVS)

    Open source software switch that acts as a hypervisor hostswitch within XenServer, Xen, KVM and other Linux-based hypervisors. NSX Edge switching components are based on OVS.

    Overlay Logical Network

    Logical network implemented using Layer 2-in-Layer 3 tunneling such that the topology seen by VMs is decoupled from that of the physical network.

    Physical Interface (pNIC)

    Network interface on a physical server that a hypervisor is installed on.

    Tier-0 (T0) Logical Router

    Provider gateway router is also known as Tier-0 gateway router, and interfaces with the physical network. Tier-0 gateway router is a top-tier router and can be configured as an active-active or active-standby cluster of service routers. The gateway router runs BGP and peers with physical routers via the service router. In active-standby mode, the gateway router can also provide stateful services.

    Tier-1 (T1) Gateway Router

    Tier-1 gateway router is the second tier router that connects to one Tier-0 gateway router for northbound connectivity, and one or more overlay networks for southbound connectivity. Tier-1 gateway router can also be configured in an active-standby cluster of services when the router is configured to provide stateful services.

    Transport Zone

    Collection of transport nodes that defines the maximum span of logical switches. A transport zone represents a set of similarly provisioned hypervisors, and the logical switches that connect VMs on those hypervisors.

    VM Interface (vNIC)

    Network interface on a virtual machine that provides connectivity between the virtual guest operating system and the standard vSwitch or vSphere Distributed Switch. The vNIC can be attached to a logical port. You can identify a vNIC based on its Unique ID (UUID). The vNIC is equivalent to a network interface card (NIC) on a physical machine.

    TEP

    Tunnel End Point. Tunnel endpoints enable hypervisor hosts to participate in an NSX-T network overlay. The NSX-T overlay deploys a Layer 2 network over an existing physical network fabric by encapsulating frames inside of packets, and transferring the encapsulated packets over the underlying transport network. The underlying transport network can consist of either Layer 2 or Layer 3 networks. The TEP is the connection point at which encapsulation and decapsulation takes place.

    VIrtual Network Interface (VNI)

    The network identifier associated with a given logical switch. As Layer 2 segments are created in NSX, an associated VNI is allocated. This VNI is used in the encapsulated overlay packet, and facilitates Layer 2 separation.


    Thank you,
    vCloudNotes

    NSX-T | Tier0 and Tier 1 Router

    You would see many articles\blog on the title but I am putting one simplified definition for my readers. Folks who worked on NSX-v might have heard about the DLR and Edges, right?

    let's compare this DLR\Edge with Tier0\Tier1.

    DLR - it is used to connect the logical switch with ESG to exit and connect with outer world, if configured so.
    ESG - It act as the only mean for internal packet to get out and communicate with external\outer world.

    It means, VM's traffic goes to DLR (if DLR is default gateway for that VM) and then DLR send the packet to ESG (If there is trunk port configured between DLR and ESG and packet is destined to go out). Below is the reference picture. Picture taken from blog.vmware.com
    Now Let's see how Tier0 and Tier1 routers are similar or different than DLR and Edge.

    In Short, Tier1 act as DLR that is it does east-west routing and Tier0 act as ESG that is it does North-South routing. Below picture will clear all doubts. Taken from docs.vmware.com


    I will post more about components of NSX-T. Keep visiting the space.



    Thank you,
    Team vCloudNotes

    All about NSX-T

    I got very very awesome way to learn NSX-T so I just wanted to share with you guys.

    I erased all the content of my previous postbecause duplicating the text is not smart way and specially if it is already written in better way and by VMware.

    Just browse below link, login with your VMware account credentials (if you have already sign-up otherwise you need to sign-up first) and start exploring NSX-T because future is T.

    https://labs.hol.vmware.com/HOL/catalogs/enrollments/lab/NEE-049991_40988847_

    Keep up the pace guys..




    Thank you,
    Team vCloudNotes

    NSX | Deny vs Reject

    In NSX, while configuring firewall rules in Edge or in DFW, you might have noticed that there are three option while choosing any action for any incoming or outgoing packet.

    In DFW - it is Allow, Block and Reject
    In ESG - it is Accept, Deny and Reject

    Reject action sends following responses-

    • RST packet for TCP Connection
    • ICMP unreachable with network administratively prohibited code

    Deny action silently drops packet from or to the specified source and destination. For example, RTO.

    Feel free to ask any question folks.





    Thank you,
    Team vCloudNotes