2016年5月21日土曜日

3d party の SFP を使うときの注意点


■目的
Ciscoの純正SFPが高いので3d-partyのSFPを使おうと思った。

■内容
Cisco機器で普通に純正品ではないSFPを挿すと
%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port Gi2/1/1 has bad crc
%PM-4-ERR_DISABLE: gbic-invalid error detected on Gi2/1/1, putting Gi2/1/1 in err-disable state
といったエラーが出ることがあります。

■参考にさせて頂いたサイト
http://d.hatena.ne.jp/koyamartian/20110309/1299628777

純正のSFPを使わない場合は
(config)#no errdisable detect cause gbic-invalid
(config)#service unsupported-transceiver 
ってコマンドが物によって必要みたいです。

Aristaだとこのコマンド隠しコマンドになっていて
引数にライセンスネームとなんか入れないとダメみたい。
arista(config)#service unsupported-transceiver ?
  WORD  Licensee name

arista(config)#service unsupported-transceiver FINISAR ?
  8-digit hex number  Key to authorize unsupported transceivers

■終わり
ホワイトボックススイッチの時代になっていく傾向が見えるので今更感もありますが
まだまだCiscoやBrocade等のベンダー製品も沢山使われているので
SFPだけでも3d-partyの安い物で運用したいと思って試しました。
ただ保守が受けられるのか等はベンダーさんと調整が必要だと思います。

私の体験が誰かの生産性向上に役立っていただけることを祈って

2015年10月18日日曜日

sonarmanを試してみる

■目的
 パケットキャプチャでsonarmanというフリーソフトがあるというのを聞いたので試してみた。
特徴として基本垂れ流しでキャプチャを取っていて、特定のsyslogメッセージを受け取った際に
一つ前のファイルと現在のキャプチャファイルを保存してくれるというものらしい。

■参考にさせて頂いたサイト
http://develup-japan.co.jp/wp/works/sonarman-free-edition/
https://github.com/DevelUpJapan/Sonarman
■内容
上記参考にさせて頂いたサイトにフリー版があるのでそれをダウンロードしてインストールしてみる。
vmwareにとりあえずデプロイしてみたところとても簡単に使えた。

・DebianのOSで動いている
・eth0がDHCPで動いている
・OSのデフォルトパス:sonarman/sonarman
・キャプチャはwiresharkを使っている

vmwareでデプロイした際にeth0に接続するセグメントではDHCPを動かしていなかったためNIC設定をstaticに変更する
/etc/network/interface 内にあるeth0設定をstaticでIP割り振り
ifdown ifupでネットワーク設定を再起動した後にIPにwebアクセス

・webのデフォルトパス:admin/pass
web経由でキャプチャファイルをダウンロードできる
・webからNIC設定も変更できる
サイト自体はすごく簡素な作りになっていた。



受け取るsyslogメッセージはwebからは変更出来ない。
/home/sonarman/shells/swatchrc
の編集が必要

■終わり
データセンターのキャプチャを取り続けるというよりは、特定のサーバーの前にミラーポートを作り、
サーバーがsyslogを出したらキャプチャを退避する。
のような使い方が良さそうだと思った。

私の体験が誰かの生産性向上に役立っていただけることを祈って

2015年9月10日木曜日

LINEのスタンプ作ってみました②

■目的
 LINEのスタンプ 第二弾になります。#今回は宣伝です
茨城県はつくば市の非公認キャラ目指します。
筑波山に在来する福来みかんの「ふくれみかちゃん」です!
皆応援してね!

■内容
https://store.line.me/stickershop/product/1186181/ja



 LINEスタンプの作り方は第一弾を参照
http://activebrainlab.blogspot.jp/2015/05/line.html



■終わり
 実はこのふくれみかちゃん、3作品目なんです。
2作品目は別な奴があったのですが、Line側から規定違反で全部却下されました。
40個作ってからの全却下・・・恐ろしいですよ・・・
皆さん作る時には規定違反していないか注意しましょう。

来年のユルキャラグランプリ出たいな〜

私の体験が誰かの生産性向上に役立っていただけることを祈って

2015年8月13日木曜日

KVMのNIC設定に起因する障害対応

#久しぶりの更新です。最近バタバタしてました。
#Lineスタンプの製作も別途実施中です。

■目的
 とあるセキュリティアプライアンスのVNFソリューションを導入検証していたところ
