ネットワーク構築の最近のブログ記事

IPアドレス(レンジ表記)をサブネット表記に置き換えるスクリプトですが、副産物と言うべきか、できたものがこれ。
ip.zip

使い方ですが
D:\src>ip.pl -s 10.1.0.0 -e 10.11.200.255
10.1.0.0/16
10.2.0.0/15
10.4.0.0/14
10.8.0.0/15
10.10.0.0/16
10.11.0.0/17
10.11.128.0/18
10.11.192.0/21
10.11.200.0/24

D:\src>ip.pl -s 192.1.0.0 -e 192.20.255.199
192.1.0.0/16
192.2.0.0/15
192.4.0.0/14
192.8.0.0/13
192.16.0.0/14
192.20.0.0/17
192.20.128.0/18
192.20.192.0/19
192.20.224.0/20
192.20.240.0/21
192.20.248.0/22
192.20.252.0/23
192.20.254.0/24
192.20.255.0/25
192.20.255.128/26
192.20.255.192/29
こんな感じで、10.1.0.0から10.11.200.255をサブネット表記するにはこうしたらいいというリストを出してくれます(2つ目は192.1.0.0から192.20.255.199の例)。ネットワークなんて触ってると、ルーティングテーブルとかACLとかで、オーバーヘッド(ペナルティ)を減らしたいという意図からできる限り行数を短くしたい事も多いし、この機会に作っておこうとか、そんな感じですが。
ま、そもそもIPアドレス設計の段階で考慮されていればこんな涙ぐましい努力は必要無いんですけど、現実問題としては既に存在するネットワークをどうこうするという話が多いわけで、過渡期的にぐちゃぐちゃなネットワークになってしまう事なんて良くある話で。ま、そんな意味では必要悪というか仕方ないというか。。。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
ルーティングテーブルの評価はロンゲストマッチ!
という基本的な話。


当たり前なのに、なかなか理解して貰えないんだよな・・・。




要するに

ルーティングテーブルがあって、(PCとかでもnetstat -rnとか、route printとかすると見れますぜ)、、
サブネットマスクの長いものから評価対象になりますというお話。



例えば、

dest          gateway        interface        metric
0.0.0.0/0    192.168.100.254    eth0    1
172.16.0.0/12    192.168.100.253    eth0    1
172.24.0.0/24    192.168.100.252    eth0    1
192.168.100.0/24    192.168.100.1    eth0    1
192.168.100.1/32    192.168.100.1    eth0    1

こんなテーブルがあったとして、

最初に評価されるのが、
サブネットの最も長い192.168.100.1/32のテーブル。
次が192.168.100.0/24のテーブル。
その次が172.24.0.0/24のテーブル。
その次が172.16.0.0/12のテーブル。
最後が0.0.0.0/0のテーブル。


というだけの話。


この場合、自分のインターフェースは192.168.100.1なので、逆から解釈すると
192.168.100.0/24に行くには、192.168.100.1、つまり直結ですよ。
172.24.0.0/24に行くには192.168.100.252のルータ経由。
172.16.0.0/12に行くには192.168.100.253のルータ経由。
それ以外は192.168.100.254経由になる。。。


という風に理解すればいいだけの話。



