ネットワークエンジニアの備忘録

トラブルや気になった点をメモしておきます。

マルチエリアOSPF環境の通信迂回時の注意点

ospf マルチエリア

先日マルチエリアOSPF環境のルータでモジュール故障被疑が発覚したため、コストアップで経路迂回しようとしたら失敗したので備忘録として残しておきます。環境イメージは以下のとおりです、故障被疑はRT#01です。

f:id:hy0:20180526224557p:plain

通常のトラフィックフローは以下となります。

f:id:hy0:20180526224729p:plain

ここからRT#01とRT#03間のインターフェースコストを10000追加し、経路迂回を実施しました。トラフィックフローを見てみると、RT#03からの経路は迂回出来ているけどBGP Networkからの通信は迂回出来ていない。。。。

 RT#03からの発信経路f:id:hy0:20180526225100p:plain

BGP Networkからの発信経路

f:id:hy0:20180526225108p:plain

 なんでだろうってコンフィグをよく見たらRT#01、RT#02間はArea0でRT#01、RT#03間はArea100でした。OSPF ルートの選択ルールでは、エリア内ルートがエリア間ルートより優先され、エリア間ルートが外部ルートより優先されます。そのため、今回の構成ではコスト値より同一Areaからのルートを優先してしまいます。RT#03から発信する通信はコストに従ってRT#02経由へ迂回できましたが、BGP Networkからの通信はRT#01がRT#03と同一Areaのため、コスト度外視でRT#03に向かってしまいました。

う～ん、マルチエリアはあまり経験がなく、初歩的なことでつまづいてしましました。。OSPFのマルチエリア環境ではシングルエリアとは違う迂回手順が必要なため、注意して下さい。多分RT#01でPassiveにするしかなさそうです。ちなみにPassive化のほうが該当インターフェースのシャットダウンよりダウンタイムが少なったです。

 

 

 

ロードバランサーのTLS1.3対応状況

LB SSL

ちょっと前にA10やF5のエンジニアのかたとお話しする機会があったため、TLS1.3の対応状況を伺ってみました。

基本的に両社とも同様の回答で、現在ラインナップしている機器はファームウェアアップグレードで対応予定であるとのことでした。

しかし、注意点としてSSLに関しては専用のSSLチップでオフロードしており、このチップがTLS1.3に対応していないため、ソフトウェア処理によるスループットの低下が想定されるとのことです。現在と同等のスループットを期待する場合は、暗号化チップがTLS1.3に対応した製品買い替えることを検討しなければなりません。

本内容はUTMやプロキシなど、SSLデコードを行う機器では同様のことが想定されるため、TLS1.3が正式対応される直前では機器のリプレイスを控えるなど、各社がハードウェアレベルでTLS1.3に対応する時期を抑えて顧客に提案する必要性があると感じました。

※2018/8/17追記

セイコーの担当者ともお会いしました、セイコーのロードバランサーは低価格に抑えるために必要最低限の機能搭載としているため、Office365の迂回機能やTLS1.3の対応については現行ラインナップではなく次期製品から対応予定とのことでした。

SRX　ポリシー変更時のセッション断について

Juniper

SRXでFWポリシーを変更する場合、許可しなければいけないポリシーを消してしまうことや、ポリシーの順番を変更する際に、許可したい通信がDenyポリシーにヒットしないか注意する必要があります。その他にも、以下のポリシー操作をすることでセッション断が発生してしまうので注意が必要です。

  • src dest serviceのいずれかをシングルセルからマルチセルへ変更
  • src dest serviceのいずれかをマルチセルからシングルセルへ変更

シングルセルはオブジェクトが単体の状態を指し、マルチセルは複数のオブジェクトが指定されている状態を指します。

例として以下のポリシーを変更する場合、(1)～(3)では影響の有無が異なります。

f:id:hy0:20180502234904p:plain

  1. Src:192.168.0.0/24を削除する場合、マルチセルからシングルセル変更されるため、セッション断が発生します。

  2. Dest:133.243.238.163を削除する場合、マルチセルから変更されないため、セッション断は起きません。

  3. Serviceにプロトコルを追加する場合、シングルセルからマルチセルに変更されるため、セッション断が発生します。

 

