ESX physical uplink resiliency (part 2)

What is beacon probing?

In my recent blog article “ESX physical uplink resiliency” I’ve discussed countermeasures to harden vSphere traffic against downstream physical failures. Today I will discuss another failover detection method which can handle uplinks that are not yet dead but not functional either.

Reasons for failure can be driver / firmware related errors on the NIC itself, or a broken downstream path (cable / switch).

Beacon probing

Beacon probing is a mechanism, where an ESX host will send out beacon packets over every uplink port every second to verify that each other uplink is reachable.

Continue reading “ESX physical uplink resiliency (part 2)”

5. December 2018

ESX physical uplink resiliency

Ensure vmnic uplink redundancy with Link State Tracking / Smart Links

A vSphere cluster is redundant in many aspects. The loss of one component may not lead to a loss of functionality. Therefore we are building RAID sets from multiple disk drives, have redundant controllers in our storages, have multiple paths, redundant LAN- and SAN-switches and multiple uplinks from a host to the physical network.

VMware vSphere uses multiple physical NICs to form a logical NIC in order to gain redundancy. This is crucial for kernelports, which are responsible for vMotion, Management Network, FT, iSCSI and Heartbeats.

But there are scenarios where all vmnics have physical uplink, but a path loss further downstream towards the core lets packets wander into a black hole.

We will now discuss some network architectures and how to work around the issue.

Continue reading “ESX physical uplink resiliency”

10. September 201810. February 2019

Syslog on Brocade FC-Switches

Setting up syslog export on Brocade FC-Switches

Browsing through logs of many different devices can be a cumbersome duty. It is much better to aggregate logs from different devices on a dedicated syslog server. To make this possible, a syslog server needs to be registered on the device.

I will show here how to configure a Brocade FibeChannel switch that it will send logs to a syslog server.

Requirements

FOS 7.4 or higher
Access to CLI (serial or SSH)

Procedure

syslogadmin --set -ip <syslogserver>

To check status, use the show command.

syslogadmin --show -ip

To revert settings and deregister syslog server from switch use command:

syslogadmin --remove -ip <syslogserver>

Timesync

Timesync with a NTP source is crucial in order to correlate events precisely. Therefore we need to register a NTP server on the (principal) switch.

tsclockserver <IP>

Choosing the local timezone is best in interactive mode.

tstimezone --interactive

12. July 20189. October 2018

Monitoring HPE Switches with Log Insight

Using Log Insight as Syslog Server for HPE 5000 series Switches

In one of my last posts I’ve shown how to collect and monitor status logs of many different systems wit vRealize Log Insight. In this post I will show how to leverage Log Insight as syslog target for HPE switches.

Basically you can use Log Insight for any system that uses the syslog protocol, but there might be slight differences in the data structure of the transmitted datasets. For example some HPE FlexFabric 5000 series switches sent the year of the timestamp where Log Insight expected to find the hostname. Not very useful, because you want to know WHO sent that dataset.

The following commands on the switch shell will prepare the switch for logging to a remotehost and adjust the dataset to read properly by Log Insight. Finally you tell the switch which VLAN interface should be used to communicate with the loghost. In my simple example it’s VLAN interface 1. You’ll have to adjust values for loghost and interface according to your infrastructure.

system-view
info-center enable
info-center loghost s-vlog.mydomain.local port 514
info-center timestamp loghost no-year-date 
info-center loghost source Vlan-interface 1