ネットワーク

VRFでネットワーク構築

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - VRFでネットワーク構築
このエントリーをはてなブックマークに追加
はじめまして。ネットワーク事業部のokuです。

「仮想化」というキーワードから連想する物にVMwareやXenなどあると思いますが、今回は少しレイヤを下げて、ネットワークの仮想化について書きたいと思います。これはVLAN(Virtual LAN)だけではなく、VRF(Virtual Routing and Forwarding)も使って社内ネットワークを論理的に分けた時のお話です。



■背景


もともとlivedoorのオフィス拠点は都内2箇所に別れていました。
データセンターを中心とした活動を行う事業拠点と、主にポータルサイトのコンテンツ開発を行う事業拠点です。もちろん、この2拠点は専用線で接続し、互いにイントラ通信を可能としていましたが、業務特性の違いがあるため、運用ポリシーを別とし、物理的には分けたネットワークを構築していました。
(データセンター拠点を含んでいませんが、ここでは割愛します)


Topo-old
構成図 - 1


しかしビデオ会議システムを導入する程の拠点数と距離ではなく、会議の度に移動していた偉い人達は面倒になったのでしょうか(いや、もちろん違う理由だと思いますが)、2009年秋に、この2拠点が集約される事になりました。

そこで、新オフィスのイントラ構成を考えていた時にあがった議題が、デフォルトゲートウェイの問題です。



■検討


"構成図-1"の通り、以前は拠点ごとにゲートウェイ装置を設置していた為、オフィスの端末からインターネットに出ていく際のソースIPアドレスは、拠点ごとで異なりました。

一般企業の場合、ソースIPアドレスが何であろうと、さほど問題にはならないかと思います。しかしlivedoorの場合、ソースIPアドレスが変更になると、複数箇所で設定変更が必要になる事が予め分かっていました。インターネット上の管理サーバに、ソースIPアドレスでのアクセス制限を適用しているからです。

解決策として次の案を検討しました。

o 設定変更の手間はあきらめて、ゲートウェイ装置を集約?

やはり手間がかかるので、できれば別の方法で…

o ゲートウェイ装置は集約して、管理サーバにアクセスしたい場合はVPN?

業務の度に、VPN経由でアクセスするのも面倒…

o 新オフィス内でも物理的に分けたネットワークを構築する?

物理機器が増え過ぎるのも…
ハードウェアの保守費用もばかになりませんし…

o VRF?

ソースIPアドレスが維持できる Good!!
サーバ側の設定変更がいらない Good!!
物理的には最少構成で構築できる Good!!

しかし、VRF社内での運用実績はないため多少の不安(機能としての不安ではなく、今後運用していけるかどうかという不安)がありましたが、現時点での問題点を全て解決してくれるVRFを使って構築する事にしました。

★VRF(Virtual Routing and Forwarding) について
VRFの技術概要については、Googleやlivedoor等で検索して頂ければと思いますが、1台の物理装置内に、論理的に分離された複数のルーティングテーブルを保持し、各ルーティングテーブルに従ってパケット転送が行われる機能だと理解しています。
VRF自体はもともと、ISPのMPLS網などで利用されている機能であり、新しい技術ではないのですが、いくら企業内ネットワークに使用したいと考えても、VRF(もといMPLS)を実装するルータは非常に高価(家が買えるくらい…)で、イントラネットの為に購入できる金額ではありません。しかし、現在はメーカー問わず比較的安価なL3スイッチでもVRFが使えるようになってきているので、今回のような、

o クライアントによってデフォルトゲートウェイを分けたい

(クライアントによって参照するルーティングテーブルを分けたい)
o 物理構成は最少にしたい

といった要件を実現する場合には、非常に便利な機能です:)



■ 設定


概要構成とConfiguration内容です。
今回は、Router-AとRouter-BにてVRFを動かしてみました。
機種は、Cisco Catalyst 3650シリーズです。


Topo-new

構成図 - 2


* 補足
Native は Router-A、VRF Buser はRouter-Cにてデフォルトルートを生成し、OSPFで再配信しています。

【Router-Aの設定内容】(抜粋)

