ネットワーク設定について¶

仮想サーバのNICをBonding構成にすることは可能ですか?¶

同一仮想サーバに搭載された複数のNICは、同一のスイッチまたは共有回線に接続できないため、Bonding構成はできません。

ルータ+スイッチで使用できないIPアドレスはありますか?¶

先頭の4個はネットワークアドレスやルータ用のため、最後尾の1個はブロードキャストアドレスのため使用できません。

※203.0.113.0/28(16個)の場合の例

203.0.113.0	ネットワークアドレス(使用不可)
203.0.113.1	デフォルトゲートウェイ (使用不可)
203.0.113.2	マスター側ルータ (使用不可)
203.0.113.3	バックアップ側ルータ (使用不可)
203.0.113.4～14	お客様使用可
203.0.113.15	ブロードキャストアドレス (使用不可)

仮想サーバ1台に割り当て可能な最大アドレス数は何個ですか?¶

共有セグメント（100Mbpsベストエフォート）回線の場合は、IPアドレスの割り当ては、最初の1個のみで、追加することは出来ません。

ルータ＋スイッチ（有償）を利用する場合は、ルータ＋スイッチで割り当てされたIPアドレスブロック(ネットワークアドレスやブロードキャストアドレスなど使用できないIPアドレスを除く)やスタティックルーティング機能で追加したIPアドレスブロックから自由に割り当てることが可能です。

ただし、ルータ＋スイッチに接続可能なNICは、サーバあたり1個に制限されるため、使用するサーバOSの技術的な制限により、割り当て可能な最大IPアドレス数が制約される場合があります。

NICのインタフェース名が変更されてしまいますが原因は何ですか?¶

Linux系のOSなど、udevを使用している場合に発生する場合があります。
インタフェース名が変更される場合/var/log/messagesに以下のメッセージが出力されます。

kernel: udev: renamed network interface eth1 to eth2

udevのルール(/etc/udev/rules.d/70-persistent-net.rulesなど)を削除しOSを再起動することで変更されなくなります。

サーバに取り付けられたNICのMACアドレスが変更されるのはどのような場合ですか?¶

作成済みのNICを削除する以下のような操作

NIC取り付け先サーバの削除
サーバの追加NICの削除

を行った場合、同じMACアドレスを再利用することはできず、新たに作成されるNICには新たなMACアドレスが割り当てられます。NICの削除を伴わない

サーバの電源停止・起動
サーバのプラン変更
NICのスイッチへの接続・切断
ディスクの接続・切断

などの操作ではMACアドレスは変化しません。

NICのMACアドレスで固定化したものを割り当てたり、任意のものに変更することはできますか?¶

クラウド上の仮想NICは、弊社がIEEEより割り当てられたOUIを使用したグローバルに一意なMACアドレスがNIC作成時に自動的に割り当てられます。そのため、お客様ごとに固定的にMACアドレスを割り当てることや、お客様任意のものに変更することはできません。

パケットフィルタで設定可能なルール数に制限はありますか?¶

1つのパケットフィルタに登録可能なルールは30個までとなります。詳細はパケットフィルタのページを参照ください。

VRRPによる冗長構成は可能ですか?¶

スイッチ、またはルータ+スイッチをご利用いただくことで、仮想サーバでVRRPを使用した冗長構成をとることが可能です。

ただし、さくらのクラウドの仕様上、頻繁な切り替えを避けるためVRRP Advertisement送出間隔を5秒以上に設定することを推奨します。

例: keepalived使用時の設定例

vrrp_instance V1 {
        state BACKUP
        interface eth0
        virtual_router_id 1
        priority 100
        advert_int 5             ※ advert_intパラメータ
        virtual_ipaddress {
                xx.xx.xx.xx
        }
}

※ 上記のようにadvert_intパラメータを5以上に指定してください。

VRRPを利用した場合の仮想IPアドレス(VIP)の使用について制限はありますか?¶

