This is the multi-page printable view of this section. Click here to print.
Broadcom
- 1: Edge Secure Web Gateway (Edge SWG)
- 2: ESX
- 3: NSX
- 4: vCenter
1 - Edge Secure Web Gateway (Edge SWG)
Edge Secure Web Gateway (Edge SWG): Secures web traffic through policy enforcement, SSL inspection, and real-time threat protection.
To onboard such a source to Axoflow, complete the generic appliance onboarding steps.
Labels
Axoflow automatically adds the following labels to data collected from this source:
| Analytics label | Message field | value |
|---|---|---|
vendor |
meta.vendor |
broadcom |
product |
meta.product |
edge-swg |
service |
meta.service.name |
bluecoat, ProxySG |
You can use the labels as:
- Filter labels on the Analytics page,
- in the Filter By Label field during log tapping.
You can use the message fields
- in Flow Processing steps, for example, in the Query field of Select Messages steps,
- in AQL expressions in the search bars.
Sending data to Splunk
When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:
| sourcetype | index |
|---|---|
bluecoat:proxysg:access:syslog |
netops |
bluecoat:proxysg:access:kv |
netproxy |
If the Axoflow classification doesn’t set the source field for the message automatically, and you haven’t set it in a flow processing step manually (by setting the meta.destination.splunk.source field), AxoRouter automatically sets the source to the name of the AxoRouter connector that received the message (for example, axorouter-syslog-tcp-514).
Sending data to Google SecOps
When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: BROADCOM_EDGE_SWG.
Earlier name/vendor
- Blue Coat Proxy
- Blue Coat ProxySG
- Symantec ProxySG
- Symantec Edge Secure Web Gateway
- Symantec Edge SWG
2 - ESX
ESX: The primary function of ESX is to partition a physical server into multiple virtual machines (VMs), allowing different operating systems to run simultaneously and improving hardware utilization.
To onboard such a source to Axoflow, complete the generic appliance onboarding steps.
Labels
Axoflow automatically adds the following labels to data collected from this source:
| Analytics label | Message field | value |
|---|---|---|
vendor |
meta.vendor |
broadcom |
product |
meta.product |
esx |
service |
meta.service.name |
vmk, lsud, vsan, iofiltervpd, hostd, cmmdstimemachine, vmware, vpxa, eam, rhttpproxy, sdrsInjector, fdm, esxupdate, healthd, ConfigStore, kmxa, crx-cli, backup.sh, configStoreBackup, Host, vmauthd, localcli, watchdog-vsanperfsvc, watchdog-iofiltervpd, apiForwarder, tmpwatch, .etc.init.d.vsanmgmtd, ComplianceManager, hostprofiletrace, vobd, ucs-tool-esxi-inv, usbarb, auto-backup, cmmdsTimeMachineDump |
You can use the labels as:
- Filter labels on the Analytics page,
- in the Filter By Label field during log tapping.
You can use the message fields
- in Flow Processing steps, for example, in the Query field of Select Messages steps,
- in AQL expressions in the search bars.
Sending data to Splunk
When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:
| source | sourcetype | index |
|---|---|---|
vmware:esxlog:<service-name> |
vmware:esxlog:<service-name> |
infraops |
The service-name in the source and sourcetype is the same as the service label, for example, vmware:esxlog:vmware
If the Axoflow classification doesn’t set the source field for the message automatically, and you haven’t set it in a flow processing step manually (by setting the meta.destination.splunk.source field), AxoRouter automatically sets the source to the name of the AxoRouter connector that received the message (for example, axorouter-syslog-tcp-514).
Sending data to Google SecOps
When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VMWARE_ESX.
Earlier name/vendor
- VMware ESX
3 - NSX
NSX: Provides network virtualization, micro-segmentation, and security for software-defined data centers.
To onboard such a source to Axoflow, complete the generic appliance onboarding steps.
Configure your NSX appliances, NSX Edges, and hypervisors to send their logs to the Syslog (autodetect and classify) connector of an AxoRouter instance. Use either:
- The TCP protocol (port 601 when using the default connector), or
- TLS-encrypted TCP protocol (port 6514 when using the default connector)
For details on configuring NSX, see Configure Remote Logging in the NSX Administration Guide.
Labels
Axoflow automatically adds the following labels to data collected from this source:
| Analytics label | Message field | value |
|---|---|---|
vendor |
meta.vendor |
broadcom |
product |
meta.product |
nsx |
service |
meta.service.name |
NSX, NSXV, FIREWALL-PKTLOG, dfwpktlogs |
You can use the labels as:
- Filter labels on the Analytics page,
- in the Filter By Label field during log tapping.
You can use the message fields
- in Flow Processing steps, for example, in the Query field of Select Messages steps,
- in AQL expressions in the search bars.
Sending data to Splunk
When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:
| sourcetype | index |
|---|---|
vmware:nsxlog:dfwpktlogs |
netfw |
vmware:nsxlog:firewall-pktlog |
netfw |
vmware:nsxlog:nsx |
infraops |
vmware:nsxlog:nsxv |
infraops |
If the Axoflow classification doesn’t set the source field for the message automatically, and you haven’t set it in a flow processing step manually (by setting the meta.destination.splunk.source field), AxoRouter automatically sets the source to the name of the AxoRouter connector that received the message (for example, axorouter-syslog-tcp-514).
Sending data to Google SecOps
When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VMWARE_NSX.
Earlier name/vendor
- VMware NSX
- NSX-T Data Center
4 - vCenter
vCenter: vCenter is a centralized management platform that provides a single console for managing an entire VMware vSphere virtual infrastructure, including multiple ESXi hosts and virtual machines.
To onboard such a source to Axoflow, complete the generic appliance onboarding steps.
Labels
Axoflow automatically adds the following labels to data collected from this source:
| Analytics label | Message field | value |
|---|---|---|
vendor |
meta.vendor |
broadcom |
product |
meta.product |
vcenter |
service |
meta.service.name |
vpxd, vws, stats, cim-diag, sms, vim, cis-license, applmgmt-audit, updatemgr, vmafdd, vmcad, vmdird, vmon, osfsd, wcpxsvc, wcpsvc, mbcs, vmcam, vpostgres, vsphere, vcha, vcenter-server |
You can use the labels as:
- Filter labels on the Analytics page,
- in the Filter By Label field during log tapping.
You can use the message fields
- in Flow Processing steps, for example, in the Query field of Select Messages steps,
- in AQL expressions in the search bars.
Sending data to Splunk
When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:
| source | sourcetype | index |
|---|---|---|
vmware:vclog:<service-name> |
vmware:vclog:<service-name> |
infraops |
The service-name in the source and sourcetype is the same as the service label, for example, vmware:vclog:vmon
If the Axoflow classification doesn’t set the source field for the message automatically, and you haven’t set it in a flow processing step manually (by setting the meta.destination.splunk.source field), AxoRouter automatically sets the source to the name of the AxoRouter connector that received the message (for example, axorouter-syslog-tcp-514).
Sending data to Google SecOps
When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VMWARE_VCENTER.
Earlier name/vendor
- VMware vCenter