★ VRFの定義 ※今回は旧B拠点ネットワークをVRFのインスタンスとして定義
!
ip vrf Buser
!
★ loopback は、NativeとVRF、それぞれで設定
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface Loopback1
ip vrf forwarding Buser
ip address 10.0.255.1 255.255.255.255
!
★ ゲートウェイ装置向けの物理インターフェース
!
interface FastEthernet0/1
description "Gateway-A"
switchport access vlan 50
switchport mode access
!
★ Router-B 向けの物理インターフェース
!
interface GigabitEthernet0/1
description "Router-B"
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
!
★ Router-C 向けの物理インターフェース
!
interface GigabitEthernet0/2
description "Router-C"
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,40
switchport mode trunk
!
★ Router-A〜Router-B間の接続用 interface vlanを、NativeとVRF、それぞれで設定
!
interface Vlan10
description "Router-B-Native"
ip address 10.0.10.253 255.255.255.252
!
interface Vlan20
description "Router-B-VRF-Buser"
ip vrf forwarding Buser
ip address 10.0.20.253 255.255.255.252
!
★ Router-A〜Router-C間の接続用 interface vlanを、NativeとVRF、それぞれで設定
!
interface Vlan30
description "Router-C-Native"
ip address 10.0.30.253 255.255.255.252
!
interface Vlan40
description "Router-C-VRF-Buser"
ip vrf forwarding Buser
ip address 10.0.40.253 255.255.255.252
!
★ Router-A〜Gateway間の接続用 interface vlanを作成
!
interface Vlan50
description "Router-C-Native"
ip address 10.0.50.2 255.255.255.252
!
★ Native サーバ収容 interface vlanを作成
!
interface Vlan100
description "vlan100-Native"
ip address 10.0.100.1 255.255.255.0
!
★ NativeとVRF、それぞれでOSPFを動かす
!
router ospf 1
router-id 10.0.0.1
log-adjacency-changes
default-information originate
passive-interface Vlan100
network 10.0.0.1 0.0.0.0 area 0
network 10.0.10.253 0.0.0.0 area 0
network 10.0.30.253 0.0.0.0 area 0
network 10.0.50.2 0.0.0.0 area 0
network 10.0.100.1 0.0.0.0 area 0
!
router ospf 2 vrf Buser
router-id 10.0.255.1
log-adjacency-changes
network 10.0.20.253 0.0.0.0 area 0
network 10.0.40.253 0.0.0.0 area 0
network 10.0.255.1 0.0.0.0 area 0
!
!
★ Native 用の default route を設定
!
ip route 0.0.0.0 0.0.0.0 10.0.50.1
!
!


【Router-Bの設定内容】(抜粋)

★ VRFの定義
!
ip vrf Buser
!
★ loopback は、NativeとVRF、それぞれで設定
!
interface Loopback0
ip address 10.0.0.2 255.255.255.255
!
interface Loopback1
ip vrf forwarding Buser
ip address 10.0.255.2 255.255.255.255
!
★ Router-A 向けの物理インターフェース
!
interface GigabitEthernet0/1
description "Router-A"
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
!
★ Router-A〜Router-B間の接続用 interface vlanを、NativeとVRF、それぞれで設定
!
interface Vlan10
description "Router-A-Native"
ip address 10.0.10.254 255.255.255.252
!
interface Vlan20
description "Router-A-VRF-Buser"
ip vrf forwarding Buser
ip address 10.0.20.254 255.255.255.252
!
★ Native ユーザ収容用 interface vlanを作成
!
interface Vlan101
description "vlan101-Native"
ip address 10.0.101.1 255.255.255.0
!
interface Vlan102
description "vlan102-Native"
ip address 10.0.102.1 255.255.255.0
!
★ VRF ユーザ収容用 interface vlanを作成
!
interface Vlan201
description "vlan201-VRF-Buser"
ip vrf forwarding Buser
ip address 10.0.201.1 255.255.255.0
!
interface Vlan202
description "vlan201-VRF-Buser"
ip vrf forwarding Buser
ip address 10.0.201.1 255.255.255.0
!
★ NativeとVRF、それぞれでOSPFを動かす
!
router ospf 1
router-id 10.0.0.2
log-adjacency-changes
passive-interface Vlan101
passive-interface Vlan102
network 10.0.0.2 0.0.0.0 area 0
network 10.0.10.254 0.0.0.0 area 0
network 10.0.101.1 0.0.0.0 area 0
network 10.0.102.1 0.0.0.0 area 0
!
router ospf 2 vrf Buser
router-id 10.0.255.2
log-adjacency-changes
passive-interface Vlan201
passive-interface Vlan202
network 10.0.20.254 0.0.0.0 area 0
network 10.0.201.1 0.0.0.0 area 0
network 10.0.202.1 0.0.0.0 area 0
network 10.0.255.2 0.0.0.0 area 0
!



■ 結果


