ZOOT NATIVEを使ってみることに

この頃どうもネットワークの接続が遅いと感じることが多く、また、プロバイダ間接続におけるIPoE接続というのを経験したことがなく、実際どう接続していくのかを確認するべく、InterlinkのZOOT NATIVE接続に申し込みを行った。

そして、現行環境の制約上、機器はFujitsu Si-R G200で行うことになりました。

実態としてはIPIPトンネル張るだけ

まずはInterlinkのサイトページから、自身の会員IDとパスワードを用いてZOOT NATIVEに契約をします。その際、フレッツ契約を結んだ際に渡されるIDとセキュリティーキーを入力する必要がありますので、契約の控えなどを持っておくとマルかなと。
私の場合、クレジット支払いにしていたので、手続きは自動的に進められ、恐らくは1時間程度でInterlink側で必要となる作業は完了するようです。実はこの時、NGN側から渡されるPrefixが変更されるので注意が必要です。私のところではHomenocとの接続が切れてしまいました。これについては、Homenoc担当者さんへ連絡し、こちらの変更されたIPv6アドレスを伝えることで復旧しています。
さて、次に設定の話になるわけですが、YAMAHAのコンフィグサイトやIPoE接続をした人のブログ記事など色々参考にさせていただいたんだけど、結論としては「単純にIPIPトンネルを引くだけ」だったという。
残念ながら今回使用しているFujitsuルーターの直接的な参考になる情報はなかったため、若干の応用力は必要になりました。

今回の構成

Si-Rの設定

Si-R G200のコンフィグはSi-R第1世代の機種と比較してかなり癖が変わっているので、以前のSi-Rを使用している人には色々難を感じるところもあるかもしれないんだけど、慣れてみれば少し他社機種に寄せた動作をするところもあるのかなと感じていて、むしろ使いやすくなるんじゃないかなぁと言う気がする。

また、Si-Rで変わってる設定要素として、Bridge Groupと言う考え方がある。
L2フレームを直接渡せる範囲をグループ化できるのだけど、この考えは少々WindowsやMikroTik製品で使われるROSに似たところなんじゃないかなーと勝手に思っていたりする。

その他変わってるなぁと感じるところは

• 基本的に1行で一気に書き上げる文法であり、コマンド階層はそんなにない
• コマンド階層それ自体は恐らくYAMAHAルーターに似ている
• 設定確定はCommitが必要。このあたりはJunosっぽい。
• 未反映ConfigはCandidate-configとして確保されており、Running-configは反映後のコンフィグ。このあたりもなんだかjunosっぽい。

インタフェースの設定

インタフェースはG200の場合、1/1-2、2/1-8と言う形で大きく分けて2系統構成されている。
これに対してVLAN IDを割り当てる形で、インタフェースとVLANの対応付けを行う。

ether 1 1 vlan untag 784
ether 1 2 vlan untag 785
ether 2 1 vlan untag 788
ether 2 2 vlan untag 788

Si-R第1世代だとetherに直接IPアドレスを割り当てたり、Bridge Groupを割り当てたりするのだけど、G200では以下のようにVLANに対してBridge Groupを適用している。
もちろん、従来モデルと同様にSTPを動かすことも出来る。

stp mode stp
vlan 10 bridgegroup use on
vlan 10 bridgegroup group 2
vlan 785 bridgegroup use on
vlan 785 bridgegroup group 3
vlan 788 bridgegroup use on
vlan 788 bridgegroup group 1

