---
name: vpc-logging
title: Logging for VPC
description: IBM Cloud services, such as IBM Cloud VPC, generate platform logs that you can use to investigate abnormal activity and critical actions in your account, and troubleshoot problems.
last-updated: 2026-02-26
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/vpc?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Logging for VPC
{: #logging}

IBM Cloud services, such as IBM Cloud VPC, generate platform logs that you can use to investigate abnormal activity and critical actions in your account, and troubleshoot problems.
{: shortdesc}

You can use IBM Cloud Logs Routing, a platform service, to route platform logs in your account to a destination of your choice by configuring a tenant that defines where platform logs are sent. For more information, see [About Logs Routing](https://cloud.ibm.com/docs/logs-router?topic=logs-router-about&format=markdown).

You can use IBM Cloud Logs to visualize and alert on platform logs that are generated in your account and routed by IBM Cloud Logs Routing to an IBM Cloud Logs instance.

## Locations where platform logs are generated
{: #log-locations}

### Locations where logs are sent by IBM Cloud Logs Routing
{: #lr-locations}



IBM Cloud VPC sends logs by IBM Cloud Logs Routing in the regions that are indicated in the following table.

| Dallas (`us-south`) | Washington (`us-east`)  | Toronto (`ca-tor`) | Montreal (`ca-mon`) | Sao Paulo (`br-sao`) |
|---------------------|-------------------------|--------------------|---------------------|----------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green}      | [Yes]{: tag-green} | [Yes]{: tag-green}  | [Yes]{: tag-green}   |
{: caption="Regions where platform logs are sent in Americas locations" caption-side="top"}
{: #lr-table-1}
{: tab-title="Americas"}
{: tab-group="lr"}
{: class="simple-tab-table"}
{: row-headers}

| Tokyo (`jp-tok`)    | Sydney (`au-syd`) | Osaka (`jp-osa`) | Chennai - Airtel (`in-che`) | Mumbai - Airtel (`in-mum`) |
|---------------------|------------------|------------------|------------------|------------------|
| [Yes]{: tag-green} | [Yes]{: tag-green} | [Yes]{: tag-green} | [Yes]{: tag-green} | [Yes]{: tag-green} |
{: caption="Regions where platform logs are sent in Asia Pacific locations" caption-side="top"}
{: #lr-table-2}
{: tab-title="Asia Pacific"}
{: tab-group="lr"}
{: class="simple-tab-table"}
{: row-headers}

| Frankfurt (`eu-de`)  | London (`eu-gb`)   | Madrid (`eu-es`)   |
|----------------------|--------------------|--------------------|
| [Yes]{: tag-green}   | [Yes]{: tag-green} | [Yes]{: tag-green} |
{: caption="Regions where platform logs are sent in Europe locations" caption-side="top"}
{: #lr-table-3}
{: tab-title="Europe"}
{: tab-group="lr"}
{: class="simple-tab-table"}
{: row-headers}

## Viewing logs
{: #log-viewing}

### Launching IBM Cloud Logs from the Observability page
{: #log-launch-standalone}



For more information about launching the IBM Cloud Logs UI, see [Launching the UI in the IBM Cloud Logs documentation.](https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-instance-launch&format=markdown)

## Fields per log type
{: #logging_fields}

The following table outlines the fields that are included in each log record:


| Field | Type | Description |
| ----- | ---- | ----------- |
| `logSourceCRN` | Required | Defines the account and flow log instance where the log is published. |
| `saveServiceCopy` | Required | Defines whether IBM saves a copy of the record for operational purposes. |
| `message` | Required | Description of the log that is generated. |
| `messageId` | Required | ID of the log that is generated. |
| `msgTimestamp` | Required | The timestamp when the log is generated. |
| `resolution` | Optional | Guidance on how to proceed if you receive this log record. |
| `documentsURL` | Optional | More information on how to proceed if you receive this log record. |
| `generation` | Required | Defines the VPC source of the log. Valid options are `1` (VPC Classic) and `2` (VPC Gen 2). |
{: caption="Log record fields" caption-side="bottom"}

## Log messages
{: #logging_msgs}

The following tables list the message IDs that are generated by VPC services:

### Dedicated Host
{: #logging-dedicated-host}

The following table outlines the message IDs that are generated for dedicated hosts:

| Message ID | Type | Learn More |
| ----------- | ----- | ----------- |
| `dedicated-host.00001` | `err` | [`Failed to create dedicated host <Dedicated Host ID> due to insufficient capacity in zone.`](https://cloud.ibm.com/docs/vpc?topic=vpc-why-did-a-dedicated-host-fail-to-create&format=markdown) |
| `dedicated-host.00002` | `info` | `Provisioned a virtual server instance on dedicated host <Dedicated Host ID>.` |
| `dedicated-host.00003` | `info` | `Removed a virtual server instance on dedicated host <Dedicated Host ID>.` |
{: caption="Message IDs that are generated for dedicated hosts" caption-side="bottom"}

A log is generated when each Dedicated Host event occurs.
{: note}

### File share cross-account access
{: #logging-file-share-accessor}

The following table outlines the message IDs that are generated for File Storage related events:

| Message ID | Type | Description |
| ------------ | ------ | ------------- |
| `is.share.00004I` | `info` | The lifecycle_state of accessor share `{{.shareID}}` is stable. |
| `is.share.00005I` | `info` | The lifecycle_state of accessor share `{{.shareID}}` is failed and the reason for failure is `{{.shareLifecycleReason}}`. |
| `is.share.00006I` | `info` | The lifecycle_state of share mount target `{{.targetID}}` for the `{{.shareID}}` at accessor account is stable. |
| `is.share.00007I` | `info` | The lifecycle_state of share mount target `{{.targetID}}` for the `{{.shareID}}` at accessor account is failed. |
{: caption="Message IDs that are generated for accessor file share events" caption-side="bottom"}

### File share replication
{: #logging-file-share-replication}

The following table outlines the message IDs that are generated for File Storage replication events:

| Message ID | Type | Description |
| ---------- | ---- | ----------- |
| `regional-file.00001I` | `info` | The replication status of `{{.shareID}}` is active. |
| `regional-file.00002W` | `warning` | The replication status of `{{.shareID}}` is degraded. |
| `regional-file.00003I` | `info` | Initiated by the cron schedule `{{.cronSpec}}`, `{{.dataTransferredInGiB}}` of data transferred from the source share `{{.shareID.}}` between `{{.startedAt.}}` and `{{.endedAt.}}` with a data transfer rate of `{{.transferRate}}`. |
{: caption="Message IDs that are generated for file share replication events" caption-side="bottom"}

A log is generated when a replication event occurs.
{: note}

### Flow log collector
{: #logging-flow-log-collector_msgs}

The following table outlines the message IDs that are generated by the flow log collector service:

| Message ID | Type | Learn More |
| ---------- | ---- | ---------- |
| `is.flow-log-collector.00001E` | `err` | [`Failed to write Flow Log file for the past 24 hours. Dropping flow log for Virtual Server <ServerName>`](https://cloud.ibm.com/docs/vpc?topic=vpc-fl-ts-error-failed-write&format=markdown) |
| `is.flow-log-collector.00002E` | `err` | [`Unauthorized access to Cloud Object Storage bucket <BucketName>`](https://cloud.ibm.com/docs/vpc?topic=vpc-fl-ts-error-unauth-access-cos&format=markdown) |
| `is.flow-log-collector.00003E` | `err` | [`Cloud Object Storage bucket <BucketName> was not found`](https://cloud.ibm.com/docs/vpc?topic=vpc-fl-ts-error-cos-bucket&format=markdown) |
{: caption="Message IDs that are generated by Flow Log Collector" caption-side="bottom"}

Flow log collector generates hourly logs.
{: note}

### Load Balancer for VPC
{: #logging-load-balancer}

The following table outlines the message IDs that are generated by the Load Balancer for VPC service:

| Message Category | Type | Description |
| ---------------- | ---- | ---------- |
| `Health check` | `info` | `Connect from <IP>:<PORT> to <IP>:<PORT>` |
| `Connect` | `info` | `Health check for server <ID>> failed, reason: Layer4 connection problem, info: "General socket error (Network is unreachable)", check duration: 0ms, status: 1/2 UP` |
{: caption="Message IDs that are generated by the Load Balancer for VPC service" caption-side="bottom"}

### Resource Quota
{: #logging-resource-quota}

The following table outlines the message IDs that are generated for resource quota events:

| Message ID | Type | Learn More |
| ---------- | ---- | ---------- |
| `quota-monitoring.00001` | `info` | `Successfully provisioned resource <Resource ID>.` |
| `quota-monitoring.00002` | `err` | `Failed to provision resource <Resource ID> due to resource quota limits.` |
| `quota-monitoring.00004` | `err` | `Failed to update resource <Resource ID> due to resource quota limits.`  |
{: caption="Message IDs that are generated for resource quota events" caption-side="bottom"}

A log is generated when a provision or update resource quota event succeeds or fails.
{: note}

### Snapshots for VPC
{: #logging-snapshots}

The following table outlines the message IDs that are generated by the Snapshots service:

| Message ID | Type | Learn More |
| ---------- | ---- | ---------- |
| `snapshot.00001` | `info` | `Snapshot creation requested for volume <Volume ID>.` |
| `snapshot.00002` | `info` | `Snapshot <Snapshot ID> is successfully captured. Volume <Volume ID>` |
| `snapshot.00003` | `info` | `Snapshot <Snapshot ID> is an incremental snapshot. Volume <Volume ID>` |
| `snapshot.00004` | `info` | `Snapshot <Snapshot ID> is a full snapshot. Volume <Volume ID>` |
| `snapshot.00005` | `info` | `Snapshot <Snapshot ID> is available. Volume <Volume ID>` |
| `snapshot.00006` | `info` | `Snapshot <Snapshot ID> is uploaded. Volume <Volume ID>` |
| `snapshot.00007` | `info` | `Snapshot <Snapshot ID> deletion requested.` |
| `snapshot.00008` | `info` | `Snapshot <Snapshot ID> is successfully deleted. Volume <Volume ID> Region <Region>` |
| `snapshot.00009` | `info` | `All snapshots of volume <Volume ID> in the region <Region> are requested to be deleted.` |
| `snapshot.00010` | `info` | `Delete all snapshots request for volume <Volume ID> is completed successfully. Region <Region>` |
| `snapshot.00010` | `info` | `Snapshot copy creation in region <Region> requested for snapshot <Snapshot ID> from region <Source Region>. Volume <Volume ID>` |
{: caption="Message IDs that are generated for Snapshot events" caption-side="bottom"}

### Virtual server instances
{: #logging-instance}

[Select availability]{: tag-green}

The following table outlines the message IDs that are generated for instance related events:

| Message ID | Type | Description |
| ---------- | ---- | ----------- |
| `instance.00001` | `info` | Volume `{{.volumeID}}` with a max bandwidth of `{{.volumeBandwidthMbps}}` Mbps has been attached to instance `{{.instanceID}}` with an attachment bandwidth of `{{.attachmentBandwidthMbps}}` Mbps. |
| `instance.00002` | `warn` | Spot instance `{{.instanceID}}` has been selected for preemption. |
{: caption="Message IDs that are generated for virtual server instances" caption-side="bottom"}

A log is generated when a volume is attached to the instance, and when a volume's maximum bandwidth value is changed.
{: note}

## VPN for VPC (site-to-site) logging
{: #logging-s2s}

### Fields per log type (VPN for VPC)
{: #logging_fields-vpn-vpc}

The following table outlines the fields that are included in each site-to-site VPN log record:

Sub-system name = `is.vpn`

| Field | Type | Description |
| ----- | ---- | ----------- |
| `logSourceCRN` | Required | The VPN ID can be obtained from `logSourceCRN`. |
| `tag` | Required | Includes the account where the VPN is and matches the account in `logSourceCRN`. |
| `message` | Required | Contains different data based on the RFC protocol standard. |
{: caption="Log record fields (VPN for VPC)" caption-side="bottom"}

### Logs (VPN for VPC)
{: #logs-vpn-vpc}

The following table outlines sample logs that are generated by the VPN for VPC service. The following logs are based on Internet Key Exchange version 2 (IKEv2).

| Log | Description |
| --- | ----------- |
| `UTC YYYY-MM-DD HH24:MM:SS 03[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|32563> initiating IKE_SA peer_{PEER GW IP}_{VPN GW CONNECTION ID}[32563] to {PEER GW IP}` | Initiating the establishment of an IKE Security Association with the peer. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> received proposals: IKE:{IKE POLICIES}` | List of IKE proposal received from the peer side. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> configured proposals: IKE:{IKE POLICIES}` | Listing the IKE policies currently configured. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> selected proposal: IKE:{IKE POLICIES}` | Final agreed IKE proposals. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> local host is behind NAT, sending keep alives` | VPN device is behind NAT. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> remote host is behind NAT` | Peer VPN device is behind NAT. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> configured proposals: ESP:{IPSec POLICIES}` | Child SA (ESP) proposals for encrypting data traffic. |
| `UTC YYYY-MM-DD HH24:MM:SS 12[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|665> IKE_SA peer_{PEER GW IP}_{VPN GW CONNECTION ID}[665] established between {GW PRIVATE IP}[{LOCAL GW IP}]...{PEER GW IP}[{PEER GW IP}]` | The IKE Security Association with the peer is established. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> received proposals: ESP:{IPSec POLICIES}` | List of phase 2 (CHILD_SA) proposal received from the peer side. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> configured proposals: ESP:{IPSec POLICIES}` | List of phase 2 (CHILD_SA) proposal configured in IBM side. |
| `UTC YYYY-MM-DD HH24:MM:SS 07[CFG] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|664> selected proposal: ESP:{IPSec POLICIES}` | Final agreed ESP proposals. |
| `UTC YYYY-MM-DD HH24:MM:SS 12[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}> CHILD_SA peer_{PEER GW IP}_{VPN GW CONNECTION ID}{1} established with SPIs {SPI INDEX} and TS {LOCAL CIDR} === {PEER CIDR}` | The CHILD Security Association is established and finalized with the peer. |
| `UTC YYYY-MM-DD HH24:MM:SS 12[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}> activating CHILD_REKEY task` | CHILD_SA rekey task is activated. |
| `UTC YYYY-MM-DD HH24:MM:SS 13[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|665> IKE_SA deleted` | The IKE Security Association has been terminated. |
| `UTC YYYY-MM-DD HH24:MM:SS 13[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|665> IKE_SA peer_{PEER GW IP}_{VPN GW CONNECTION ID}[665] state change: DELETING => DESTROYING` | Tearing down the deleted IKE Security Association connection. |
| `UTC YYYY-MM-DD HH24:MM:SS 06[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|32563> establishing IKE_SA failed, peer not responding` | The `IKE_SA` connection initiation from the VPN gateway is not getting a response from the peer. |
| `UTC YYYY-MM-DD HH24:MM:SS 15[ENC] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|670> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]` | Error triggered by a preshared key mismatch on either side. |
| `UTC YYYY-MM-DD HH24:MM:SS 06[IKE] <679> no IKE config found for {GW PRIVATE IP}...{LOCAL GW IP}, sending NO_PROPOSAL_CHOSEN` | Error occurred because the IKE policies selected on both sides do not match. |
| `UTC YYYY-MM-DD HH24:MM:SS 15[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|684> no acceptable proposal found` | Error occurred because the IPsec policies selected on both sides do not match. |
| `UTC YYYY-MM-DD HH24:MM:SS 15[IKE] <peer_{PEER GW IP}_{VPN GW CONNECTION ID}\|684> failed to establish CHILD_SA, keeping IKE_SA` | Error prevented the successful establishment of `CHILD_SA`. |
{: caption="Logs that are generated for VPN for VPC (site-to-site)" caption-side="bottom"}

The following table outlines sample BGP logs that are generated by the VPN for VPC service for dynamic routing VPN connection.

| Log | Description |
| --- | ----------- |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [N9HHH-F8H1M] %ADJCHANGE: neighbor {PEER TUNNEL INTERFACE IP}(Unknown) in vrf default Up` | The peer’s ASN is not known yet because the OPEN message has not been received or decoded. |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [Q5ZXR-22T5Z] {PEER TUNNEL INTERFACE IP} [AS4] rcv OPEN w/ OPTION parameter len: 24, peeking for as4` | Received an OPEN message containing 24 bytes of optional capabilities; checking whether the peer supports 4-byte ASNs. \n BGP session-establishment process, when BGP state moves from **OpenSent to OpenConfirm**. |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [MBFVT-8GSC6] u4:s4 {PEER TUNNEL INTERFACE IP} send UPDATE w/ nexthop {ROUTE}` | Advertising routes to the peer and informing it which next hop should be used to reach those routes. |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [MAXTH-W5WMN] {PEER TUNNEL INTERFACE IP} suppress UPDATE w/ attr: nexthop 0.0.0.0, origin i, path {AS-PATH}` | VPN is withholding the UPDATE to neighbour because the route is not eligible for advertisement. |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [M59KS-A3ZXZ] bgp_update_receive: rcvd End-of-RIB for IPv4 Unicast from {PEER TUNNEL INTERFACE IP} in vrf default` | As part of BGP establishment, peer has finished sending all its initial routing information. |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [T5AAP-5GA85] {PEER TUNNEL INTERFACE IP}(Unknown) rcvd UPDATE w/ attr: nexthop {PEER TUNNEL INTERFACE IP}, origin i, metric 100, path {PEER ASN}` | BGP UPDATE message from the peer. This happens after the session is Established and indicates the peer is sending routes (advertising, updating, or changing attributes). |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: [YCKEM-GB33T] {PEER TUNNEL INTERFACE IP}(Unknown) rcvd {RECEVIED ROUTE} IPv4 unicast` | Receives one IPv4 Unicast routes from peer. |
| `UTC YYYY/MM/DD HH24:MM:SS BGP: {PEER TUNNEL INTERFACE IP} [AS4] about to set cap PEER_CAP_AS4_RCV, got as4 {ASN}` | Incorrect peer ASN set in VPN config. |
{: caption="BGP Logs that are generated for dynamic routing VPN for VPC (site-to-site)" caption-side="bottom"}

## Client VPN for VPC (client-to-site) logging
{: #logging-c2s}

### Fields per log type (VPN for VPC)
{: #logging_fields-c2s-vpn-vpc}

The following table outlines the fields that are included in each client-to-site VPN log record:

Sub-system name = `is.vpn.server`

| Field | Type | Description |
| ----- | ---- | ----------- |
| `logSourceCRN` | Required | The VPN ID can be obtained from `logSourceCRN`. |
| `tag` | Required | Includes the account where the VPN is and matches the account in `logSourceCRN`. |
| `message` | Required | Contains different data based on the RFC protocol standard. |
{: caption="Log record fields (Client VPN for VPC)" caption-side="bottom"}

### Logs (Client VPN for VPC)
{: #logs-client-vpn}

The following table outlines sample logs that are generated by the Client VPN for VPC service. The following logs are based on Internet Key Exchange version 2 (IKEv2).

| Log | Description |
| --- | ----------- |
| `YYYY-MM-DD HH24:MM:SS {DEVICE PUBLIC IP:PORT} {USERNAME/INTERMEDIATE CA} connect` | The connection between the OpenVPN client and the server is established. |
| `YYYY-MM-DD HH24:MM:SS {DEVICE PUBLIC IP:PORT} {USERNAME/INTERMEDIATE CA} disconnect` | The OpenVPN client is no longer linked to the server. |
{: caption="Logs that are generated for Client VPN for VPC (client-to-site)" caption-side="bottom"}