Router-Bのルーティングテーブルを確認

【Native側】

Router-B#sh ip route

Gateway of last resort is 10.0.10.253 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
C 10.0.0.2/32 is directly connected, Loopback0
O 10.0.0.1/32 [110/2] via 10.0.10.253, 00:15:43, Vlan10
O 10.0.60.0/30 [110/7] via 10.0.10.253, 00:15:43, Vlan10
O 10.0.50.0/30 [110/2] via 10.0.10.253, 00:15:43, Vlan10
O 10.0.100.0/24 [110/2] via 10.0.10.253, 00:15:43, Vlan10
O 10.0.40.252/30 [110/7] via 10.0.10.253, 00:15:43, Vlan10
O 10.0.20.252/30 [110/8] via 10.0.10.253, 00:15:43, Vlan10
O 10.0.30.252/30 [110/2] via 10.0.10.253, 00:15:44, Vlan10
O 10.0.255.1/32 [110/8] via 10.0.10.253, 00:15:44, Vlan10
O 10.0.255.2/32 [110/9] via 10.0.10.253, 00:15:44, Vlan10
C 10.0.10.252/30 is directly connected, Vlan10
O*E1 0.0.0.0/0 [110/12] via 10.0.10.253, 00:15:44, Vlan10


【VRF側】

Router-B#sh ip route vrf Buser

Gateway of last resort is 10.0.20.253 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
O 10.0.0.2/32 [110/9] via 10.0.20.253, 00:16:11, Vlan20
O 10.0.0.1/32 [110/8] via 10.0.20.253, 00:16:11, Vlan20
O 10.0.60.0/30 [110/7] via 10.0.20.253, 00:16:11, Vlan20
O 10.0.50.0/30 [110/8] via 10.0.20.253, 00:16:11, Vlan20
O 10.0.100.0/24 [110/8] via 10.0.20.253, 00:16:11, Vlan20
O 10.0.40.252/30 [110/2] via 10.0.20.253, 00:16:11, Vlan20
C 10.0.20.252/30 is directly connected, Vlan20
O 10.0.30.252/30 [110/7] via 10.0.20.253, 00:16:12, Vlan20
O 10.0.255.1/32 [110/2] via 10.0.20.253, 00:16:12, Vlan20
C 10.0.255.2/32 is directly connected, Loopback1
O 10.0.10.252/30 [110/8] via 10.0.20.253, 00:16:13, Vlan20
O*E1 0.0.0.0/0 [110/12] via 10.0.20.253, 00:16:13, Vlan20

上記の通り、同じ経路向けの宛先アドレスも、それぞれ異なるアドレスを学習しています。

インターネット向けの traceroute を確認

Router-B#traceroute 203.131.***.***

Type escape sequence to abort.
Tracing the route to 203.131.***.***

1 10.0.10.253 0 msec 0 msec 0 msec
2 10.0.50.1 0 msec 0 msec 0 msec
3 203.131.***.*** 0 msec 0 msec 9 msec
4 203.131.***.*** 0 msec 0 msec 8 msec

Router-B#traceroute vrf Buser ip 203.131.***.***

Type escape sequence to abort.
Tracing the route to 203.131.***.***

1 10.0.20.253 0 msec 0 msec 0 msec
2 10.0.40.253 0 msec 0 msec 0 msec
3 10.0.60.1 0 msec 0 msec 0 msec
4 203.174.***.*** 8 msec 9 msec 0 msec
5 203.131.***.*** 8 msec 0 msec 8 msec


それぞれ別の経路でインターネットにでている事が確認できました。



■ 終りに


VRF自体の設定は結構簡単にできますが、こと運用面に関しては、VRFという依存関係が加わる事によってネットワークが複雑化するため、障害時の事を考えると、それはそれで悩ましかったりします。

しかし某展示会ネットーワークモデルのように、VRFを使うと、同じ物理網を使って用途別に、容易に、ネットワークを構築する事ができるので、今後は(要望があれば)、検証用、IPv6用、人事用など、VRFの追加をおこなって、運用ノウハウをためていきたいと思います。VRF、おすすめです:)

ライブドアの無線LAN ログインのしくみ

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - ライブドアの無線LAN ログインのしくみ
このエントリーをはてなブックマークに追加
こんにちは、コアネットワークグループの深谷です。
今回はlivedoor Wirelessのお話をしようと思います。


ライブドアの無線LANを使う

livedoor Wirelessは、アクセスポイントの第1号機が設置されてから早4年が過ぎました。このサービスが始まった頃、私は無線LANにノートパソコンで接続して利用していましたが、現在ではいろいろな機器が無線LANに繋げられるようになりました。