lanインタフェースも同様で、etherに対して割り当てるのではなく、VLANに割り当てるようになってるみたい。
今回の構成では、NGN(ひかり電話なし）パターンを使用するため、ipv6の末尾部分を固定するため、ifid指定をlan0に対して行っている。

lan 0 ipv6 use on
lan 0 ipv6 ifid 0:0:0:2
lan 0 ipv6 address 0 auto
lan 0 ipv6 ra mode recv
lan 0 vlan 784

lan1はNGNでトンネルされたL2フレームを流すだけであるため、VLANの紐付けしか行っていない。
lan2及びlan3については、IPv4のみを通す想定で、IPアドレスの指定を行っている。 必要に応じて内部セグメントに対するルーティングを流す必要もあるが、ここでは割愛。
ルーティングは内部で転がすならIGP設定などを入れて動的制御するのも一つの手。

lan 1 vlan 788
lan 2 ip address <内部セグメントIP>/<サブネットPrefix長> 3
lan 2 vlan 10
lan 3 ip address /<サブネットPrefix長> 3
lan 3 vlan 785

IPoEトンネルの設定

今回、NGNを通じて追加するremoteインタフェースはいずれもIPoEであるため、トンネルを構成する形になる。

まずHomenocの堂島POPとの接続が以下の通り。
張ったトンネルはVLAN 788とバインドし、これをBridgeGroup 1に渡す形になっている。 こうすることで、同一ブリッジにつなげたフレームをVLAN788に流すことが出来るようになる。

remote 0 name homenoc
remote 0 ap 0 name doujima
remote 0 ap 0 datalink type ip
remote 0 ap 0 datalink bind vlan 788
remote 0 ap 0 keep connect
remote 0 ap 0 tunnel local <こちらのNGNアドレス>
remote 0 ap 0 tunnel remote <対向のNGNアドレス>
remote 0 ip msschange 1404
remote 0 ipv6 use on
remote 0 bridgegroup use on
remote 0 bridgegroup group 1

INTERLINK ZOOT NATIVE接続用トンネルが以下の通り。
EtherIPとIPIPトンネルの違いがいまいちわかってないんだけど、いずれにしてもL2フレームをトンネル経由で流す構成になる。VLAN 785にバインドし、Bridge Group3へ通すことにより、Homenocと同様に構成するに加えて、デフォルトゲートウェイ設定を入れることで、トンネルインタフェースをデフォルトゲートウェイに強制することが出来るようになる。

remote 1 name ilink
remote 1 ap 1 name mfeed
remote 1 ap 1 datalink type ip
remote 1 ap 1 datalink bind vlan 785
remote 1 ap 1 keep connect
remote 1 ap 1 tunnel local <こちらのNGNアドレス>
remote 1 ap 1 tunnel remote <対向のNGNアドレス>
remote 1 ip route 0 default 1 1
remote 1 ip msschange 1404
remote 1 ipv6 use on
remote 1 bridgegroup use on
remote 1 bridgegroup group 3

Bridge Groupルーティング設定

各Bridge GroupでIPv4/IPv6のルーティングを有効にするかどうかを設定する箇所。

bridgegroup 0 ip routing off
bridgegroup 1 ip routing off
bridgegroup 1 ipv6 routing off
bridgegroup 2 ipv6 routing off
bridgegroup 3 ipv6 routing off

ACL設定

今回、ACL設定はTELNETやHTTP/HTTPS/FTP等のサービスに対して仕掛ける。中継パケットに対してはとやかく言わない方針で組んでいる。

acl 0 ip <内部ネットワーク> any any any
acl 1 ipv6 <内部ネットワーク(IPv6)> any any any
acl 2 ip <内部ネットワーク> any any any
acl 3 ipv6 <外部許可ネットワーク1> any any any

serverinfo ftp filter 0 accept acl 0
serverinfo ftp filter 1 accept acl 1
serverinfo ftp filter 2 accept acl 2
serverinfo ftp filter default reject

serverinfo telnet filter 0 accept acl 0
serverinfo telnet filter 1 accept acl 1
serverinfo telnet filter 2 accept acl 2
serverinfo telnet filter default reject

serverinfo ssh filter 0 accept acl 0
serverinfo ssh filter 1 accept acl 1
serverinfo ssh filter 2 accept acl 2
serverinfo ssh filter default reject

serverinfo http filter 0 accept acl 0
serverinfo http filter 1 accept acl 1
serverinfo http filter 2 accept acl 2
serverinfo http filter default reject

SNMPサービスの設定箇所

snmp service enable
snmp agent sysname nigauri
snmp agent ip address <こちらのルーターアドレス>
snmp manager 0 <監視サーバA> v2c enable
snmp manager 1 <監視サーバB> v2c enable

Syslog転送設定

syslog server 0 address <ログサーバIP>
syslog server 0 pri error,warn,notice
syslog pri error,warn,notice
syslog facility 23
syslog source ip address <こちらのルーターアドレス>

時刻同期設定

time auto server  sntp
time auto interval 1h
time zone 0900

その他諸設定

resource system vlan 4084-4094
consoleinfo autologout 8h
telnetinfo autologout 5m
sysdown harderr fan yes
sysdown harderr thermal yes
sysname
terminal pager enable
terminal charset SJIS
alias history "show logging command brief"

実際速度はどうだったか？

仮想クライアントで速度計測を行いました。(物理クライアント端末だとWifiを通るので、その速度劣化が出てあんまり差が出ませんでした)

片方はPPPoE接続、もう片方はIPoE接続。IPoE接続により130Mbpsまで向上させることが出来るようになりました。
Sophos UTMでガッツリIPSなどを動かしている関係上、ある程度のオーバーヘッドが発生していることは推測されるのですが、それでも応答速度がpingベースで15msまで下がったのは感動でした。それも15msってのがGoogle Public DNS相手にってのがいいですね。

ただ、IPoEはCGNを必ず通る性質上、固定IPを取得することができないため、自宅サーバには向かず、あくまでクライアント端末向けのアクセス経路にはなります。とは言え、両方契約するのもありでしょうし、異なるプロバイダを採用するというのもありでしょうし、選択肢は広がったと言えるのではないでしょうか。

終わりに

PPPoEだとONUの許容するセッション数に依存するところが、IPoEですとルーターのTunnel対向数に依存する形になるので、そういう意味でも回線利用の幅が広がるのかなーと思いました。今までの接続方式(PPPoE)と比較するとちょっと「？」と感じるところもそれなりに出てくるんですが、そこはお勉強対象ということで、も少し深く学べばそれはそれで面白いんじゃないかとも。何にしても今回も良い勉強になったと思います。