MTUの設計

mtu

最近MTUの設計方法をド忘れしていたので、備忘録を残しておきます。

MTUとは1フレームで送信できるデータの最大値を示す伝送単位であり、一般的に使われるイーサネットであればイーサネットフレームの最大値である1518byteからEthernetヘッダ ( 14byte ) と FCS ( 4byte ) は除くため、IPとして通信できるサイズは1500byteとなります。

f:id:hy0:20180412230530p:plain

基本的にはこのMTUサイズが大きければ大きいほど、一度に送信できるデータ量が増えるため、（間の経路でフラグメントを考慮しなければ）通信の効率化が見込めます。そのため、間の経路でPPPoEやカプセル化などのヘッダ追加がないのであれば、実際に機器に設定するMTUも1500にしておけば問題ありません。実際にはローカル環境でない限り1500にすることはあまり無いと思います。その理由はMTUの最適値が間の経路を含めた最小値になるためです。MTUより大きなサイズのパケットがくるとフラグメント化して送信する必要があり、フラグメントの処理はハードウェア処理ではなくソフトウェア処理になってしまい、断片化したパケットを元に戻すのにも処理が必要で負荷が高くなるためです。

例えばGreヘッダは24byteの構成要素があるため、MTUの計算は-24しなければならず1476byteとなります。つまり実際に一度に送れるデータ量が1456byteです。

f:id:hy0:20180412231216p:plain

また、MTUサイズはフラグメントを避けるために小さくすれば良いか？と問われると答えはそうではありません、フラグメントを禁止したパケットがドロップしてしまうためです。このドロップを防ぐためにはいくつかの方法が存在します。

「mtu path discovery」という機能を使えばパケットサイズが超過していた場合に、フラグメントせずに済むサイズで再送するように要求を行うことが出来ます。ただし、mtu path discovery機能はICMPを使用するため、ルータのACLやFWでICMPが全て無効になっていると使うことが出来ません。また、通信を行う相手側（サーバ等）も対応している必要があるため、この機能だけで救えない場合も存在します。

「crypto ipsec df-bit」コマンドを使用すれば強制的にdf-bitを上書きすることも可能です。しかし、各パケットがプロセス レベルで再アセンブルされるため、高いデータ レートでパフォーマンスに大きな影響が生じます。プロセススイッチングによる通信速度低下が起こるうえに、再アセンブル キューが満杯になるとフラグメントが強制的に廃棄されることがあります。また、SSLなどの通信がフラグメント禁止にしているのはハッシュ値が変わることを防ぐためでもあります。これを強制的にフラグメントすることで想定外の挙動になる可能性があります。

 

新たな公開DNSサーバ「1.1.1.1」

dns

APNICとCloudflareが無料の公開DNSサーバの提供を始めました。

このサービスのメリットとしてユーザーのIPアドレスを記録せず、これを証明するためにKPMGによる監査を毎年行うことを名言しています。これは昨今のセキュリティを重視する流れに沿っていて良いと思います。

さらに、公式ページによれば他の公開DNSサーバより高速だとうたっており、一時期流行ったインターネットを高速化するためにDNSサーバのIPを8.8.8.8に変更する手法も、今後は1.1.1.1に変更してみる流れになるかもしれません。

f:id:hy0:20180404222726p:plain

個人的にはお客さんの環境がインターネットへ接続できているかの確認のために、8.8.8.8へpingを打ってもらって切り分けすることがあるので、今後は1.1.1.1に打ってもらうことがあるかもしれません。

 

SRX ClustrerIDの変更方法

Juniper HA SRX

SRXでHA構成を組む場合、以下のコマンドでClusterIDを指定する必要があります。

root> set chassis cluster cluster-id 1 node 0 reboot
root> set chassis cluster cluster-id 1 node 1 reboot

 ClusterIDはHAを組む機器同士で同一の値である必要があり、仮想IPに使用する仮想MACアドレスのベースになります。そのため、VRIDと同様に同一ネットワーク内に同一ClusterIDでHA構成を組んだSRXが存在することは許容されません。SRXの場合、以下の構成では仮想IPが別の値でもUntrustセグメントでMACアドレスが重複します。

 

