Known Issues for Networking

If the following things occur, in the Oracle Console you receive an error that says The CPE is missing the vendor information (the device type). Update the CPE and add the vendor information:

• You have a CPE that existed before the CPE Configuration Helper feature was released.
• You have not yet edited the CPE in the Oracle Console and specified which vendor makes your CPE.
• You try to generate the Helper content for the CPE or any IPSec connections that use that CPE.

Perform the following actions:

1. In the Oracle Console, view the CPE.
2. Click Edit.
3. In the CPE Vendor Information section, select the vendor that makes your CPE. If you're not sure which vendor makes your CPE, or it's not in the list, select Other.

4. If prompted, select a value for Platform/Version. Here are guidelines:

   • Oracle recommends using a route-based configuration if possible.
   • If you do not see your specific CPE platform or version in the list, choose the closest platform/version that predates your CPE version.
5. Click Save Changes. It's important to click this even if you did not change the value for the vendor.

You can then generate the Helper content successfully for the CPE or any IPSec connections that use that CPE.

We recommend that you remove the route rule that has the Destination Service set as All <region> Services in Oracle Services Network and the Target Type set as service gateway. Revert to the configuration you used before adopting the service gateway for Oracle Services Network. With this change, your public instances retain access to all Oracle services through the internet gateway. Oracle services can continue to access your public instances.

However, your instances in the public subnet can continue to access Object Storage through the service gateway. Update the subnet's route table to include a route rule with Destination Service set as OCI <region> Object Storage and the Target set to the VCN's service gateway.

This known issue applies only to public subnets that have access to an internet gateway. Regarding private subnets: you can still configure a private subnet's route table to provide access to All <region> Services in Oracle Services Network or to OCI <region> Object Storage through the VCN's service gateway.

Several of the Monitoring charts for Site-to-Site VPN v1 tunnels show incorrect data and should not be used to determine recent traffic levels in the tunnel.

To summarize, these are the available Monitoring charts for Site-to-Site VPN v1 tunnels:

• IPSec tunnel state: This chart is accurate and correctly shows the up or down state of the tunnel.
• Bytes or packets sent or received: These four charts are inaccurate and do not show the correct level of bytes or packets sent or received through the tunnel.
• Packets with errors: This chart is inaccurate and does not show the correct number of packets dropped with errors.

For more information about the charts, see Site-to-Site VPN Metrics.

• Instances created before November 2018 might have their repos pointed to URLs that are not accessible through the service gateway
• Instances that were not able to contact their local region's yum server before may have fallen back to using yum.oracle.com, which is not accessible through the service gateway

Try the following automated mitigation. If it fails for some reason, use the manual mitigation method that follows.

Copy the following script the to local system and run it. The script disables existing repos and downloads the repo file, which directs the system to the region's local yum servers accessible through the service gateway.

#!/bin/bash
REPODIR='/etc/yum.repos.d'
REPOS=$REPODIR/*
REGION=$(curl -sfm 3 http://169.254.169.254/opc/v1/instance/ | jq -r '.region' | cut -d '-' -f 2)
VERSION=$(egrep '^VERSION_ID' /etc/os-release | cut -d '"' -f 2 | cut -d '.' -f 1)
REPOURL="http://yum-${REGION}.oracle.com/yum-${REGION}-ol${VERSION}.repo"

echo "Disabling existing repos"
for i in $REPOS
do
  if [[ "$i" != *".disabled" ]]; then
    mv $i $i.disabled
    echo "$i disabled"
  else
    echo "$i repofile already disabled"
  fi
done
yum clean all
echo "Pulling new regional repository file"
wget -q $REPOURL -O "$REPODIR/yum-${REGION}-ol${VERSION}.repo"
retval=$?
if [[ "$retval" -ne 0 ]]; then
  echo "Unable to pull repo file, please run manual steps"
  exit 1
fi
yum makecache fast

If the automated mitigation fails, you can manually mitigate the issue. Here you disable the existing repo files and pull down the latest repo file from your region's yum server. To identify your instance's region key, look at the region list in Regions and Availability Domains.

To disable the existing repo files, navigate to the /etc/yum.repos.d directory and rename all files present to include .disabled at the end of the file name.

Example:

ls /etc/yum.repos.d ksplice-uptrack.repo.disabled public-yum-ol7.repo.disabled

Download the repo file for your region to the local system. The following example uses Ashburn (with region key iad). Replace iad with the region key applicable to your instance.

cd /etc/yum.repos.d/
wget http://yum-iad.oracle.com/yum-iad-ol7.repo
chown root:root yum-iad-ol7.repo
yum makecache fast