*

Juniper FireFlyでJUNOSと仲良し その2

ネットワークG 南部です。

前回は2台のubuntu間でpingが届くところまで確認しましたが
ネットワークがシンプルすぎるのでもう少しISPっぽく修正したいと思います。

ispっぽく

 

筆者の主観ですがiBGPが張ってあるとISPっぽいんではないでしょうか。大規模ISPですとユーザへのルーティングがBGPにくべられていることが多いと思います。network1(11.0.0.0/24)とnetwork2(22.0.0.0/24)をiBGPに入れることにします。

Fireflyへのログイン

前回の続きで2台のFireflyにログインします。

firefly1へログインする・・・telnet 192.168.233.11

firefly2へログインする・・・telnet 192.168.233.12

Fireflyの設定

設定の時はコンフィグレーションモードに移行します。

lab@firefly2> configure
Entering configuration mode

[edit]

 

firefly1

iBGPを張るのは一般的にルータのループバックアドレスを使います。

set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive

投入した設定は、まだ反映されていないですよね。
今回の設定分をshow|compareコマンドで反映前に確認します。

lab@firefly1# show | compare
[edit] interfaces
+   lo0 {
+       unit 0 {
+           family inet {
+               address 1.1.1.1/32;
+           }
+       }
+   }
[edit] protocols ospf area 0.0.0.0
      interface ge-0/0/1.0 { ... }
+     interface lo0.0 {
+         passive;
+     }

[edit]

次に本当にこの設定が正しいかをcommit checkコマンドで確認します。

lab@firefly1# commit check
warning: You have changed inet flow mode.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
configuration check succeeds

[edit]

最後にcommitコマンドで設定を反映します。

lab@firefly1# commit
warning: You have changed inet flow mode.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
commit complete

[edit]

作業時の一連の流れはshow|compare –> commit check –> commit という感じです。

firefly2

以下のconfigを投入します。

set interfaces lo0 unit 0 family inet address 1.1.1.2/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive

コミットします。

commit

ループバックの/32がOSPFで対抗のルータに伝わったはずです。

ルーティングテーブルの確認

JUNOSではconfigurationモードにいるときに
設定以外のコマンドを打つ場合、runコマンドを使います。(Ciscoでいうところのdoコマンド)

lab@firefly1# run show route protocol ospf

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.2/32 *[OSPF/10] 00:04:38, metric 1
> to 1.0.12.12 via ge-0/0/2.0
22.0.0.0/24 *[OSPF/10] 00:19:03, metric 2
> to 1.0.12.12 via ge-0/0/2.0
224.0.0.5/32 *[OSPF/10] 00:20:17, metric 1
MultiRecv

[edit]

pingで確認

pingを打つ際に、ソースIPアドレスを指定しないと知りたいことが正確にわからないことがあります。

lab@firefly1# run ping 1.1.1.2 source 1.1.1.1
PING 1.1.1.2 (1.1.1.2): 56 data bytes
64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=12.354 ms
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=10.189 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=10.151 ms
^C
--- 1.1.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.151/10.898/12.354/1.030 ms

[edit]

firefly1のbgpの設定

## 11.0.0.0/24の経路がOSPFに流れるのを止めます。
delete protocols ospf area 0.0.0.0 interface ge-0/0/1.0

## IBGPの設定を行います。
set routing-options autonomous-system 1
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 1.1.1.1
set protocols bgp group IBGP neighbor 1.1.1.2
set protocols bgp group IBGP export BGP11
## IBGPに入れる経路は11.0.0.0/24だけとするポリシーを作ります。 
set policy-options policy-statement BGP11 term 10 from route-filter 11.0.0.0/24 exact
set policy-options policy-statement BGP11 term 10 then accept
set policy-options policy-statement BGP11 term 999 then reject

commit

firefly2のbgpの設定

## 11.0.0.0/24の経路がOSPFに流れるのを止めます。
delete protocols ospf area 0.0.0.0 interface ge-0/0/1.0

## IBGPの設定を行います。
set routing-options autonomous-system 1
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 1.1.1.2
set protocols bgp group IBGP neighbor 1.1.1.1
set protocols bgp group IBGP export BGP22

## IBGPに入れる経路は22.0.0.0/24だけとするポリシーを作ります。
set policy-options policy-statement BGP22 term 10 from route-filter 22.0.0.0/24 exact
set policy-options policy-statement BGP22 term 10 then accept
set policy-options policy-statement BGP22 term 999 then reject

commit
これで、firefly間でiBGPが張れていればいいですね。

lab@firefly1# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.2                   1        179        181       0       0     1:19:40 1/1/1/0              0/0/0/0

