トップページ | 2006年10月 »

2006年9月の3件の記事

RFC2328 OSPFv2の一部日本語訳

以下は、RFC2328 OSPFv2に書かれている
AS-external-LSAsの項目に関して、一部を訳したものです。

12.4.4.  AS-external-LSAs

   In figure 16, suppose instead that both RTA and RTB
   exchange BGP information with RTX.  In this case,

   RTA and RTB would originate the same set of AS-
   external-LSAs.  These LSAs, if they specify the same
   metric, would be functionally equivalent since they
   would specify the same destination and forwarding
   address (RTX).  This leads to a clear duplication of
   effort.  If only one of RTA or RTB originated the
   set of AS-external-LSAs, the routing would remain
   the same, and the size of the link state database
   would decrease.  However, it must be unambiguously
   defined as to which router originates the LSAs
   (otherwise neither may, or the identity of the
   originator may oscillate).  The following rule is
   thereby established: if two routers, both reachable
   from one another, originate functionally equivalent
   AS-external-LSAs (i.e., same destination, cost and
   non-zero forwarding address), then the LSA
   originated by the router having the highest OSPF
   Router ID is used.  The router having the lower OSPF
   Router ID can then flush its LSA.  Flushing an LSA
   is discussed in Section 14.1.

   図16のケースでは、RTAとRTBの両方がRTXでBGP情報を交換
   すると仮定してください。

   RTAとRTBは、同じAS外部LSAを生成するでしょう。
   これらのLSAは、もし、メトリックが同じであれば、それら
   が同じ目的地および転送先(RTX)を指定するので、機能的に
   等価でしょう。これは明瞭な複製の努力に結びつきます。
   もし、RTAまたはRTBのうちの1つだけがAS-external-LSAsを
   生成すれば、ルーティングは同じままで、リンクステート
   データベースのサイズは減少するでしょう。
   しかしながら、それはどのルーターがLSAを生成するかに関
   しては明確に定義されるべきです。
   (そうでなければ、どちらのルータも生成しないかもしれな
   いし、あるいは生成するルータが変動するかもしれない。) 

   そのため、次の規則が確立されます:
   互いに到達可能な、2つのルーターが機能的に等価なAS-ext
   ernal-LSAs(同じディスティネーション、コスト、及び「0」
   でないネクストホップを持つ)を生成する場合、最も値の高
   いルータIDを持つルータによって生成されたLSAが使用され
   ます。その際、より低いOSPFルーターIDを持つルーターは
   そのLSAをFlushすることができます。

               +
               |
     +---+.....|.BGP
     |RTA|-----|.....+---+
     +---+     |-----|RTX|
               |     +---+
     +---+     |
     |RTB|-----|
     +---+     |
               |
     +---+     |
     |RTC|-----|
     +---+     |
               |
               +

   Figure 16: Forwarding address example

| | コメント (0) | トラックバック (0)

NetScreenのアラートメールフォーマット

NetScreenで警告やトラフィックのログをメールで送信する際には

メールの送信元アドレスはデフォルトで netscreen_admin@[an.ip.add.ress]となっている。

※an.ip.add.ressは通常Untrust側interfaceのIPアドレスがセットされる。

このままではメールサーバの設定によってはドメイン名部分にIPアドレスを利用する事を許可していない場合などがあり、拒否される事が多い。また、仮にリレーできたとしても後段のメールサーバで拒否されたりスパム判定される可能性が残る。

但し、以下のようにNetScreen自身のホスト名とドメイン名を設定する事でメールの送信元アドレスがFQDNを利用したものへ変化する。

set hostname <hostname>
set domain <domain name>

例:ホスト名:netscreen (set hostname netscreen)

ドメイン名:example.jp (set domain example.jp)

ホスト名とドメイン名を上記のように設定した場合、メールの送信元アドレスは「netscreen@example.jp」となります。

もし、どちらか一方しか設定されていないような場合やデフォルトのホスト名、ドメイン名(デフォルトではドメイン名設定なし) を利用している場合には「netscreen_admin@[an.ip.add.ress]」となるようです。

以上

| | コメント (0) | トラックバック (0)

今日からブログ

今日から、ブログを書くことにしました。
ブログと言っても日記ばかりでは無く
Network & Security関連の設定やTips、勉強の記録です。

それでは、始まり始まり・・・。

| | コメント (0) | トラックバック (0)

トップページ | 2006年10月 »