Category Archives: NSX

Flow Monitoring is a traffic analysis tool that provides a detailed view of the traffic to and from protected virtual machines. When flow monitoring is enabled, its output defines which machines are exchanging data and over which application. This data includes the number of sessions and packets transmitted per session. Session details include sources, destinations, applications, and ports being used. Session details can be used to create firewall allow or block rules.

You can view TCP and UDP connections to and from a selected vNIC. You can also exclude flows by specifying filters.

Flow Monitoring can thus be used as a forensic tool to detect rogue services and examine outbound sessions.

Configure Flow Monitoring

Flow collection must be enabled for you to view traffic information. You can filter the data being displayed by specifying exclusion criterion. For example, you may want to exclude a proxy server to avoid seeing duplicate flows. Or if you are running a Nessus scan on the virtual machines in your inventory, you may not want to exclude the scan flows from being collected.

Procedure

1. Log in to the vSphere Web Client.

2. Select Networking & Security from the left navigation pane and then select Flow Monitoring.

3. Select the Configuration tab.

Continue reading →

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:

<highAvailability>
<declareDeadTime>6</declareDeadTime>
</highAvailability>

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 →

I’m not completely up to speed with APIs and Powershell and all that cool stuff but I am trying! NSX seemed like a great opportunity to get more into using APIs and thankfully the API guide from VMware for NSX is quite good! Continue reading →

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.

Procedure

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 →

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!

Onwards!

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 →

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.

Procedure

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 →