[edit]

経路も見てみます。

lab@firefly1# run show route protocol bgp

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

22.0.0.0/24        *[BGP/170] 01:03:49, localpref 100, from 1.1.1.2
                      AS path: I
                    > to 1.0.12.12 via ge-0/0/2.0

[edit]

22.0.0.0/24がBGPで伝播してきていることが分かります。

結果は?

root@ubuntu1:/home/lab# ping  22.0.0.10
PING 22.0.0.10 (22.0.0.10) 56(84) bytes of data.
64 bytes from 22.0.0.10: icmp_seq=1 ttl=62 time=12.7 ms
64 bytes from 22.0.0.10: icmp_seq=2 ttl=62 time=10.2 ms
64 bytes from 22.0.0.10: icmp_seq=3 ttl=62 time=13.2 ms
^C
--- 22.0.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.278/12.117/13.296/1.317 ms

正常にpingが届きました。

もう一声

Fireflyにトラフィック負荷をかけたいです。

そのためサーバに手を加えます。httpサーバとしてnginx、httpクライアントとしてApache-Benchをインストールします。ついでにubuntu上でトラフィックを可視化するためSpeedometerをいれます。

apt-get install -y nginx apache2-utils speedometer

 

httpサーバ

httpサーバのubuntu2ではnginxに10MBのファイルを置きます。以下のコマンドで10MBのファイルを生成できます。

dd if=/dev/urandom of=/usr/share/nginx/html/10m.html bs=1024 count=10000

この状態でトラフィックのグラフを表示させておきます。

speedometer1

httpクライアント

httpクライアントのubuntu1には以下のようなシェルスクリプトを設置しました。

ab.sh

#!/bin/sh

ulimit -n 40960

while :
do
        trap break 2
        ab -c 1000 -t 30  http://22.0.0.10/10m.html > /dev/null 2>&1
done

実行権限をつけます。

chmod 755 ab.sh

実行します。

speedometer2

TX方向つまりサーバが出す方向で24MB/sということなので8をかけて192Mbpsくらいのトラフィックが流れています。
検証なので192Mbps流れればまあ良いかなぁ、という気がします。(チューニングをする道もありますね)

今日はココまで。

関連記事

cloud-mon

改善していける監視を目指して 第一回

ネットワークG 平(ひら)です。 Bit-isle promptに記事を寄稿するにあたり、新し

記事を読む

awssummt

新入社員がAWSサミットに参加してきました。

こんばんは、最近配属が決まったばかりのビットアイル新入社員です。 先週7/17、18に品川で開

記事を読む

no image

誤解しがちなVMware等のHyper VisorのHAの期待効果

VMware 等の Hyper Visor の HA 冗長構成では MTBFを改善できない。

記事を読む

構成図

Softlayer Direct Link を smokeping で測ってみた ~その1 構成~

こんにちは。 ネットワークGの藤岡です。 昨年 IBM が Softlayer を買収したニ

記事を読む

techops

システム運用サービスで必要なこと

こんにちは。ビットアイルの 大野 です。 本日は ITシステムにおける一連のライフサイクルの中

記事を読む

構成図

Softlayer Direct Link を smokeping で測ってみた ~その2 インスタンスの作成~

こんにちは。 ネットワークGの藤岡です。 前回に引き続き Softlayer についての記事

記事を読む

kousei

Juniper FireFlyでJUNOSと仲良し

ネットワークG 南部です。 普段からネットワークに触れていることを楽しんでいるのですが、最近の

記事を読む

cloud-mon

改善していける監視を目指して 第二回

ネットワークG 平(ひら)です。 第一回では、主にクラウドサービスの状態監視(イベント監視)に

記事を読む

no image

ビットアイル・エクイニクスのエンジニアブログです。データセンターの最前線から様々な情報をお伝え致します。

構成図
Softlayer Direct Link を smokeping で測ってみた ~その2 インスタンスの作成~

こんにちは。 ネットワークGの藤岡です。 前回に引き続き So

構成図
Softlayer Direct Link を smokeping で測ってみた ~その1 構成~

こんにちは。 ネットワークGの藤岡です。 昨年 IBM が S

cloud-mon
改善していける監視を目指して 第二回

ネットワークG 平(ひら)です。 第一回では、主にクラウドサービ

cloud-mon
改善していける監視を目指して 第一回

ネットワークG 平(ひら)です。 Bit-isle prompt

ispっぽく
Juniper FireFlyでJUNOSと仲良し その2

ネットワークG 南部です。 前回は2台のubuntu間でping

→もっと見る

PAGE TOP ↑