灰色のエンジニア

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日木曜日

＃久しぶりの更新です。最近バタバタしてました。
＃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が枯渇したのかと思ったがすんなり解決できてよかった。

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

2015年4月6日月曜日

AristaでのVRF設定

■目的
　Arista-SWでVRFの設定をしてみる。
基本的にCiscoと同じ設定なので備忘録として記載する。

■内容
以下コマンドでVRF設定が可能

①まずはvrfの定義をする
vrf definition vrf1
rd 65000:1

vrf definition vrf2
rd 65000:2

②インターフェースVLANにVRFの指定をする
interface Vlan301
vrf forwarding vrf1
ip address 30.0.1.254/24

interface Vlan401
vrf forwarding vrf2
ip address 40.0.1.254/24

③VRF指定でルーティングを記載する
ip route vrf vrf1 40.0.1.0/24 30.0.2.1
ip route vrf vrf2 30.0.1.0/24 40.0.12.1

④IProutingでvrfの指定をする
ip routing
ip routing vrf vrf1

ip routing vrf vrf2

①Arista#sh vrf

  Vrf        RD            Protocols       State      Interfaces
---------- ------------- --------------- ------------- -------------------
   vrf1       65000:1       ipv4            routing    Vlan301, Vlan302,
                                                       Vlan303, Vlan304,
                                                       Vlan305,
   vrf2       65000:2       ipv4            routing    Vlan401, Vlan402,
                                                       Vlan403, Vlan404,
                                                       Vlan405,

test-arista#sh ip route vrf vrf1
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary

Gateway of last resort is not set

 C      30.0.1.0/24 is directly connected, Vlan301
 C      30.0.2.0/24 is directly connected, Vlan302
 C      30.0.3.0/24 is directly connected, Vlan303
 C      30.0.4.0/24 is directly connected, Vlan304
 C      30.0.5.0/24 is directly connected, Vlan305
 S      40.0.11.0/24 [1/0] via 30.0.12.1, Vlan312
 S      40.0.21.0/24 [1/0] via 192.168.207.250, Vlan2007

test-arista#sh ip route vrf vrf2
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary

Gateway of last resort is not set

 S      30.0.1.0/24 [1/0] via 40.0.12.1, Vlan412
 S      30.0.11.0/24 [1/0] via 40.0.12.1, Vlan412
 S      30.0.21.0/24 [1/0] via 192.168.203.250, Vlan2003
 C      40.0.1.0/24 is directly connected, Vlan401
 C      40.0.2.0/24 is directly connected, Vlan402
 C      40.0.3.0/24 is directly connected, Vlan403
 C      40.0.4.0/24 is directly connected, Vlan404
 C      40.0.5.0/24 is directly connected, Vlan405

test-arista#ping vrf vrf2 192.168.204.1
PING 192.168.204.1 (192.168.204.1) 72(100) bytes of data.
^C
--- 192.168.204.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

test-arista#ping vrf vrf2 192.168.204.254
PING 192.168.204.254 (192.168.204.254) 72(100) bytes of data.
80 bytes from 192.168.204.254: icmp_req=1 ttl=64 time=0.065 ms
80 bytes from 192.168.204.254: icmp_req=2 ttl=64 time=0.016 ms
80 bytes from 192.168.204.254: icmp_req=3 ttl=64 time=0.014 ms
80 bytes from 192.168.204.254: icmp_req=4 ttl=64 time=0.017 ms
80 bytes from 192.168.204.254: icmp_req=5 ttl=64 time=0.012 ms

--- 192.168.204.254 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.012/0.024/0.065/0.021 ms, ipg/ewma 0.056/0.044 ms
test-arista#

■終わり

Ciscoとほぼ一緒

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

Arista-SWでのVerUP

■目的
　Arista-SWでのVerUP方法を記載する。
CiscoのIOSと違い、AristaのEOSは容量が大きいためtftpではなくFTPを使ったファイル転送を使う。

■前提
・VerUPするAristaのEOSは事前にPC上にダウンロードしておく
・PCでFTPサーバーを立てておく
・AristaにIPを振ってVLANの割り当てをし、PCとArista間で疎通出来る事を確認する。

■内容
①Arista-SWで新しいに空き容量がある事を確認する
②copyコマンドでEOSをAristaに送る
③boot configで次回起動時のEOSを新しいEOSに指定する。
④再起動

①Arista#sh version

Arista DCS-7150S-24-F
Hardware version:    01.00
Serial number:       XXXXXXXXXXXXX
System MAC address:  XXXXXXXXXXXXX

Software image version: 4.12.3
Architecture:           i386
Internal build version: 4.12.3-1352018.EOS4123
Internal build ID:      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Uptime:                 6 weeks, 2 days, 19 hours and 26 minutes
Total memory:           4017112 kB
Free memory:            1980076 kB

以下のcopyコマンドでAristaのFlash内にOSを入れる。・事前にdir flash:で空き容量があることを確認する。・ftpのアカウントを作成しておく ②Arista#copy ftp://test:test@192.168.1.1/EOS-4.12.5.1.swi flash: errorと出ずに以下のように転送が始まっていればOK `EOS-4.12.5.1.swi' at 202073552 (48%) 2.13M/s eta:95s [Receiving data]

転送が終わったらdir flash:でOSが転送出来ていることを確認する。

＃Arista#dir flash:

Arista#dir flash:
Directory of flash:/

       -rwx   408036210           Jul 18 01:49  EOS-4.12.3.swi
       -rwx   413508508           Dec 19 15:41  EOS-4.12.5.1.swi
       -rwx          24            Aug 1 02:04  boot-config
       drwx        4096           Nov 12 01:12  debug
       -rwx           0            Aug 1 02:05  fullrecover
       drwx        4096           Nov 12 01:10  persist
       drwx        4096           Aug 23 18:42  schedule
       -rwx        2698           Dec 26 00:20  startup-config
       -rwx          13           Nov 12 01:09  zerotouch-config

1769799680 bytes total (537268224 bytes free)

次にboot-configを確認する。

Arista#show boot-config

Software image: flash:EOS-4.12.3.swi

Console speed: (not set)

Aboot password (encrypted): (not set)

Memory test iterations: (not set)

次回起動時に新しいOSで上がってくるように以下コマンドで転送したOSを指定する。

③Arista(config)#boot system flash:^VEOS-4.12.5.1.swi

Arista#show boot-config

Software image: flash:/EOS-4.12.5.1.swi

Console speed: (not set)

Aboot password (encrypted): (not set)

Memory test iterations: (not set)

この状態で再起動すれば新OSで上がってくる。

■終わり

容量が大きいのもあるがFTP接続であればTCPコネクションを張るので信頼性は高くなったので良いかな

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

登録: 投稿 (Atom)

灰色のエンジニア

2015年9月10日木曜日

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

2015年8月13日木曜日

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

2015年6月8日月曜日

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

2015年5月24日日曜日

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

2015年4月25日土曜日

OpenStackのDHCPレンジ拡張

2015年4月6日月曜日

AristaでのVRF設定

Arista-SWでのVerUP

ブログアーカイブ