実に簡単です。(^^;



# 実はちょっとした愚痴・・・。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
HSRP:Hot Standby Router Protocol
VRRP:Virtual Router Redundancy Protocol

ルータの冗長構成用プロトコルとしてCiscoが独自にHSRPを開発したが、ベンダー独自規格であったため他社とは互換性がなかった。そこで複数のベンダーがHSRPを発展させたVRRPが作られ、RFC(RFC2338、RFC3768)で規格化された。(とはいえ、HSRPもRFC2281として公開されている・・・)


どちらのプロトコルも複数のルータ間でやり取りして仮想的なルータを作成する。仮想的なルータは仮想MACアドレスと仮想IPアドレスを持ち、クライアントはこの仮想アドレスをゲートウェイとして通信を確立する。

HSRPのActiveルータは仮想IPアドレスと実IPアドレスの両方を持つが、VRRPのMasterルータは仮想IPアドレスを持ったとき、実IPアドレスが無効になる。(装置によって実装がまちまちで、実IPアドレスも有効になっている実装もある。・・・監視とか考えたときには非常に悩ましい部分だけど。)


仮想MACアドレスは
HSRP:00-00-0C-07-AC-*
VRRP:00-00-5E-00-01-*
 ※"*"はグループ番号が入る

が使われる。


ルータ間で使われるパケットについても若干違って、

HSRP:
ルータ/MLS間でHelloパケットのやりとりを行う。HelloパケットはUDP(プロトコル番号17)の1985番ポートが使われ、224.0.0.2(マルチキャストアドレス)をTTL=1にして送信される。(アプリケーション層で動作する。)

VRRP:
ルータ/MLS間でVRRPパケットのやりとりを行う。VRRPパケットはIP上でプロトコル番号112で動き、224.0.0.18(マルチキャストアドレス)でTTL=255にしてやりとりする。(トランスポート層で動作する。)


HSRPではStandbyルータからActiveルータにHelloパケットを送るが、VRRPではBackupルータからMasterルータにVRRPパケットを送ることは無い。そのため、MasterルータはBackupルータを認識する事ができない・・・という違いがある。


似たようなものだけど。


用語も若干違って、状態の表現も

HSRP:Active、Standby

VRRP:Master、Backup

と表現する。


似て異なるものだけど・・・。



↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
単純なことなんだけど、、、
あらためて、ルーティングってことを考えてみる。
(というか、ルータやL3スイッチの動作)

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
たまたま手元にあった実機(Catalyst3750、IOS IP-Services 12.2(20)SE1)を使ってテストしてみたけど・・・コンフィグはこんな感じで。
vlan 10
 name External-Network
 exit
!
vlan 20
 name Internal-Network
 exit
!
interface Vlan10
 description ---- External Network ----
 ip address 192.168.10.254 255.255.255.0
 ip access-group input in
 ip access-group output out
 exit
!
interface Vlan20
 description ---- Internal Network ----
 ip address 192.168.20.254 255.255.255.0
 exit
!
ip access-list extended input
 permit ip 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255
 permit udp any any eq rip
 permit udp any eq ntp any
 evaluate dyn-in
 deny   ip any any log
 exit
!
ip access-list extended output
 permit tcp host 192.168.20.1 host 192.168.10.10 eq 8080 log reflect dyn-in timeout 10
 permit icmp 192.168.20.0 0.0.0.255 any log reflect dyn-in timeout 10
 permit tcp 192.168.20.0 0.0.0.255 any log reflect dyn-in timeout 300
 permit udp 192.168.20.0 0.0.0.255 any log reflect dyn-in timeout 120
 deny   ip any any log
 exit
!
正直な感触としては、パケットの破棄が多すぎて使い物にならない。尤も、再帰ACLについてはCPUで処理されている筈なので、Catalyst3750の力不足というのも考えられる。より高速なルータ(7200とか)なら実用になるのかも知れないけど・・・。
今すぐ使えるという感じでは無いな。


一応ちゃんとダイナミックにフィルタが更新されてる様子として・・・
Switch#show ip access-lists dyn-in
Reflexive IP access list dyn-in
     permit tcp host 192.168.10.10 eq 8080 host 192.168.20.1 eq 1308 log (3 matches) (time left 119)
     permit tcp host 192.168.10.10 eq 8080 host 192.168.20.1 eq 1307 log (7 matches) (time left 116)
     permit tcp host 192.168.10.10 eq 8080 host 192.168.20.1 eq 1300 log (3 matches) (time left 109)
     permit icmp host 192.168.10.10 host 192.168.20.1  log (87 matches) (time left 9)
Switch#

ちょっと期待はずれでガッカリ。
↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
CiscoのACLで面白い機能を見つけたので、メモ。


CCIEの範疇っぽい内容だけど。



IOS11.3以降でサポートされている機能として、再帰ACLと書かれてるんだけど、どうも単なるダイナミックフィルターっぽい。

再帰 ACL は、Cisco IOS ソフトウェア リリース 11.3 で導入されました。 再帰 ACL では、上位層セッションの情報に基づいて IP パケットをフィルタリングできます。 一般に再帰 ACL は、ルータ内部から開始されたセッションに対して、発信トラフィックを許可し着信トラフィックを制限するために使用されます。

再帰 ACL は、拡張名前付き IP ACL でのみ定義できます。 番号付きまたは標準名前付き IP ACL、またはその他のプロトコル ACL では定義できません。 再帰 ACL は、他の標準 ACL やスタティックな拡張 ACL と組み合せて使用できます。


次に、さまざまな再帰 ACL コマンドの構文を示します。

interface
ip access-group {number|name} {in|out}

ip access-list extended name
permit protocol any any reflect name [timeoutseconds]
ip access-list extended name
evaluate name
次に、ICMP については発信および着信トラフィックを許可し、TCP トラフィックについては内部から開始された場合だけ許可して他のトラフィックは拒否する例を示します。

ip reflexive-list timeout 120


interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group inboundfilters in
ip access-group outboundfilters out

ip access-list extended inboundfilters
permit icmp 172.16.1.0 0.0.0.255 10.1.1.0 0.0.0.255
evaluate tcptraffic


!--- 次のコマンドにより、tcptraffic という名前の、outboundfilters ACL
!--- の再帰 ACL 部分を inboundfilters ACL に結び付けます。


ip access-list extended outboundfilters
permit icmp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 reflect tcptraffic



NAT/NAPTと(他社で言うところの)ダイナミックフィルターが使えるって事は簡易的にファイアウォール的な制御も可能って事じゃない?と思ったんだけど・・・。

実際のところ、実験してみないとどれだけ細かく制御できるのとかは判らないし、CEFとかが効くのかも不明だし、どれだけ実用的に使えるかは不明なんですが。
今度、暇ができたらISRとか3750辺りの評価機でも使って実験してみようっと。

なんかあったとき、逃げとして位なら使えるかも知れないし。


ちなみに、本当の意味でのステートフルな制御はコンテキストベース アクセス制御とか言われててFirewallフィーチャセットが必要っぽい。(Firewallフィーチャセットを買って使うくらいの要件ならPIX/ASA使った方が・・・とも、最近ちょっと思う)


以下、ちょっと愚痴。

上記のCBAC、再帰ACL、普通のACLの違いって、話してもなかなか理解してもらえない部分ですよね。ファイアウォールとACLの違いって何?みたいな聞き方をされたときに、もっと判りやすく説明できる方法があればいいんだけどねぇ。(どうしても技術的な話になっちゃうし、くどくなっちゃうから・・・)


↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
今回の仕事。 前々から、支援したり調整したりしてたんですが、先週の段階で『全然調整不足』ということが判りまして、まあ、現地担当者には『これとこれを確認しておいて』的に現地調整をお願いしていたのですが…。 全然意味を理解してくれてなかったようで、、、トンチンカンな答えが帰ってきた訳です。 そんなわけで先週の金曜日に(しかも夕方)急遽何とか調整したわけですが…。 まぁ、何とかするしかないかぁ。。。
↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
IT Proの記事
 米Microsoftは10月16日(米国時間),カリフォルニア州サンフランシスコで開催したイベントにおいて,IT業界のパートナ企業50社から バックアップを受けるユニファイド・コミュニケーション製品群の提供開始を発表した。Microsoftは様々なサーバー向け,デスクトップ向け,携帯機 器向けソフトウエアをそろえ,企業ユーザー間の多様なコミュニケーション手段の統合を図る。
Microsoftも(Telcoの技術も使ったんでしょう)VoIPに乗り込んで来ました。
本当、NGNは外せないキーワードだなぁ。。


↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ

確かに良いファイアウォールだと思うけどさ。個人的には好きな機器ですし。

こちらのサイトはドメイン名からして逝っちゃってます。viva-netscreenなんてドメイン取得してる時点で凄すぎる。

個人的にはFirewallといえば、CheckPointのFirewall-1が一番最初に頭に浮かびます。(最初はSunのFirewall-1だった・・・)で、初めてNetScreenを見たとき「ゾーンによる管理」の概念が取り入れられていてビックリした記憶があります。確かに判りやすかったし。
気に入らなかったのは、セッションクローズされるまでアクセスログが記録されないこと。「通る通らない」の調査をする際は、判りにくくて・・・。現在はScreenOSも5.4まで上がってますので、セッションを張った時点でアクセスログに記録する機能も追加されていますが。

対抗して「viva-2001」ドメインでも取得しますかw
※「monolith.org」「1x4x9.org」は既に使われてて取れませんでしたので。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ

ネットワーク移行後の話なんですが、DDNSが不調になりました。
DDNS更新されてないってのはまだ想定内だったんですが、PPPoEの割り当てIPが接続毎に変わるってのはこれまで無かったので、焦りました。
結局Firewall再起動で安定しだしたんですが、最初は何が起こったのかと(ry
内部側のIPアドレス以外ほとんど設定変更したのですが、やはり大幅に設定変更をした後は再起動しておいた方がよいですね。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ

このアーカイブについて

このページには、過去に書かれたブログ記事のうちネットワーク構築カテゴリに属しているものが含まれています。

前のカテゴリはサーバー構築です。

次のカテゴリはネット/コンピュータです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

タグクラウド