一部の通信において通信出来たり出来なかったりの障害が発生していた。
以下切り分け結果を備忘録的に記載する

■前提
 HV:KVM
 ホストOS:CentOS7.0
 OpenStack:juno
 上記プライベートクラウド上で製品版のVNFソリューションを乗せ通信フローを経由させる

■不具合事象
 VNFソリューションを経由させる通信において、遅くなる。
HTTP通信であればリクエストタイムアウト、または数分後に画面表示される。
キャプチャによる切り分けでパケットの再送が見られた。

■原因と対策
・rx-checksumming: on
・tx-checksumming: on
・tcp segmentation offload: on
をoffにすることで解決

NICに処理をオフロードする機能のようだが、offにしても特に問題はなかった。
google先生で検索すると似たような事象の記事が見受けられた。
特に以下のサイトを参考させて頂きました。
http://blog.livedoor.jp/donuts_/archives/241014.html

以下のコマンドを実行することで対象のNICでオフロード機能を無効にした。
# ethtool -K eth0 rx off tx off tso off

■後日追記
恒久対策としてrc.localにも記載するのを忘れないようにする
http://extstrg.asabiya.net/pukiwiki/index.php?TSO(TCP%20Segmentation%20Offload)%A4%CE%CC%B5%B8%FA%B2%BD

■終わり
有効な場合、高負荷時にパケロスすることがあるということだが逆に無効にした場合に速度劣化等はしないのかが気になった。
SR-IOVとかを利用する場合にも似たような設定が必要になるのか頭の片隅に残しておこう。

私の体験が誰かの生産性向上に役立っていただけることを祈って

2015年6月8日月曜日

サーバー側でLLDPを有効にしてSWから情報を見てみる

■目的
 LLDPを利用してSWの先に繋がったサーバーの情報を確認することが出来るか試してみる。

■前提
 SW:お馴染みArista
 SV:ESXi6.0、KVM(CentOS7.0)

ESXi:6.0でLLDPを有効にしてみる。



操作でアドバタイズを指定する。
この状況でSW側からLLDPコマンドでどのように見えるか確認してみる。


Arista#sh lldp neighbors
Last table change time   : 11:56:10 ago
Number of table inserts  : 7
Number of table deletes  : 0
Number of table drops    : 0
Number of table age-outs : 0

Port       Neighbor Device ID             Neighbor Port ID           TTL
Et2        esx2.test.local          0050.565c.2f11             180

上記のように接続ポート先にSV側のホスト名が確認出来るようになった。

■KVM(CentOS7)でLLDPを有効にしてみる。
まずはLLDPをインストールする。
#yum install lldpad
================================================================================
 Package            Arch            Version                 Repository     Size
================================================================================
Installing:
 lldpad             x86_64          0.9.46-10.el7           base          256 k
Installing for dependencies:
 libconfig          x86_64          1.4.9-5.el7             base           59 k

Transaction Summary

================================================================================

②LLDPサービスをスタートさせて、再起動時も有効にしておく
 #systemctl start lldpad
 #systemctl enable lldpad

lldptool を使って設定を見てみる
 以下のようにサーバーのNICの先にいる接続先の「SW名」「SW-IP」「SW型番」等を確認することが出来る

# lldptool get-tlv -i ens1f0 -n
Chassis ID TLV
        MAC: XXXXXXXXXXX
Port ID TLV
        Ifname: Ethernet3
Time to Live TLV
        120
System Name TLV
        接続先SW名
System Description TLV
        Arista Networks EOS version 4.12.5.1 running on an Arista Networks DCS-7050T-52
System Capabilities TLV
        System capabilities:  Bridge, Router
        Enabled capabilities: Bridge, Router
Management Address TLV
        IPv4: 接続先SWIP
        Ifindex: 5000000
Port VLAN ID TLV
        PVID: 102
Link Aggregation TLV
        Aggregation capable
        Currently aggregated
        Aggregated Port ID: 1000003
Maximum Frame Size TLV
        9236
End of LLDPDU TLV

今回SVを2台用意し、一台は以下の設定を行う。
# lldptool set-tlv -i ens1f0 -V sysName enableTx=yes
 sysNameを有効にする。


Arista#sh lldp neighbors
Last table change time   : 11:56:10 ago
Number of table inserts  : 7
Number of table deletes  : 0
Number of table drops    : 0
Number of table age-outs : 0

