ささの備忘録

ITインフラSEの備忘録です ITインフラを中心に、 日々忘れないがちな事を、つぶやいていきます

2019年04月

STP(スパニングツリープロトコル)の動作を検証③

前回、STP(スパニングツリープロトコル)の動作を検証②で、YAMAHAルーターでは、STPが実装されておらず、冗長経路を作ると、ループしてしまいました

今回は、機器を「YAMAHA RTX32」→「Ciscoルーター892J」へ変更して、試してみたいと思います。こんなイメージです

STP12

実際に、Cisco892に、インターネット接続設定を行い、接続しました
赤い円で囲んだところが、冗長経路(ループ構成)になっています

stp11

PCをつなげると、PCがフリーズ(マウスも全く動かない・・)
スイッチのランプを見ると、経路両方共リンクがあがってしまっており、「ループ」してしまいました
PCからスイッチに接続するLANケーブルを抜くと、フリーズは解消

恐らく設定がよくないのでしょう

機器側で状態を見てみたいと思います

Cisco 892の状態を確認してみる

コンソール画面より、確認していきます

・STPは動作しているか?
#show spanning-tree
結果を見る限り・・
 -STPは動作している
 -FE0, FE1共「Forwarding」状態になっている
 -BPDUを送信しているが、受信していない
stp12

この情報をみると、Allied側が悪そうな感じです

Allied GS908Mの状態を確認してみる

以下のコマンドは投入済み
>enable stp
>SET STP RSTPTYPE=STPCOMPATIBLE※
※この機種のデフォルトSTPモードは、RSTPなので、通常モードも対応させる)

・STPの状態を確認
>show stp portstate=
 -STPは動作している
 -Port6, Port7共「Fowarding」状態
stp13


こんな状態でした

機器単体で試してみた

この後、いろいろ試行錯誤したのですが
現象は改善されませんでした

ひとまず、機器それぞれで動作を確認してみました

具体的には・・
LANケーブルをぐるっと回して、自分だけでループ構成にしてみました
stp14
・Cisco892
#show spanning-tree
しっかり、「blocking」ポートが出来ました
問題なさそうです
stp15

・Allied GS908M
>show stp portstate=
相変わらず、両ポートとも「Fowarding」状態
stp16

Allied 908M側の設定が悪そうな事は分かったのですが
それ以上の原因がわからず、タイムアップとなってしまいました

また、時間があるときに仕切り直しで、検証してみたいと思います




STP(スパニングツリープロトコル)の動作を検証②

こんにちは、ささです

前回、STP(スパニングツリープロトコル)の動作を検証①で、STPのざっくりとした動作について、書きました

早速、試してみようと思います

ひとまず、家にある機器より、以下機器を選定しました
安定のYAMAHAルーター「RTX32」と、唯一のL2スイッチ「GS908M」
stp06

やりたい事は、こんな感じです
あえて、機器間の接続を2重にして、ループ構成にさせて、STPを動作させます
STP7

まず、機器間の接続を1本で、インターネット接続を確認します
もちろん、「OK」
STP8

では、機器間の接続を2本にして、あえて「ループ構成」にしてみます
STP9

すると、PCの操作が効かなくなり、
スイッチのランプの激しく点滅、「ループ状態」になりました

まぁ、想定内なのですが、
「デフォルトでSTPは有効になってないのか」
と思い、まず、RTX32のコマンドで、STPの状態を確認して見ようと・・
コンソールで、コマンドを打とうとしますが、
STP10

STP状態を確認するコマンドや、STP設定するコマンドが無い!!

ここで、やっと気づきました

「YAMAHAルーターってSTPに対応していないのでは!!」

仕様を確認してみます、RTX32は無いので、RTX810で

STP11

「あぁ~、無い」

STP機能がありませんでした

仕切り直しです

Alliedだけでも、STP動作していれば何とかなる気がしますが・・
こちらの動作していないのかな??

次回までに、STPに対応している機器を準備します
準備不足ですみません



STP(スパニングツリープロトコル)の動作を検証①

こんにちは。ささです。

やっと花粉症の季節もおわり、ほっと一息
ただ、まだ寒いですね。もう4月の半ばなのに、忘れてるな~
毎年、こんな寒かったかな~

今回は、ネットワーク機器に昔からある機能である、「STP(スパニングツリープロトコル)」を、試してみたいと思います。
機能自体は、机上で理解しているつもりですけど、実践で意図して使った事がない

なんとなく、デフォルトで動いている感じ

まず、「STP」について、改めておさらいしてみます

「STP」の目的

まず、「STP」の目的は
 信頼性の高いネットワークを構築するため

通常、信頼性の高いネットワークを構成する為には、一部のネットワーク機器に障害が発生して、迂回路で通信できるように、複数のスイッチ同士で、複数経路が出来るように構成します

そうすると、スイッチ間で輪っか構成になります
こんな感じ↓
STP1

しかし、その構成では問題が発生します。