さて、ライブドアの無線LANを使うには、livedoor Wirelessへユーザ登録して頂く方法のほかに、livedoor Wirelessがローミング提携しているユーザIDも利用することができます。現在、livedoor Wirelessでは6社とローミング提携しており、ローミング提携先で発行されたログインIDを利用してlivedoor Wirelessをご利用頂いている方も増えてきています。

次のグラフは2006年から2009年のそれぞれ7月度のウェブ認証でログインしたID数です。2008年からローミング提携先で発行されたログインIDでの接続が増えていますね。




ローミング

ところで、どのようにしてローミング提携先で発行されたログインIDを利用してlivedoor Wirelessへログインできるかご存知でしょうか?簡単に見てみましょう。大まかにまとめると次の図のようなイメージです。(画像をクリックすると大きい画像が現れます)

ローミングの画像

まず、ユーザがウェブ認証画面からログインIDとパスワードを入力してログインボタンを押すと、認証をコントロールするシステム(以下認証システム)がそれを受け取ります。ログイン情報を受け取った認証システムからRADIUDSへ、送られてきたログイン情報が登録されているものであるかを問い合わせる(以下認証リクエスト)のですが、その前にRADIUSのProxy機能(以下RADIUS Proxy)を利用して、送られてきたログイン情報はどのRADIUSに確認すべきかの振り分けを行います。RADIUS ProxyにはログインIDの@より右側の情報(以下レルム)と問い合わせるRADIUSの情報があらかじめ紐づいて登録されています。この登録情報からどのRADIUSに問い合わせるかを決定し、認証リクエストを対象のRADIUSへ転送しています。

認証リクエストを受け取ったRADISUは、登録されたユーザか否かを判断して認証リクエストに返答を返します。返答を受け取った認証システムは、認証がSuccessの場合にはアクセスポイントへのユーザ接続などを制御している機器(以下コントローラ)へ対象ユーザのインターネットへの接続を許可するようにリクエストを投げ、コントローラが許可をすると、めでたくユーザはインターネットを利用することが出来るわけです。

ローミング提携先によってはiPassが公開しているGeneric Interface Specification(GIS)やWi-Fi AllianceのWISPrのガイドラインのように、クライアントと認証システム間のやり取りを共通の様式(XML)を利用してログイン処理を行う方法もありますが、この場合もRADIUSやコントローラは前述と同じような処理を行っています。


まとめ

いろいろな端末が無線LANに対応してきている今日この頃、ライブドアで設置しているアクセスポイントたちが、より便利にご利用いただけるように努力してまいります。今後ともlivedoor Wirelessをよろしくお願いいたします。

tracerouteの仕組み

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - tracerouteの仕組み
このエントリーをはてなブックマークに追加
ネットワーク事業部 コアネットワークグループ所属の市川です。普段は、広域ネットワークの管理をしていて、端末に向かっていても頭の中は、1都3県を飛び回っています。

好きなポートは何番ですか?


入社後エンジニア部隊に配属され、隣に座っていた同僚に挨拶をした時の返しの第一声が忘れられません。

「好きなポートは何番ですか?」

これって自己紹介なのでしょうか...それとも好きなポート番号から僕の性格が分かっちゃったりするんでしょうか?ところで、みなさんの好きなポートは何番でしょうか?ちなみにボクは、23番が好きでした(笑)。さて、私は現在ネットワーク事業部でネットワーク管理の仕事をしております。ネットワークにトラブルが発生した場合、状況調査に利用するツールでもっともメジャーな物に、ping/traceroute(windowsではtracert.exe)があります。



このtracerouteの仕組みはご存知でしょうか。私は初めてその仕組みを知った時、感激しました。このようなアイディアあふれるツールは大好きです。今回は、知ってる人は知ってるが、知らない人は知らないtracerouteの仕組みと各OS付属の物の実装、そしてIP TTLの落とし穴についてご紹介します。

[仕組み] IP TTL


tracerouteの実装は、ツールによって様々ではありますが基本的な仕組みは同じです。IPパケットのヘッダはご存知の事と思います。(下図参照)



あて先アドレス、送信元アドレス、優先度フラグ等に混じって、TTLという値があります。tracerouteは、このTTLをうまく利用し、パケットがどのような経路を通り宛先へ届いているのか?を調査する為のツールです。
TTLとは、Time To Liveの略で、そのパケットの寿命を表しています。パケットが転送されるたびに値が「1」減らされていき、「0」になったらそのパケットの死亡通知が送信元ホストへ送られます。