f:id:hy0:20180401202148p:plain

ClusterIDの変更方法は、HA構成を組む際に使用した上記コマンドと同一であり、HA構成を組んだままClusterIDを変更することが出来ます。ただし、ClusterIDの変更には再起動が必要なため注意してください。

複数セグメントでのVRID重複問題

VRRP

VRRPの標準仕様では仮想IPアドレスに対する仮想MACアドレスを使用します。この仮想MACアドレスはVRIDから作られるため、VRIDが同一だとセグメントが違っていても同じMacアドレスが生成されてしまいます。この仕様は下記のようにL2SW等がVLAN毎にMacアドレスを学習してくれれば通常問題ありません。

f:id:hy0:20180317003938p:plain

しかし、以下のようにVlan単位でMacアドレスを学習できない場合は複数ポートに同一Macアドレスが見えるため、仮想Macアドレス宛のフレームをどのポートに転送するのかはスイッチ次第となり、動作が不安定となります。

f:id:hy0:20180317004235p:plain

では設定を変更して仮想IPのMacアドレスを仮想Macではなく物理Macアドレスを使用すれば良いか？と言われるとそうとは言い切れません。物理Macアドレスを使用するとRFCに準拠しなくなり、パケットロスにも弱くなってしまいます。また、VRRPの系切り替わり時にバッティングログも出てしまいます。昔NECのClusterPROで冗長化していたサーバも物理Macアドレスを使用していたので、よくNW機器にバッティングログが出ていました。

結論としては適切なVLAN設計がされているネットワークではセグメントが分かれていればVRIDが被っていても特に問題はありません。しかし客先ネットワークの一部しか構成を把握できないような案件では、一見セグメントが違う場合もVRIDはユニークなものにしたほうが良いかもしれません。間に何が挟まってるかわからないので。。。

 

SRX HA構成時に片系のみHAランプがオレンジ点灯

SRX HA Juniper

SRX340のHA構成でドはまりしたので備忘録として残しておきます。。。

以下のような構成でSRXでHAを組んだ際に、HAステータスが不安定になりました。具体的には片系のみHAのLEDランプがオレンジ点灯(Amber)となっています。この状態で系切り替えを起こすと通信が引き継がれず、show chassis cluster status コマンドを実行するとインターフェース監視を行っているRedundancy group: 1のみHAランプがオレンジ点灯機器のプライオリティが表示されません。

f:id:hy0:20180310230413p:plain

 

＃正常な出力結果
node0 primary
root >show chassis cluster status 

Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 200 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 1
node0 101 primary no no None
node1 1 secondary no no None
＃問題発生時の出力結果
node0 primary
root >show chassis cluster status 

Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 200 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 1
node0 101 primary no no None
node1 0 secondary no no IF

なんじゃこりゃ、、何分放置しても正常にはならず、HAランプもオレンジ点灯のままだ、、、しかも面倒なのがごくまれに両系再起動すると正常になるんですよね。

 色々模索した結果、物理リンクはLEDが点灯していますが、HAランプがオレンジ点灯している機器のみshow chassis cluster interface コマンドを実行すると監視対象インターフェースがダウンしてました。

＃HAランプがグリーンの機器での表示結果
node0 Primary
root >show chassis cluster interface

Interface Monitoring:
 Interface Weight Status Redundancy-group
 ge-0/0/2 100 Up 1
 ge-5/0/2 100 Up 1
 ge-0/0/4 100 Up 1
 ge-5/0/4 100 Up 1
＃HAランプがオレンジの機器での表示結果
node1 secondary
root >show chassis cluster interface

Interface Monitoring:
 Interface Weight Status Redundancy-group
 ge-0/0/2 100 down 1
 ge-5/0/2 100 down 1
 ge-0/0/4 100 down 1
 ge-5/0/4 100 down 1