Port       Neighbor Device ID             Neighbor Port ID           TTL
Et2       esx2.test.local             0050.565c.2f11            180
Et3        kvm1.test.local             2c76.8a5c.3780             120
Et4        2c76.8a5c.4041                 2c76.8a5c.4041             120

Et3はsysNameを有効にしたSVの為、SWtから見ると対向先のホスト名を確認することが出来る。
Et4はsysNameを有効にせずに単純にLLDPを有効にしただけである。

このようにSV側でLLDPを有効にすれば、SW側から対向先のSV情報を確認することが出来る。

■終わり
Ciscoの場合であればCDPと専用のプロトコルだが、LLDPはSVでも使うことが出来るので
自動構成図作成等で利用する事が可能である。

私の体験が誰かの生産性向上に役立っていただけることを祈って

2015年5月24日日曜日

LINEのスタンプ作ってみました

■目的
 LINEのスタンプを作ってみたかったので、地元のなんちゃってクリエイターと作成してみた。

■参考にさせて頂いた本
http://gihyo.jp/book/2014/978-4-7741-6684-1

■前提
・使用するペイントソフトはイラストレーター

■内容
 LINEスタンプの作り方を簡単に纏める。

■制作
①40個ネタを考える
②規定のサイズに合わせて絵と文字を入れる
③40個出来たら、タイトル用とサブメニュー用でさらに2つを規定のサイズで作る

■クリエイターズマーケットへの登録
https://creator.line.me/ja/
①クリエイターズマーケットでアカウントを作成する
②振込先情報を登録する
③作成した画像をアップロードする
④スタンプの説明を日本語文と英文の両方で作成する
⑤スタンプのアップロードが終わったら審査に回す。
⑥一度審査に出すと数日で審査中になる。
 今回缶コーヒーを持っている絵を入れたのだが、マークが某メーカーを彷彿とさせるという事で審査に回してから4日でリジェクト(差し戻し)された。
 対象の画像を修正し再度審査に回す。
⑦数日で審査中 → 1ヶ月で審査完了になった。
⑧メールで連絡が届くので販売開始ボタンを押すと数時間後にクリエイターズスタンプの新着に載る
https://store.line.me/stickershop/showcase/top_creators/ja

■販売後は
・統計情報等を見ることが出来るが、Twitterや友達に紹介してもらうのが良い。
★ポイント
・自身で作成したスタンプでも、クリエイターズスタンプから購入しないと使う事が出来ない。

■結果
https://store.line.me/stickershop/product/1130635/ja



■終わり
 初日10個程度しか売れなかったが、実績を残すことが出来て良かった。
次もまた作成してみようと思います。

私の体験が誰かの生産性向上に役立っていただけることを祈って

2015年4月25日土曜日

OpenStackのDHCPレンジ拡張

■目的
 ある日OpenStack環境でVMを作成しようとしたところエラーで作成出来なかった。
調べてみるとNetworkで払い出せるアドレスの上限に達していたのでアドレスレンジを拡張する。

■前提
・OpenStack ver:juno

■内容
①まずはVMが作れないエラー調査

コンピュートノードで

tail -f /var/log/nova/nova-compute.log 
しながらVM作成を実行。
エラーになるが以下のようなログが出た。
nova-compute 2015-04-23 19:30:05.549 10981 WARNING nova.network.neutronv2.api [-] [instance: 24cbdf14-c745-46c9-921a-31a71729555d] Neutron error: No more fixed IPs in network: dc1ca486-c896-47ef-a3c5-6fa89a0b4654

nova-compute 2015-04-23 19:30:05.550 10981 ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s)

No more fixed IPs in network:
ということでアドレスが枯渇している見たい。

②コントローラーノードで
[root@juno-controller01 ~]# . keystonerc_admin

[root@juno-controller01 ~(os_admin)]$
keystonerc_adminを読み込んでから

まずはneutron subnet-listでdhcpレンジを見てみる