具体的には、PCが上位スイッチの先の宛先、例えば「インターネット」へ通信する際(絵が途切れていてすみませんm(_ _"m))、まずは、ゲートウェイのルーターと通信を行います

その為、ルーターのMACアドレスを知ろうとします
(ルーターのIPアドレスはデフォルトゲートウェイ設定からわかります)

PCはARPリクエストを、接続スイッチにブロードキャストします

すると、そのブロードキャストが、LANケーブル接続先全ての経路に送信されます
受け取ったスイッチは、同じように全経路に送信されます
STP2

すると、フレームがスイッチ間を「グルグル」「フレームが増殖」していくと、「ブロードキャストの嵐(ストーム)」が発生し、同じセグメント間のスイッチがすべて停止※してしまいます
※特に機能がなければ・・

これが「ループ」です

この「ループ」を防ぐ為、通常、どこかのスイッチポートを停止しておけば大丈夫
こんな感じ↓
STP3

こうすることで、経路が1方向になりますので、「ブロードキャストストーム」=「ループ」は発生しなくなります

もし、今使っている経路が使えなくなったら、停止していたポートを開始して、迂回経路を使えるようにすれば、「信頼性の高いネットワーク」になります

これが、「STP」の概要です

「STP」のざっくり仕組み

では、上記動きを実現される「STP」の仕組みですが・・

細かなところは、実際の機器で確認しながら、説明していきたいと思いますので、ざっくりと書きます

『STPで停止(ブロック)するポートの決め方』
① まず、ループ構成のスイッチの中で、代表となるスイッチを決めます
 なぜ代表を決めるか?:この代表から一番遠いポートを「ブロック」する為
 代表の決め方:STPが有効なスイッチは「ブリッジID」をもっており、最小のブリッジID
 やりとり:BPDUといフレームの中に情報をいれて、やりとりします

STP4

② ルートブリッジから「一番遠いポート」の決め方
 遠いポートの判断:スイッチ間の「帯域幅」で決めます
 STP5
いろいろと、細かなことは省略しますが、
上記のような流れで、ルートブリッジから、一番遠いポートを決めて、「ブロック」します


次回は、「STP」の動作を実際に確認してみたいと思います



最近の「Citrix XenApp」について

こんばんは。今日は寒い
昨日まで、暖かかったせいで、コートを着ないで会社に行ってしまいました
う~っ 寒い

さて、最近めっきり、話をきかなくなった「Citrix XenApp」についてです
商品としては、存在していますが、Remote Desktopサービスの影に隠れている感じです

最近の「Remote Desktop」は高機能なので、あまり「XenApp」と変わらない気がします

その中でも、Windows Server 2008からサポートされる「RemoteApp」の存在が大きく
XenAppの得意技である、アプリケーション公開を、WindowsOSの標準機能で実現が可能になりました

また、最近のアプリケーションは「Remote Desktop」に対応しているものも多く、あえて「XenApp」を選択することは、少なくなっているような気がします

Citrix Virtual Apps and Desktop(旧XenApp)

今、Citrixのページを調べたところ、名前が変わってました
「XenApp」改め、「Citrix Virtual Apps  and Desktop」と

Citrix Virtual Apps and Desktops(旧称:XenApp & XenDesktop)

現在(2019/4/8)の最新Ver:Citrix Virtual Apps and Desktops 7 1903

名前は変わりましたが、XenApp7.Xから、XenDesktopと融合しているところは、相変わらず

さらに、接続クライアントソフトである「Citrix Reciver」も名前を変え、「Citrix Workspace」へ
XenApp7より、Webアクセスのみ対応なので、名前は変わっても、この部分は変わらないでしょうか

いろいろ、変わってしまった事に気づき・・
ちょっと、検証の虫がうずうずしてきたので、
再度、現在のVerで、XenApp環境構築を検証してみたいと思います。
また、報告いたしますね


FortiGateの『deep-inspection』について

こんにちは
今日は天気も良くて、花見日和です
こんな日は、公園で花見しながら、ビールですよぉ
でも、年々面倒くなり、ゴロゴロしながら、漫画読んだり、YouTube見たりが、最近の定番です

以前「FortiGateのSSLインスペクションで『deep-inspection』を使う」で、お話の続きです、今回は、もう少し「SSLインスペクション」を掘り下げてみたいと思います

具体的には、HTTPSでアクセス時、ダウンロードしたファイルのウィルススキャンが実施されるか?実施されないか?を試してみたいと思います

調べる限りでは、

・『certificate-inspection』:スキャンが実施されない
・『deep-inspection』:スキャンが実施される

です。では、早速試してみました!

『certificate-inspection』ではどうか?

自宅で使用しているFortiGate60Dの、[internal]->[wan1]に、「AVプロファイル」と「certificate-inspection」を適用します
deep01

PCから、テストウィルスファイル「eicar」をダウンロードします
まずは、HTTPプロトコルでダウンロード実施
deep02

すると、きっちりFortiGateで検出してくれました
deep03

次に、HTTPSプロトコルでダウンロードします
deep04

「あれっ」検出されず、ダウンロードされてしまいました
deep05

やはり、「certificate-inspection」では、HTTPSでアクセス時のウィルスキャンは、実施されないようです

『deep-inspection』ではどうか?

次に、「deep-inspection」を適用してみます
deep06

PCから、テストウィルスファイル「eicar」をHTTPSプロトコルでダウンロードします
deep04


きっちりと、テストウィルスを検出してくれました
deep07

この結果からも、HTTPS通信を保護できていなければ、セキュリティが確保できているとは言えません。面倒ですが、ぜひ、『deep-inspection』を使用しましょう!


スポンサードリンク
プロフィール

ささ

名前:ささ
関東地方に住む40代、子供2人と妻と猫とで暮す
主に「ITインフラ系」の構築に携わる。今の会社は転職の末、お世話になり早20数年。保有資格は、「ネスペ」「セスペ」など
最近、「ソロキャンプ」「DIY」を趣味にするため、いろいろと準備中