もしかしてデフォルトでRSTP動いている？？と思ったら当たりでした。。。設定からRSTPを無効にし、起動しなおすとHAランプもグリーンとなり、素直にHA構成を組んでくれました。試しにプライマリに電源断を起こしても早々に切り替わってくれ、起動するとそそくさとHAも組んでくれたので一安心です。とはいってもSRXは起動自体が遅いので、起動した機器のHAランプがグリーンになり、コマンド出力結果が正常になるまで7分程度かかりました。SRXの結合試験は起動が遅すぎるから億劫ですね。。。

 

ipv6パケットを阻害するL2SW

ipv6

ipv6 IPoE環境ではPPPoEのように認証を行う必要がないため、フレッツ・v6オプションとISPのv6サービスを契約すれば接続するだけでipv6アドレスが払い出されます。

なぜ認証していないのに特定のipv6アドレスを取得できるか？というと、v6サービスを契約することで物理回線（ONU)と払い出されるipv6アドレスが紐づけられます。そのため、v6サービスを提供するにはISP側からCAF番号を求められます。ONUはDHCPv6PDによりプレフィックスを保持しており、ONU配下のipv6 ClientはRAによりipv6アドレスを取得します。PPPoEと違ってセッション制限があるわけではないので、理論上はハブで分岐すればプレフィックス分のホストをつなげることが出来ます。

注意が必要なのはフレッツ・v6オプションを契約すればISPのv6サービスを契約しなくてもipv6アドレスを取得できます。これはNGN/Flets網でのみ使用でき、インターネット網には接続できないipアドレスのため、NGN/Flets網のサービスまたはNGN網での折り返し通信にしか使えません。さらにNTTのNGN/Flets網は東西で分離されているため、ロケーションによっては網内折り返し通信も出来ません。基本的にipv6によるインターネット接続を利用したい場合はISPのv6サービスも契約が必要です。

f:id:hy0:20180306220719p:plain

ここで本題になりますが、特定のL2SWをハブ替わりにしてipv6 Client(PC)を複数接続したときにipv6アドレスを取得出来ませんでした。。。事象が発生したL2SWはWS-C2960S-24TS-L ver:15.0(2)SEです。デフォルト設定で使用してもうまくいかず、ソフトウェアバグなのかな、、、切り分けのためにスイッチをWS-C3560V2-24TS ver:12.2(55)SE8にすると問題なく分岐できました。事象が発生したL2スイッチでパケットキャプチャをしてみるとipv6 ClientはRSを出しているのに、同一Vlanの別ポートではRAはおろかRSもキャプチャ出来ませんでした。ちなみに100均のJJで伸ばしても受け取れなくなり、ハブを使用すれば分岐できました。まだ原因はわかっておらず、まだまだipv6の勉強が足りないと痛感しました。

 

 

SRX340でのHA構成構築

SRX Juniper

初めてSRX340でHA構成を組んだので、備忘録として残しておきます。SRXシリーズでHA構成を組む場合、機器同士でコントロールリンク(fxp1)とファブリックリンク(fab0/1)の最低２本の接続が必要です。ここで注意する必要があるのがコントロールリンクで使用するポートが機種ごとに違います。(ファブリックリンクは任意で決められます)

使用するポートは下記にまとめてあるので参照ください。SRX340ではge-0/0/1です。

www.juniper.net

脱線しましたが、設定手順を記載します。

(1)コントロールリンクであるge-0/0/1同士を接続し、リンクアップさせる。

(2)Primaryに以下の設定を実施

root# delete interface
root# delete security
root# set system root-authentication plain-text-password
New password:"root Password"
Retype new password:"root Password"
root# commit
root# quit
root> set chassis cluster cluster-id 1 node 0 reboot

(3)Slaveに以下の設定を実施

root# delete interface
root# delete security
root# set system root-authentication plain-text-password
New password:"root Password"
Retype new password:"root Password"
root# commit
root# quit
root> set chassis cluster cluster-id 1 node 1 reboot

 

両系立ち上がればHA構成を組むことが出来ます。起動してもしばらくは両系ともに{hold:nodex}と表示されてしまいます。HA構成を組むには両系が起動してから数分待つ必要があるので注意してください。

構成後は各機器でEnterを押すと{primary:node0}、{secondary:node1}と表示が変化します。

本設定以降もファブリックリンクの設定やプライオリティの設定等がありますが、特に難しい作業はないので省略します。