[root@nfv-juno-controller01 ~(os_admin)]$ neutron subnet-list
+--------------------------------------+------+------------------+--------------------------------------------------------+
| id                                   | name | cidr             | allocation_pools                                       |
+--------------------------------------+------+------------------+--------------------------------------------------------+
| 0e7ebceb-758e-47aa-a1e8-65fe7bfc9404 |      | 192.168.210.0/24 | {"start": "192.168.210.1", "end": "192.168.210.253"}   |
| 201b876b-1d50-4b79-aeef-a04d8c0ffe48 |      | 192.168.205.0/24 | {"start": "192.168.205.1", "end": "192.168.205.253"}   |
| 247f6bf3-32f9-43ee-8dab-0620bb75e3e2 |      | 192.168.220.0/24 | {"start": "192.168.220.1", "end": "192.168.220.253"}   |
| 51148210-a9a3-46b6-a9d0-f9f496a5fdaa |      | 192.168.208.0/24 | {"start": "192.168.208.1", "end": "192.168.208.253"}   |
| 67b66355-7b26-447b-8e08-820ab5ee18f1 |      | 192.168.204.0/24 | {"start": "192.168.204.1", "end": "192.168.204.253"}   |
| 6b3cf7aa-c831-428d-a866-7373e0d63f71 |      | 192.168.255.0/24 | {"start": "192.168.255.151", "end": "192.168.255.170"} |
+--------------------------------------+------+------------------+--------------------------------------------------------+

192.168.255.0/24だけレンジが少ないのでこれを拡張する。
第4オクテット.181~200までを追加する。

しかしsubnet-updateのコマンド書式が分からないのでまずはヘルプ
[root@nfv-juno-controller01 ~(os_admin)]$ neutron help subnet-update
usage: neutron subnet-update [-h] [--request-format {json,xml}] [--name NAME]
                             [--gateway GATEWAY_IP] [--no-gateway]
                             [--allocation-pool start=IP_ADDR,end=IP_ADDR]
                             [--host-route destination=CIDR,nexthop=IP_ADDR]
                             [--dns-nameserver DNS_NAMESERVER]
                             [--disable-dhcp] [--enable-dhcp]
                             [--ipv6-ra-mode {dhcpv6-stateful,dhcpv6-stateless,slaac}]
                             [--ipv6-address-mode {dhcpv6-stateful,dhcpv6-stateless,slaac}]
                             SUBNET

Update subnet's information.

・・・

③以下の書式でコマンド実行してみる。
既存のアドレス分も記載して実行する
[root@nfv-juno-controller01 ~(os_admin)]$ neutron subnet-update --allocation-pool start=192.168.255.151,end=192.168.255.170 --allocation-pool start=192.168.255.181,end=192.168.255.200 6b3cf7aa-c831-428d-a866-7373e0d63f71

Updated subnet: 6b3cf7aa-c831-428d-a866-7373e0d63f71


もう一度見てみると
[root@nfv-juno-controller01 ~(os_admin)]$ neutron subnet-list
+--------------------------------------+------+------------------+--------------------------------------------------------+
| id                                   | name | cidr             | allocation_pools                                       |
+--------------------------------------+------+------------------+--------------------------------------------------------+
| 0e7ebceb-758e-47aa-a1e8-65fe7bfc9404 |      | 192.168.210.0/24 | {"start": "192.168.210.1", "end": "192.168.210.253"}   |
| 201b876b-1d50-4b79-aeef-a04d8c0ffe48 |      | 192.168.205.0/24 | {"start": "192.168.205.1", "end": "192.168.205.253"}   |
| 247f6bf3-32f9-43ee-8dab-0620bb75e3e2 |      | 192.168.220.0/24 | {"start": "192.168.220.1", "end": "192.168.220.253"}   |
| 51148210-a9a3-46b6-a9d0-f9f496a5fdaa |      | 192.168.208.0/24 | {"start": "192.168.208.1", "end": "192.168.208.253"}   |
| 67b66355-7b26-447b-8e08-820ab5ee18f1 |      | 192.168.204.0/24 | {"start": "192.168.204.1", "end": "192.168.204.253"}   |
| 6b3cf7aa-c831-428d-a866-7373e0d63f71 |      | 192.168.255.0/24 | {"start": "192.168.255.181", "end": "192.168.255.200"} |
|                                      |      |                  | {"start": "192.168.255.151", "end": "192.168.255.170"} |
+--------------------------------------+------+------------------+--------------------------------------------------------+
[root@nfv-juno-controller01 ~(os_admin)]$

192.168.255の.181~200が増えている。

■終わり
この状態で新規VM作成したところ問題なく作成できた。
最初はHDDが枯渇したのかと思ったがすんなり解決できてよかった。

私の体験が誰かの生産性向上に役立っていただけることを祈って