Skip to main content

Posts

What's new in NSX-T 3.0

There is various enhancement done in NSX-T version 3.0 by VMware.  Let's talk about architecture change in NSX-T version 3.0 Some of the below changes were made concerning the internal communication mechanism within the NSX-T components.  T hey are: Architecture ramp-up: NSX Manager and its cluster communicate with their transport nodes through APH Server ( Appliance Proxy Hub ) NSX Manager communicates with NSX-Proxy through port 1234. CCP (Central control plane) communicates with NSX-Proxy through port 1235 . RabbitMQ messaging is replaced with NSX-RPC between the management plane and CCP.     Add caption   Alarm and Events   In NSX-T version 3.0, there is an introduction of Alerts and Events which help in the active monitoring of different components of the environment.   Network Topology UI   In NSX-T 3.0 there is a view of the network topology which gives a diagram of each component of NSX-T.  This view gives about numbers of VM connected to segments, numbers of segments, T1,

Reason's for instability of NSX-T Cluster

  Some time back I had an issue where my NSX-T lab e nvironment was showing unstable status. My environment consists of 3 NSX-T manager nodes aligned with the VIP IP address.  The issue where I was unable to access my NSX-T console through VIP IP address nor with my other NSX-T nodes. It's quite intermittent I was able to access console UI from one of the manager node using admin account. However, unable to login to the manager's node using SSH with admin or root account. As I said its quite intermitted where I managed to access the manager UI console.  In the below Figure:1, it states that 1-2 manager nodes were showing unavailable. Figure:1 On validating the "VIEW DETAILS" it clearly shows that /var/log partition was 100% full. Figure:2 Now the main objective is to either compress or delete the old logs from /var/log partition to bring back the manager's node's.  To accomplish this I booted the NSX-T node VM sequentially, mounting the Ubuntu image using resc

IDS/IPS (Intrusion Detection System) & (Intrusion Prevention System)

 IDS (Intrusion Detection System) As its name suggest that it's designed to detect malicious or suspicious activity in the network by scanning data packets and monitoring the network traffic. It detects packet forwarding if its a good or bad packet where bad packet determines of malicious threats or any kind of risk. It generates logs to identify suspicious activity. It can not prevent malicious threats or attacks from inside the environment or outside, the aim behind the design the IDS to give warnings of that suspicious or malicious activity or threats to the system administrators or security/network admin. It continuously monitors and analyzes the incident, violations, and threats which may be breaking the network security. Credit: pngio.com IPS (Intrusion Prevention System) Its is designed to prevent the malicious or suspicious threat and activities which are detected by IPS in the network. Its design to block suspicious and malicious activities and threats before it develops a

NSX-T Manager Node Recovery

In the NSX-T environment, there were scenarios where it's required to bring down the manager node instances off from the cluster due to several abnormal reasons. Scenarios like if there were some issues during the upgrade of the manager node instance or having any abnormal circumstances where is node unable to recover from NSX-T Manager UI.  To recover/replace the node from the manager cluster its require to attempt with the manual process . Let's discuss the manual path to recover/Replace a Manager Node in the Cluster. 1) Login to NSX-T manager using CLI 2) Use command ' get cluster status ' This command will list all the NSX-T manager/controllers nodes into the cluster. Find the UUID of the existing node and Cluster to identify the node which requires recover/replace. 3) Now that we have identifying the manager node ID from the above command, its time to detect the node from the cluster.  Using detach node command "node id" will remove the node from the clus

NSX-T Datacenter Firewall

In NSX-T we have two types of firewall which we will discuss into this post. 1) Distributed firewall 2) Gateway firewall Lets talk about one by one.. 1) Distributed firewall: A distributed firewall hosted at the host (hypervisor) level which is kernel-embedded statefull firewall. This kind of firewall mostly used in between the transport nodes or you can say within in east-west network. Basically distributed firewall helps protecting the virtual machine at the virtual machine level from the hacking attack. Many people have a question like , if we have perimeter firewall at the physical layer to protect the network then why we require a firewall (distributed firewall) at the VM level......   To answer this question, Yes many of you are correct that perimeter firwall is there to protect the network at the top level. However, there are some attach which directly attach at the VM level like attach from USB drive, phishing emails and advertisements attracts.   To p

Dockers.. Basic commandlets

In this article we will go through some of the basic commands used in dockers. So lets get started. 1) docker ps This command is used to list all the running containers ie: $ docker ps CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                        NAMES 4ba5baace270        couchbase           "/entrypoint.sh couc…"   8 seconds ago       Up 5 seconds        8091-8096/tcp, 11207/tcp, 11210-11211/tcp, 18091-18096/tcp   naughty_hopper 6c1773f25479        nginx               "nginx -g 'daemon of…"   5 minutes ago       Up 5 minutes        80/tcp                                                       compassionate_dijkstra 2) docker ps -a This command list all the container into the docker, whether its in running, stopped or exited. $ docker ps -a CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS     

Removing NSX-T manager extension from vCenter

In NSX-T starting from ver 2.4 NSX-T appliance got decoupled from vCenter where now its not mandatory to run NSX-T on vCenter platform only. Now NSX-T can be managed through standalone ESXi host, KVM or through container platform. As in version 2.4 there is still an option available to connect vCenter to NSX-T using Compute Manager. Here in this blog we will learn how we can unregister and register NSX-T extenstion from vCenter in case of any sync or vCenter connectivity issue with NSX-T. Lets get started.. 1) Login to NSX-T UI Go to -> System ->Compute Manager Here, vCenter is showing in Down status where the status is showing as "Not Registered" 2) When we click on "Not Registered" option its states below error. 3) When try to click on Resolve option its states below. At this stage if the Resolve option doesn't work then its require the remove the NSX-T extenstion from vCenter. To remove the NSX-T e

Secret in Kubernetes

Secret in Kubernetes Secrets in Kubernetes are sensitive information like Shh keys, tokens, credentials etc. As in general its must require to store such kind of secret object in encrypted way rather than plantext to reduce the risk of exposing such kind of information to unauthorised species. A secret is not encrypted, only base64-encoded by default. Its require to create an EncryptionConfiguraton with a key and proper identity. All secret data and configuration are stored onto etcd which is accessible via API server. Secret data on nodes are stored on tmpfs volumes. Individual secret size is limited to 1MB in size. The larger size limit is discouraged as it may exhausted apiserver and kubelet memory.  To use secret its require that pod needs to reference with secret. A secret can be used in 2 ways with pod: as file in a volume mounted on one or more containers, or use by kubelets while pulling images from the pod. There are two steps involved in setting up secret