柔らか層外伝 Vyatta編

#SoftLayer と Vyatta について
多くのユーザーにSDN実現のためのコンポーネントとして利用されているのが、Vyatta です。SoftLayer から提供されているバージョンも、構築した時期によってかなりバラツキがあります。

#転ばぬ先の杖

杖１：Firmwareのアップデート

サーバーOSと同じように、デプロイした後は、Firmware をアップデートしましょう。
アップデート方法は、こちらに記載されています。
6.7R10 以降にはしておきましょう！
これは初期構築時だけではなく、定期的に更新する仕組みを検討し、実装しておく、ということも大切です。特に、Vyattaはネットワークの中心的な役割を担うことが多く、パフォーマンスの改善やセキュリティの強化などが施されることがあります。そんな便利機能、積極的に使わない手はありませんね。

杖２：TAG VLANのNICを作成してVRRPを構成する場合、rfc3768-compatibilityを設定しない

標準のVLAN、つまり　非TAG VLAN、さらにいうと、GW VLAN ですとか bond0/1の方は設定して問題ありません。
この frc3768-compatibility は、TAG VLANに設定してしまうと、VMのIP AliasのArp Resolutionが失敗することが分かってマス。
・TAG VLANなしのNICのVRRPには初期設定で設定されている
・TAG VLANありのNICにVRRPに設定すると不具合が発生してしまう

杖３：NICの帯域、足りてるか？

野菜、足りてる？な感覚で、ぜひ Vyatta の NIC と Vyatta を通るトランザクションに問題ないかを確認しましょう。特に、複数の VLAN を Vyatta で制御している場合は慎重に！
ログファイル転送などは圧縮して送る、とかSNMP/SMNP Trapによる監視などでトランザクション量を減らす、など全体のトランザクションについても要確認です。
一般的な企業内システムとして利用する場合、NICには1Gbps以上を強くオススメします。
また、Vyatta の帯域を広げた後、その後段のシステムの NIC も十分か、確認しましょう！

杖４：ルールは適切か？

杖３でも触れた「トランザクション」に関連します。
Firewallのルール作りでやってしまいがちですが、止めたいトラフィックだと認定するまでのフィルタが最適かどうかを考えましょう。
Vyattaのログを見てもパケットを受信した形跡がなく、サポートに聞いてもBCRやFCRに問題がないのに、通信エラーが出るような場合、フィルターが重過ぎることを疑うべきです。

Zone-policyベースでは、パケットを受け取って、転送先が決まって、いざ出力する直前の段階でフィルタをかけることになるので、パケットが増えてきたとき、処理に時間がかかる傾向があります。
Zone-policyでなくても、out側のルールだけでフィルターをしていたり、default denyに至るまでのルールがずらーーーーーっと長い場合は要注意です。シンプルにしましょう！

杖５：監視する

Vyattaそのものを監視することを検討しましょう。
IPSecなどトンネルの状況も簡単に監視できるサービスがご利用いただけるようになっています。
今なら、2019年末まで無料でお試しできます。
https://www.ibm.com/cloud/network-appliances

#こんなログ（Tx Unit Hangまたはixgbe_validate_register_read）が出た
これはSoftLayerあるある、です。Tx Unit Hangやixgbe_validate_register_readは、帯域が高負荷状態になると表示されるログです。Tx Unit Hangについては、HA構成を組んでいると、Tx Unit Hang発生→VRRP発動　で想定しない動きとなることが知られています。
この症状は、FLOW DIRECTORを無効化することで回避できます。

ethtoolコマンドでntupleをonにすることで無効化できます。しかし、サーバーの再起動によりリセットされてしまうため、/opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.scriptに実行コマンドを記述します。

/opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script

# This script is called from /etc/rc.local on boot after the Vyatta
# configuration is fully applied. Any modifications done to work around
# unfixed bugs and implement enhancements which are not complete in the Vyatta
# system can be placed here.
/sbin/ethtool -K eth0 ntuple on
/sbin/ethtool -K eth1 ntuple on

ethtool –kコマンドによりntupleの状態を確認できます。

vyatta@vyatta01:/opt/vyatta/sbin$ /sbin/ethtool -k eth1
Offload parameters for eth1:
  :
ntuple-filters: on
  :

#IPSec接続で、BGPがうまくルーティング情報を反映してくれない
データセンター間をIPsec VPNで接続し、各データセンターでは、デフォルトで割り当てられるPrimary IPサブネットに加えて、独自のIPアドレスのサブネット(BYOIPサブネット)を作成し、さらに、BYOIPサブネットのルーティング情報を、データセンター間でBGPで交換するといった設定をするケースがあります。
普段どおりに設定していくと、vyatta#1側で、vyatta#2からBYOIPのルート（例：192.168.2.0/24のルート）を受けっとってはいるが、ルーティングには出てこない、といったことになります。
この解決には、BGPのネイバー接続の設定（ebgp-multihop '2'）が必要です。

vyos@vyos# set protocols bgp 65001 neighbor 192.168.10.2 ebgp-multihop '2'
vyos@vyos# commit
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done

ネイバー接続についてはこちらを参照してください。

#補足
VyOS、使いたいなぁ、と言う場合は、
ShinobiLayer: SoftLayerで利用できるVyOSイメージを公開をしましたをご参考ください。
こちらもあわせて。Vyatta on SoftLayer覚え書き