仮想IPアドレスに紐づくMACアドレスとして物理MACアドレス(仮想サーバに割り当てられたMACアドレス)を使用する場合、制限はありません。
切り替わりの際は、近隣ホストのARPテーブル書き換えを促すためGARP送出を推奨します。
仮想MACアドレスを使用する場合、以下の4種類のみ使用可能です。
00:00:5e:00:01:01
00:00:5e:00:01:02
00:00:5e:00:01:03
00:00:5e:00:01:04

※VRRPのVID=1～4に対応する仮想MACアドレスとなります

ISOイメージやアーカイブのFTPアップロードで使用するポート範囲を固定することはできますか?¶

FTPでの転送時にパッシブモードを使用することで、さくらのクラウド側FTPサーバ宛通信で使用するポート範囲を「65000番ポート～65535番ポート」に固定することができます。
ファイアウォールを経由する場合などは、FTPアップロード時に表示されるFTPサーバに対し、上記ポート範囲の通信を許可する設定を行ってください。

Linux系OSを使用していてサーバへのアクセスが遅い、または予期しないパケットが観測されます。改善する方法はありますか？¶

Linux系OSをご利用で、virtio-netを使用していない場合、ダウンロード方向の通信が遅かったり、アクセス元で予期しないパケット分割や重複するTCP-ACKパケットなどが観測されることがあります。

この場合、以下のどちらかを実施いただくと改善することがあります。

virtio-netを利用する（推奨）
LinuxのTSO (TCP Segmentation Offload) 設定を無効にする

virtio-netを利用する場合は、サーバの「情報」タブから「編集」ボタンを選択し、オプションの “VirtIO-Net” をチェックして更新を選択します。
サーバをシャットダウンし、コントロールパネル上から起動を行うことで設定が有効になります。

オプションからVirtIO-Netを選択して更新します。

LinuxのTSO (TCP Segmentation Offload) 設定を無効にする場合は、以下のコマンドを使用します。コマンドの実行には root 権限が必要です。

●TSOの設定を無効にします

# ethtool -K <対象のインターフェイス> tso off

●設定が反映されていることを確認します。

# ethtool -k <対象のインターフェイス>
...略...
tcp-segmentation-offload: off
    tx-tcp-segmentation: off
    tx-tcp-ecn-segmentation: off [fixed]
    tx-tcp6-segmentation: off [fixed]
...略...

ここで、tcp-segmentation-offload と tx-tcp-segmentation が “off” となっていればTSOは無効化されています。

再起動後も設定を有効にする方法と、ディストリビューションごとの注意点は下記の通りです。

CentOS / Scientific Linux

再起動後も設定を有効にするには、/etc/sysconfig/network-scripts/ifcfg-* ファイルに ETHTOOL_OPTS を追記します。

# cat <<__EOL >> /etc/sysconfig/network-scripts/ifcfg-<対象のインターフェイス>
ETHTOOL_OPTS="-K <対象のインターフェイス> tso off"
__EOL

Debian

再起動後も設定を有効にするには、/etc/network/if-pre-up.d/ 配下に “tso” というファイルを作成します。

# cat <<'__EOF' > /etc/network/if-pre-up.d/tso
#!/bin/sh
ETHTOOL=/sbin/ethtool
$ETHTOOL -K <対象のインターフェイス> tso off
__EOF

上記ファイルに実行権限を付与します。

# chmod 755 /etc/network/if-pre-up.d/tso

Ubuntu Server

Ubuntu Serverでは、ethtoolコマンドは標準ではインストールされていないため、以下のコマンドを使用してインストールします。

# apt-get install ethtool

なお、再起動後も設定を有効にする方法は上記 Debian と同様です。

FreeBSD

FreeBSDではethtoolではなく、sysctlコマンドでカーネルパラメータを確認します。出力が “1” であれば、TSOは有効となっています。

# sysctl net.inet.tcp.tso
net.inet.tcp.tso: 1

sysctlコマンドでTSOを無効にします。

# sysctl net.inet.tcp.tso=0 net.inet.tcp.tso: 1 -> 0

再起動後も設定を有効にするには、/etc/sysctl.confに記述を追記します。

# cat <<__EOL >> /etc/sysctl.conf