上の仕組みを使うと...
TTL=1 で送信
→ 1 hop先のホストからパケットの死亡通知が届く
TTL=2 で送信
→ 2 hop先のホストからパケットの死亡通知が届く
...
...
TTL=n で送信
→ n hop先のホストからパケットの死亡通知が届く

これらの死亡通知コレクションを順番に並べると、パケットがどのような経路を通り相手まで届くのかを知ることができるんですね。tracerouteの結果というのは、数々のうかばれないパケットの犠牲の上になりたっているのでした。もともとTTLは、IPレイヤーでのループ回避の為の仕組みなのですが、こんな使い方もあるんだ!と驚きました。

[実装] IP ... ICMP? ... UDP? ... TCP?


ここまでで、TTLを操作したIPパケットを送信する事で経路を調べる事ができるということが分かったと思います。ところで、IPパケットと一言でいってもいくつかの種類があります。よく目にするタイプではICMP/UDP/TCPでしょうか。どの種類のパケットを使うかは、いろいろと意見があるとは思いますが、代表的なOS付属tracerouteの実装をまとめると下図の通りとなります。

↓ OS毎の実装リスト


各OSで微妙に異なっていますね。どういう議論を経てこのような実装になったのかを考えてみるのも面白そうです。

tracerouteで使うIPパケットは、対象ネットワークにたとえfirewallが設置してあったとしても入り込んで任務を完了してくれるようなタイプが望ましいと思います。となると、弊社のようなインターネットサービス系のネットワークの場合80番ポートへのTCPが最適なのかもしれません。さて、ここで最初の問いに戻って

「好きなポートは何番ですか?」

ネットワークエンジニアとしては、80番と答えるのが正解だったのかなぁと最近では思ったりしてます。以前、国外のサイトへ接続できないというお問合せを受け、調査していた時、実際にこの実装の違いでUNIXからはtracerouteが正しく動作しないのにwindowsからは正常に対象ノードまで調べられたという事がありました(pingは反応がありませんでした)。結局原因はネットワークではなく別な所にあったのですが、tracerouteの実装の違いを知らなかったら、別な方向へ調査を進めてしまい時間のロスをしてしまったはずです。

traceroute-nanogの紹介


OSに標準で付属しているtracerouteコマンドは、それぞれに特徴があるのはわかりましたが、投げるパケットを指定する事ができれば、もっといいと思いませんか?この拡張版tracerouteでは、ICMP/UDP/TCPはもちろん、それぞれのパケットを詳細に指定する事ができます。そのほか面白い機能としては、AS番号を調べたり...。作業用マシンにインストールしておくと何かと便利です。下記FTPサイトからダウンロードできます。
ftp://ftp.login.com/pub/software/traceroute/

[落とし穴] 良く考えると...


ところが、tracerouteってすばらしい!と安心していると、思わぬ落とし穴にはまる事があります。動作原理をよーーーーく考えてみて下さい。



イントラネットのような小規模なネットワークでは、行き帰りの経路は同じ事が多いと思いますが、インターネットのような大規模なネットワークでは、行き帰りの経路が違うという事は普通に発生します。仕組みを考えれば分かるように、tracerouteで調べられるのは、「行きの経路」なのです。最近ではロードバランサを利用したサイトをよくみかけます。そのようなサイトではサーバ側の設定によってはtracerouteが行きの経路情報しか調査できない事による混乱が発生し得ます。



この図のサイトは、
o ロードバランサをDNATで設定し、privateアドレスでサービス
o サーバは、globalアドレスも持っている
o サーバのdefault gatewayは、ロードバランサに向けられている

このような構成の場合、外部からサーバのglobalアドレスへの経路をtracerouteで調査すると、対象サーバは外部サーバへロードバランサを通し返事をしようとします。その結果、このサーバまわりでトラブルが発生した時に対象サーバへのネットワークがおかしいのでは?と見当違いの場所を調査してしまったりするのです。

[まとめ] 仕組みを理解する必要性


上で書いたようにtracerouteのような古典的ツールですら、このような動作原理を知らないと思わぬ落とし穴に落ちてしまうことがあります。インターネットの世界の技術は、秒進分歩と言われるほど、次々と新しい技術が開発されています。エンジニアとしては、これら新しい知識を積極的に収集する事はもちろん大切ですが、古い確立された技術についても、しっかりとした理解する必要性を痛感しました。