NSX – Modify DLR declared dead time

First I am going to need to know what Edge instance I will be changing, I will need to do a GET and retrieve all the DLR instances and find the ObjectID for a specific instance.

I can do this with a GET https://vcrooky/api/4.0/edges.

Once we have this we can query the current setting by doing the following:

Can see in the above screenshot that the DeclareDeadTime for Edge-19 is set to the value of 15.

I want to change this value to 6 (seconds).

I use the same request, this time using a PUT request and the XML:

PUT https://vcrooky/api/4.0/edges/edge-19/highavailability/config

The XML is:



NSX – NSX controller syslog

If you configure a syslog server for NSX controllers, NSX Manager sends all audit logs and system events to the syslog server. Syslog data is useful for troubleshooting and reviewing data logged during installation and configuration. The only supported method on configuring the syslog server on the NSX controllers is through the NSX API. VMware recommends using UDP as the protocol for syslog.

To enable syslog on NSX Controller, use the following NSX API. It adds controller syslog exporter and configures a syslog exporter on the specified controller node.

To query the existing syslog server do the following:

Continue reading

NSX – Configure SpoofGuard policies to enhance security

After synchronizing with the vCenter Server, NSX Manager collects the IP addresses of all vCenter guest virtual machines from VMware Tools on each virtual machine. If a virtual machine has been compromised, the IP address can be spoofed and malicious transmissions can bypass firewall policies.

You create a SpoofGuard policy for specific networks that allows you to authorize the IP addresses reported by VMware Tools and alter them if necessary to prevent spoofing. SpoofGuard inherently trusts the MAC addresses of virtual machines collected from the VMX files and vSphere SDK. Operating separately from Firewall rules, you can use SpoofGuard to block traffic determined to be spoofed.

SpoofGuard supports both IPv4 and IPv6 addresses. When using IPv4, the SpoofGuard policy supports a single IP address assigned to a vNIC. IPv6 supports multiple IP addresses assigned to a vNIC. The SpoofGuard policy monitors and manages the IP addresses reported by your virtual machines in one of the following modes.

Automatically Trust IP Assignments On Their First Use – This mode allows all traffic from your virtual machines to pass while building a table of vNIC-to-IP address assignments. You can review this table at your convenience and make IP address changes. This mode automatically approves all ipv4 and ipv6 address on a vNIC.

Manually Inspect and Approve All IP Assignments Before Use  – This mode blocks all traffic until you approve each vNIC-to-IP address assignment.

SpoofGuard inherently allows DHCP requests regardless of enabled mode. However, if in manual inspection mode, traffic does not pass until the DHCP-assigned IP address has been approved.

SpoofGuard includes a system-generated default policy that applies to port groups and logical networks not covered by the other SpoofGuard policies. A newly added network is automatically added to the default policy until you add the network to an existing policy or create a new policy for it.

Create a SpoofGuard Policy

You can create a SpoofGuard policy to specify the operation mode for specific networks. The system generated policy applies to port groups and logical switches not covered by existing SpoofGuard policies.


1. Log in to the vSphere Web Client.

2. Click Networking & Security and then click SpoofGuard.

Continue reading


NSX Edge supports OSPF, an interior gateway protocol that routes IP packets only within a single routing domain. It gathers link state information from available routers and constructs a topology map of the network. The topology determines the routing table presented to the Internet Layer, which makes routing decisions based on the destination IP address found in IP packets.

OSPF routing policies provide a dynamic process of traffic load balancing between routes of equal cost.

An OSPF network is divided into routing areas to optimize traffic. An area is a logical collection of OSPF networks, routers, and links that have the same area identification.

Areas are identified by an Area ID.

1.  Log in to the vSphere Web Client.

2. Click Networking & Security and then click NSX Edges.

3. Double-click an NSX Edge.

4. Click Routing and then click OSPF.

Continue reading


Border Gateway Protocol (BGP) makes core routing decisions. It includes a table of IP networks or prefixes which designate network reachability among autonomous systems.

An underlying connection between two BGP speakers is established before any routing information is exchanged. Keep alive messages are sent out by the BGP speakers in order to keep this relationship alive. Once the connection is established, the BGP speakers exchange routes and synchronize their tables.

To setup BGP the process is (nearly) identical on both ESGs and DLRs (there is an assumption here that the ESG and DLR is configured with IPs and subnets and interfaces and the global routing configuration is in place etc. etc.):

1. Log in to the vSphere Web Client.

2. Click Networking & Security and then click NSX Edges.

3. Double-click an NSX Edge.

4. Click Manage then Routing and then click BGP.

Continue reading

NSX – Configure centralized and distributed routing

I did some reading on this point and I think their are different ways to explain what is meant by centralised and distributed routing. From an NSX point of view centralised routing is configuring BGP or OSPF on an ESG to peer with a physical router/firewall and distributed routing is what we think of as a DLR.

However in the traditional sense I think centralised routing (in the datacentre sense) is the “core” and distributed would be further down the stack.

As far as this post is concerned I have posted a lot about configuring routing in DLRs and ESGs so I’m not going to reinvent the wheel!



Configure IS-IS Protocol

Intermediate System to Intermediate System (IS-IS) is a routing protocol designed to move information by determining the best route for datagrams through a packet-switched network.

A two-level hierarchy is used to support large routing domains. A large domain may be divided into areas. Routing within an area is referred to as Level 1 routing. Routing between areas is referred to as Level 2 routing. A Level 2 Intermediate System (IS) keeps track of the paths to destination areas. A Level 1 IS keeps track of the routing within its own area. For a packet going to another area, a Level 1 IS sends the packet to the nearest Level 2 IS in its own area, regardless of what the destination area is. Then the packet travels via Level 2 routing to the destination area, where it may travel via Level 1 routing to the destination. This is referred to as Level-1-2. Continue reading

NSX – Configure route redistribution to support a multi-protocol environment

Configure Route Redistribution

By default, routers share routes with other routers running the same protocol. In a multi-protocol environment, you must configure route redistribution for cross-protocol route sharing.


1. Log in to the vSphere Web Client.

2. Click Networking & Security and then click NSX Edges.

3. Double-click an NSX Edge.

4. Click Routing and then click Route Redistribution.

Continue reading

NSX – Manage User rights

A user’s role defines the actions the user is allowed to perform on a given resource. The role determine the user’s authorized activities on the given resource, ensuring that a user has access only to the functions necessary to complete applicable operations. This allows domain control over specific resources, or system-wide control if your right has no restrictions.

The following rules are enforced:

  • A user can only have one role.
  • You cannot add a role to a user, or remove an assigned role from a user. You can, however, change the assigned role for a user.

Enterprise Administrator  = NSX operations and security.
NSX Administrator = NSX operations only: for example, install virtual appliances, configure port groups.
Security Administrator = NSX security only: for example, define data security policies, create port groups, create reports for NSX modules.
Auditor = Read only.

Assign roles to user accounts

1. Log into the vSphere Web Client.

2. Click Networking and Security.

3. Click NSX Managers on the left-hand-side.

4. Select the NSX Manager, click Manage, followed by Users.

Continue reading