# TSO off
net.inet.tcp.tso=0
__EOL

サーバからの急激な外部向けトラフィック発生時にパケットがロスしてしまいます。軽減する方法はありますか？¶

ネットワーク設備の負荷軽減のため、お客様サーバから急激に外部向けのトラフィックが発生した場合はパケットが破棄される場合があります。
対策として、Linuxサーバをご利用の場合は急激なトラフィック増大に備えて以下のようにtcコマンドによる外部向けトラフィック制限を設定する方法があります。

※スイッチに接続されたサーバの場合、搭載メモリ量に応じた帯域制限が行われます(詳細についてはスイッチに帯域制限はありますか? を参照ください)。サーバ側での制限設定はスイッチ側での制限値の範囲内となるように設定してください。

eth0の外部向けトラフィックを10Mbpsに制限する場合、以下のコマンドを管理者権限で実行します。

# tc qdisc add dev eth0 root tbf limit 1Mb buffer 200Kb rate 10mbit

設定後、以下のコマンドで確認することができます。

# tc qdisc show dev eth0

また、再起動後も有効になるように/etc/rc.localファイルに設定コマンドを追記します。

tcによる帯域制限が有効に動作するよう、データの分割・結合処理をNIC側で行うsegmentation offload機能を無効化します。まず現在の設定状況を確認します。

# ethtool -k eth0|grep segmentation-offload
tcp-segmentation-offload: off
generic-segmentation-offload: off

さくらのクラウドではデフォルトでoff状態となりますが、もしon状態の場合、以下のコマンドで無効化の設定を行います。

# ethtool -K eth0 tso off gso off

また、再起動後も明示的にoff状態となるように/etc/sysconfig/network-scripts/ifcfg-eth0ファイルに以下の設定を記述します。

ETHTOOL_OPTS="-K eth0 tso off gso off"

独自にDSR方式のロードバランサを構成しています。バランシング先との通信が一定時間経過後に遅くなりますが原因と対策はありますか?¶

クライアントや実サーバ、ロードバランサなどの各ホスト間が複数のスイッチで構成されたネットワークの場合、L2ネットワーク内にARPパケットがブロードキャストされない限りは自らに直接接続されているホスト以外のMACアドレスを受動的に知ることができない状況となります。

そのため、エージタイムの時間内に各スイッチのMACアドレステーブルが更新されないままとなりやすく、MACアドレス再取得のためフラッディングされたEthernetフレームが一定のしきい値を超えてしまいunknown unicast flooding制限により帯域が縮小される場合があります。特にDSR型のロードバランサなど、パケットの流入出方向で経路が異なる場合に起こりやすい問題です。

対策として、一定時間ごとに各ホスト上で自身のMACアドレスをL2ネットワーク全体にブロードキャストさせることをおすすめします。以下はarpingコマンドを使用し、同様の動作を行う場合の例です。

# arping -A -c 1 $自身のIPアドレス >& /dev/null

※アプライアンスロードバランサでは同様の事象が発生しないような対応を行っています。

注釈

さくらのクラウドにおけるL2ネットワークの仕様とDSR方式のLVS構築時の注意点については さくらのクラウドにおける L2ネットワークの仕様について のドキュメントにもまとめてあります。合わせてご参照ください。

サーバ作成時に指定したNICドライバから変更したいです。どこを操作すればいいですか?¶

サーバのNICドライバはVirtIO、もしくはIntel e1000ドライバエミュレーションの2種類から選択できます。いずれかに変更したい場合は一旦サーバの電源を停止し、情報タブ画面右下の「編集」ボタンより行います。サーバ情報画面の表示方法など詳しい手順についてはサーバの詳細情報のページを参照ください。

サーバのIPアドレスと上位オクテットが同一の外部サーバに接続できません(133.242..のサーバからネームサーバ133.242.0.3へ問合せできないなど)¶

IPアドレスが設定されたインターフェースのネットマスク設定が間違っている可能性があります。サーバ詳細情報のNICタブに表示されるネットマスク値が正しく設定されているかをご確認ください。