ネットワーク系エンジニアのTips。
便利ツールや検証中の小技を書きます。
最近はXML、SNMP、Syslog、WebService、Perlといろいろ。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
使用帯域の可視化ができる。 ダウンロードはこちら。
PR
TCPのシーケンスを調べようとして、見つけたサイト。
あらゆるプロトコルのシーケンスが書かれてるので、ちょっと見るのに便利。
http://www.eventhelix.com/RealtimeMantra/Networking/
あらゆるプロトコルのシーケンスが書かれてるので、ちょっと見るのに便利。
http://www.eventhelix.com/RealtimeMantra/Networking/
いつも苦しむ正規表現。
比較的まとまってて見やすいサイトを探してみた。
XFIELD TECHNOTE
http://xfield.info/modules/tautech/content0144.html
サルにもわかる正規表現
http://www.mnet.ne.jp/~nakama/
あと、Co-workerに教わった、正規表現チェックサイト。
http://regexpal.com/
上のフレームに正規表現を書き、下のフレームに引っ掛けたい元の文字列を入れると、正規表現で取れる範囲が黄色く網掛けになる。
比較的まとまってて見やすいサイトを探してみた。
XFIELD TECHNOTE
http://xfield.info/modules/tautech/content0144.html
サルにもわかる正規表現
http://www.mnet.ne.jp/~nakama/
あと、Co-workerに教わった、正規表現チェックサイト。
http://regexpal.com/
上のフレームに正規表現を書き、下のフレームに引っ掛けたい元の文字列を入れると、正規表現で取れる範囲が黄色く網掛けになる。
※ここからはrelayする時の話です。
----------
4.3 Relayed syslog Packets
syslogを転送するデバイスでは、PRIがまともかどうかcheckします。
(中略)
考えられるケースとしては以下の通りであり、右に書いた各章で解説します。
1)PRI・TIMESTAMPともに問題なしの場合→Section4.3.1
2)PRIは正常だが、TIMESTAMPフィールドがなかったり、変な場合→Section4.3.2
3)PRI部分が無いか、PRIとして認識できるものではない場合→Section4.3.3
4.3.1 Varid PRI and TIMESTAMP
(中略)
とはいえ、TIMESTAMPフィールドに入った時間がまともなものかどうかまではcheckしなくてよいです。また、HostnameのIPアドレスがPacketのSrcアドレスと一致しているかどうかも、(前述の通り違っているパターンもあるので)checkする必要はありません。
4.3.2 Varid PRI but no TIMESTAMP or invarid TIMESTAMP
TIMESTAMPフィールドが無かったり、このフィールドのデータとしてはフォーマットがおかしい、という場合は、PRIフィールドの">"の後に1スペースあけて、その後にTIMESTAMPをつけてやる必要があります。時間は、relayするデバイスのlocal timeにします。
で、TIMESTAMPの後に1スペース空けた後、HOSTNAMEフィールドを続けます。HOSTNAMEは、relayするデバイスでわかっているならoriginalのhostnameを、分からなければoriginalが使っているアドレスを入れます。
このような修正をしたら、全体のパケット長が1024byte以下であることを確認してください。もしオーバーしていたらtruncate(切りとり)して1024byte以下になるようにします。
このような場合は、MSG部分などデータが不完全になるので、originalの送出段階から、きちんとしたフォームで(PRIやHEADERを作成して)あるべきなのです。
4.3.3 No PRI or Unidentifiable PRI
もしOriginalにPRIが無いとか、PRIかも知れないがPRIとして認識できないPRIのついたsyslog messageを受信した場合はPriorityを13にしたPRIを挿入し、TIMESTAMPフィールド以降も前述の通り追加します。
例えば、PRIは<00>なんかはPRIとして扱われないので、relayされるメッセージではこんな風にします。
(以下略)
----------
----------
4.3 Relayed syslog Packets
syslogを転送するデバイスでは、PRIがまともかどうかcheckします。
(中略)
考えられるケースとしては以下の通りであり、右に書いた各章で解説します。
1)PRI・TIMESTAMPともに問題なしの場合→Section4.3.1
2)PRIは正常だが、TIMESTAMPフィールドがなかったり、変な場合→Section4.3.2
3)PRI部分が無いか、PRIとして認識できるものではない場合→Section4.3.3
4.3.1 Varid PRI and TIMESTAMP
(中略)
とはいえ、TIMESTAMPフィールドに入った時間がまともなものかどうかまではcheckしなくてよいです。また、HostnameのIPアドレスがPacketのSrcアドレスと一致しているかどうかも、(前述の通り違っているパターンもあるので)checkする必要はありません。
4.3.2 Varid PRI but no TIMESTAMP or invarid TIMESTAMP
TIMESTAMPフィールドが無かったり、このフィールドのデータとしてはフォーマットがおかしい、という場合は、PRIフィールドの">"の後に1スペースあけて、その後にTIMESTAMPをつけてやる必要があります。時間は、relayするデバイスのlocal timeにします。
で、TIMESTAMPの後に1スペース空けた後、HOSTNAMEフィールドを続けます。HOSTNAMEは、relayするデバイスでわかっているならoriginalのhostnameを、分からなければoriginalが使っているアドレスを入れます。
このような修正をしたら、全体のパケット長が1024byte以下であることを確認してください。もしオーバーしていたらtruncate(切りとり)して1024byte以下になるようにします。
このような場合は、MSG部分などデータが不完全になるので、originalの送出段階から、きちんとしたフォームで(PRIやHEADERを作成して)あるべきなのです。
4.3.3 No PRI or Unidentifiable PRI
もしOriginalにPRIが無いとか、PRIかも知れないがPRIとして認識できないPRIのついたsyslog messageを受信した場合はPriorityを13にしたPRIを挿入し、TIMESTAMPフィールド以降も前述の通り追加します。
例えば、PRIは<00>なんかはPRIとして扱われないので、relayされるメッセージではこんな風にします。
<13>TIMESTAMP HOSTNAME <00>...ここでもやっぱり、1024byte以下になっているかどうか、確認が必要です。
(以下略)
----------