monqy blog: 2021-03

2021/03/29

BGPのベストパス選択の実際

R1はR2, R3, R5とneighborになっている。
R1でshow ip bgpを実行すると

R1#sho ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.102.0    192.168.101.2            0         32768 64513 i　※1
 *                    192.168.101.18          80             0 64517 i　※2
 * i                  192.168.101.14          80     80      0 64516 i　※3

192.168.102.0/24 のprefixはBGPテーブルに３つあるが、

ベストパスは※１である。

この時、192.168.101.2のルータ（図でいうRT5）がダウンしたら、ベストパスはどれになるか？

現在のベストパスはweightが設定されている。

weightはciscoルータがBGPのベストパスを選択するときに比較する最初の条件である。

この経路以外はWeightは設定されていない。

Weightの次に比較するのはlocal preference である。

残りの2経路のLocPrfを見ると、一つは空欄、もう一つは80である。

この時、どちらの経路が採用されるか？

そもそも、※２のlocPrfはなぜ空欄なのか？

それは、※２の経路はeBGPのネイバーから受信したprefixだからである。

逆に言うと、BGPテーブルを表示したときにLocPrfが空欄のprefixは、

eBGPから受信したものだとわかる。

eBGPから受信した経路にはlocPrfは「無い」のである。

では、ベストパスの2番目の比較が行われるときに、※２と※３の比較はどうなるのか？

locPrfがない経路より、80が設定されている※３の方が強いのか？

これは考えてもわからない。

こういう場合、LocPrfがないeBGPネイバーから受信したprefixはLocPrfがデフォルト値の100であるとして比較をおこなうことになっている。

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

だから、RT5がダウンしたらベストパスは ※２になる。

実際にやってみた。

R1#sho ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.102.0    192.168.101.2            0         32768 64513 i
 *                    192.168.101.18          80             0 64517 i
 * i                  192.168.101.14          80     80      0 64516 i


※RT5を落とす

*Mar 29 04:29:31.095: %BGP-3-NOTIFICATION: sent to neighbor 192.168.101.2 4/0 (hold time expired) 0 bytes
*Mar 29 04:29:31.095: %BGP-5-NBR_RESET: Neighbor 192.168.101.2 reset (BGP Notification sent)
*Mar 29 04:29:31.095: %BGP-5-ADJCHANGE: neighbor 192.168.101.2 Down BGP Notification sent
*Mar 29 04:29:31.095: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.101.2 IPv4 Unicast topology base removed from session  BGP Notification sent

R1#sh ip bgp summary

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.101.2   4        64513       0       0        1    0    0 00:00:07 Idle
192.168.101.14  4        64512      10      11        3    0    0 00:05:09        1
192.168.101.18  4        64517      10      11        3    0    0 00:05:09        1



※新しいベストパスが選択される

R1#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.102.0    192.168.101.18          80             0 64517 i
 * i                  192.168.101.14          80     80      0 64516 i

2021/03/21

マルチキャスト実践 2021

マルチキャストの実践。 senderで二つの宛先のストリームを送信する。

vlcを使用。

一つは、239.1.1.5宛もう一つは、239.1.1.6宛

レシーバーの上位のルータでの確認。

レシーバ側のvlcで、ストリームを開き、

1回目は 239.1.1.5を開く

2回目は 239.1.1.6を開く

同時に二つは開けなかった。

1回目

R2#sh ip igmp membership
Flags: A  - aggregate, T - tracked
       L  - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP, the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (G))
Reporter:
        - last reporter if group is not explicitly tracked
       /      -  reporter in include mode,  reporter in exclude

 Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
 *,239.1.1.5                    10.0.20.100     00:00:04 02:55 2A     Vl20
 *,239.255.255.250              10.0.20.100     00:02:22 02:42 2A     Vl20
 *,224.0.1.40                   172.16.11.1     01:34:45 02:52 2LA    Fa8

2回目

R2#sh ip igmp membership
Flags: A  - aggregate, T - tracked
       L  - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP, the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (G))
Reporter:
        - last reporter if group is not explicitly tracked
       /      -  reporter in include mode,  reporter in exclude

 Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
 *,239.1.1.6                    10.0.20.100     00:00:25 02:34 2A     Vl20
 *,239.255.255.250              10.0.20.100     00:02:01 01:57 2A     Vl20
 *,224.0.1.40                   172.16.11.2     01:34:24 02:08 2LA    Fa8

igmp membershipを表示すると、受信しているマルチキャストアドレスのグループしか表示されない。

見てはいないのだが、このときルータ R2には、レシーバーが受信しているストリームしか届いていないはずだ。

送信側でストリームを送信したままにしていても、

レシーバーのvlcを終了させればレシーバーに239.1.1.5/6 宛パケットは到達しなくなる。

2021/03/05

このアプリケーションのデジタル署名は、信頼できる認証局からの証明書を使用して生成されましたが、その認証局によって失効されていないことを確認できません。

自前サーバの自前CAで署名した自前サーバ証明書をインストールした装置にアクセスしたときに、こんなメッセージが表示された。

「このアプリケーションのデジタル署名は、信頼できる認証局からの証明書を使用して生成されましたが、その認証局によって失効されていないことを確認できません。」

アクセス先装置の証明書を発行したCAの証明書は、アクセス元のPCにインストールしてある。

だから、「信頼できる認証局からの証明書を使用して生成されました」となっている。

だが、CRLを設定していない。

これはgmailのサーバ証明書だが、「CRL配布ポイント」というのがある。

[1]CRL Distribution Point

Distribution Point Name:

Full Name:

URL=http://crl.pki.goog/GTS1O1core.crl

という値が設定されている。

私が自前で発行したサーバー証明書にはこの項目がない。

そうか、CRL配布ポイントを証明書発行のときに設定してやればいいのか....

sanを設定したのと同様にテキスト(ext.txt)に書いて、署名時に -extfile ext.txt

を付けてやればよい。

crlDistributionPoints = URI:https://www.example.com/hoge.crl

これでCRL配布ポイントが証明書に入った。

サーバ証明書を入れ替えて再度アクセスしてみると、

今度は登録した CRL配布ポイントのアクセスが信頼できませんと言われてしまった。

ちょっと考えて、気づいた。

そもそもhttpsアクセスするための証明書なのに、それを検証するCRLの宛先もhttpsになっていたらそれも検証しなければならず、永遠に検証が終わらない。

というわけで、CRL配布ポイントのURLをhttpsでなくhttpにしたら、警告が消えた。

crlDistributionPoints = URI:http://www.example.com/hoge.crl

このブログを検索