ブロードキャストストームを起こしてみた。

##■はじめに
ブロードキャストストームがどのようにして起こるのか、wire sharkでキャプチャーしながら確認をしてみました。


シミュレートはGNS3を使用しています。
##■レイヤー2の基本的な動き
ブロードキャストストームとは、レイヤー2でARP要求パケットがループして輻輳する現象になります。
まずは、レイヤー2における基本的な挙動を見ていこうと思います。

【各PCの情報】

| NAME     |       IP/MASK|    MAC    |
|:-----------------|------------------:|:------------------:|
|PC-1             | 192.168.1.1/24 |00:50:79:66:68:00      |
|PC-2          |192.168.1.2/24|00:50:79:66:68:01       |
|PC-3           | 192.168.1.3/24 |00:50:79:66:68:02        |

![topology1.png](https://qiita-image-store.s3.amazonaws.com/0/160993/64151637-de81-3f07-b3fc-15278f8734db.png)


**①上記構成で、PC-1からPC-2へpingを飛ばしてみます。**

```
PC-1> ping 192.168.1.2
84 bytes from 192.168.1.2 icmp_seq=1 ttl=64 time=2.005 ms
84 bytes from 192.168.1.2 icmp_seq=2 ttl=64 time=5.014 ms
84 bytes from 192.168.1.2 icmp_seq=3 ttl=64 time=0.972 ms
84 bytes from 192.168.1.2 icmp_seq=4 ttl=64 time=1.688 ms
84 bytes from 192.168.1.2 icmp_seq=5 ttl=64 time=1.672 ms
```
**②wire sharkでキャプチャ**
・1行目
PC-1(MAC 66:68:00)より、ブロードキャストでARP要求を送っており、同一セグメント192.168.1.0/24のすべてのノードに対して発信しています。
![wire1.png](https://qiita-image-store.s3.amazonaws.com/0/160993/238304fc-d244-2a85-a303-b9a7e4400880.png)


・2行目
192.168.1.2のIPを持っている、PC-2から自分が持っているよ~、と言うARP応答になります。
PC-2(MAC 66:68:01) → PC-1(MAC 66:68:00)
![wire2.png](https://qiita-image-store.s3.amazonaws.com/0/160993/9cd9eb22-41f8-0221-e41b-d0b03013f55e.png)


・3行目、４行目以降
ICMPのrequestとreplyになり、計5回ICMPを送っているため、行きと帰りの通信で計10回記録されています。

![wire3.png](https://qiita-image-store.s3.amazonaws.com/0/160993/6583bc0c-ec50-e45d-4345-0c61e0d348ea.png)


このように、ある宛先に対して通信をする時に、事前にARPをブロードキャスト投げていることが分かります。

##■実際にブロードキャストストームを起こしてみる。
ケーブルを一本追加して、ループ構成にしました。
パケットキャプチャはwire sharkを利用して、赤〇で囲った上段のポートをキャプチャしています。

【各PCの情報】

| NAME     |       IP/MASK|    MAC    |
|:-----------------|------------------:|:------------------:|
|PC-1             | 192.168.1.1/24 |00:50:79:66:68:00      |
|PC-2          |192.168.1.2/24|00:50:79:66:68:01       |
|PC-3           | 192.168.1.3/24 |00:50:79:66:68:02        |

![topology2.png](https://qiita-image-store.s3.amazonaws.com/0/160993/9f8318fd-3270-8b04-b81b-73b8d4fd3bd4.png)


**〆この状態で、pingを送るとどうなるでしょうか？**
PC-3からPC-1へpingを送ってみましょう。

```
PC-3> ping 192.168.1.1
192.168.1.1 icmp_seq=1 timeout
192.168.1.1 icmp_seq=2 timeout
192.168.1.1 icmp_seq=3 timeout
192.168.1.1 icmp_seq=4 timeout
192.168.1.1 icmp_seq=5 timeout
```

タイムアウトをして、疎通確認がとれません。

**〆PC-1からPC-3へもpingを試して見たいと思います。**

```
PC-1>
PC-1> 
プロンプトが固まって動かなくなりました。
```


**〆実際にwire sharkでどのような通信がされているか見てみます。**

![2018-03-02 (6).png](https://qiita-image-store.s3.amazonaws.com/0/160993/bb22af13-32c0-2e53-4af0-005d5803c78a.png)

PC-3からのブロードキャストでのARP要求が次々と続いています。
PC-1に関しても、次々にくるARP要求に対してARP応答をPC-3へ返しています。



##■ARPの挙動
**イメージ①**
PC-3からPC-1へARP要求を送る時に、ブロードキャストで受信ポート以外のすべてのポートからARP要求パケットを送信をします。

![スライド1.JPG](https://qiita-image-store.s3.amazonaws.com/0/160993/60342c5f-7881-ca34-4a0e-65c214f25da3.jpeg)


**イメージ②**
Ethernetswitch-1の上段ポートに流れてきたARP要求パケットは、PC-1側のポートと下段のポートへARP要求パケットを出力します。
Ethernetswitch-1の下段のポートに流れてきたARP要求パケットは、PC-1側のポートと上段のポートへARP要求パケットを出力します。

![スライド2.JPG](https://qiita-image-store.s3.amazonaws.com/0/160993/35d948e2-85aa-0f18-eb55-d3177c815ead.jpeg)


**イメージ③**
Ethernetswitch-2の上段ポートに流れてきたARP要求パケットは、PC-2、PC-3側のポートとEthernetswitch-2左側の下段のポートへARP要求パケットを出力します。
Ethernetswitch-2の下段のポートに流れてきたARP要求パケットは、PC-2、PC-3側のポートとEthernetswitch-2左側の上段のポートへARP要求パケットを出力します。

![スライド3.JPG](https://qiita-image-store.s3.amazonaws.com/0/160993/1ed015b8-8944-1892-66e1-0bf8c7f2ccc8.jpeg)

イメージ②とイメージ③が繰り返されることで、ブロードキャストストームが発生します。
帯域は、ループしているARP要求で埋め尽くされ、PC-1は次々にくるARP要求へのARP応答をPC-3へ返します。
PC2に関してもは、次々に来るARP要求を破棄する挙動をします。

対応としては、ループ構成となっている結線を抜栓する事で収束していきます。