naoki86star

インターネットの片隅でなにかしら書いてみる

bird2.0.6 ; flow6でうまくいかなかったこと

 birdでrtbh/flowspecをやってみた流れで書きます。

 blackholeコミュニティないし/flowspec+コミュニティを付与した経路(/32)を送出するノードをTriggerと称したとき、そのTriggerノードがダウンしたら、その経路(=指示)は消えてしまいますです。なので、Triggerノードは複数用意して送出するのがベターなのだと思います。

f:id:naoki86star:20191011154538p:plain
3nodes

 この構成は、Trigger/TriggerBackupをBGP送信専用、BirdRouterをゲートウェイルータにしていて、BirdRouterの先のルータでblackhole/flowspecを受けて機能を働かせよう、というものにしてます。

 で、ちょっと実験して、Trigger/TriggerBackupをつなげると冗長性はあがるかどうか。Trigger/TriggerBackup間をigpでつないだらいいことあるかどうか試しました。結論は、bgpをつなぐこと自体はには意味がない、だと考えてます。

  • blackhole(IPv4)
  • flowspec(IPv4)
  • blackhole(IPv6)
  • flowspec(IPv6)

 上記4プロトコルを動かしてみて、peerはすべてmutiprotocol-bgpでIPv4の1セッションに4プロトコルを押し込んでます。

 実際に試してみて、容易に推察できる通り、というか仕様的に当たり前な結果を見ることになりました。Trigger/TriggerBackup間で投入経路は共有して、それぞれからBirdRouterにupdateを送ります。経路を入れたオリジナルのノードを止めると、widthdrawが走り、入れた経路は消えてしまいます。冗長の目的にはTrigger/TriggerBackupそれぞれで同じ経路を入れる必要ある、ということです。

 で、今日ちょっと書きたかったことは、Trigger/TriggerBackupをつないでしまうと、余計な現象にあたってしまったことです。
 基本的には、4つのプロトコルのケースで、Trigger/TriggerBackupからそれぞれ経路を入れると、BirdRouterに投入した経路が2
入ってきます。
 flowspec(IPv6)の場合のみの現象なのですが、2経路入っている状態で

root@BirdRouter:~# birdc show route all
BIRD 2.0.6 ready.
Table flowtab6:
flow6 { dst fc00:10:100:1::123/128; icmp type 128; }  [E1 15:22:52.934 from 172.31.100.1] * (100) [AS65001i]
        Type: BGP univ
        BGP.origin: IGP
        BGP.as_path: 65001
        BGP.local_pref: 100
        BGP.community: (65000,667)
        BGP.ext_community: (generic, 0x80060000, 0x0)
                      [E2 15:22:52.935 from 172.31.101.1] (100) [AS65001i]
        Type: BGP univ
        BGP.origin: IGP
        BGP.as_path: 65001
        BGP.local_pref: 100
        BGP.community: (65000,667)
        BGP.ext_community: (generic, 0x80060000, 0x0)

この状態で、Triggerからこの経路をwithdrawすると(birdc downでも同じ)TriggerBackupから受けていたものも消えてしまう、すなわちflowが無効になってしまう、そんな現象になりました。TriggerBackupのflow6テーブルには当該経路は残っています。

 Trigger/TriggerBackup/BirdRouterすべてbird2.0.6を使っていました。IPv4/IPv6のunicast、それからIPv4のflowだとそうはなりません。切り分けでgobgpd(2.9.0)も混ぜて試してみました。少なくともBirdRouterをgobgpdにすると起こりません。とりあえず、bird2.0.6でflow6テーブルにおいてigpとincompleteが混在するようなケースは避けたほうがいい、というのが今日の自分の中での結論です。
 とにかく、そもそもこの最初のTrigger/TriggerBackupを繋げてみたのが、意味がないわりにレアケースの期待しない挙動があったということです。

 Trigger/TriggerBackupをネットワーク的につなぐ意義は、注入情報をなにかの方法で、同期してそれぞれのノードでオリジンとして投入できるようになる、ということ以上のメリットはなかったです。