JANOG55 NETCON 問題解説（現地問題6）

京都で開催された JANOG55 盛況でしたね。参加者が 4000 人超えるとかすごいことになってるなって思いました。

さて、今回私は NETCON 実行委員として参加して、オンライン問題1問 / 現地問題3問を作成しました。ここでは現地問題6について解説していこうと思います。

問題
事象の確認
原因調査
対処方法
コンフィグ
1. RT-01
2. RT-02
小ネタ

問題

問題文

RT-01 と RT-02 で eBGP 設定をしてあるというが、ピアが確立していない。検証用の設定を入れているので設定は変えないようにと言われているのだが、とりあえずピアだけは生かしておきたい。

達成条件

RT-01 と RT-02 で eBGP ピアが確立すること
対処完了後、RT-02 の Loopback への到達性があること。

制約

既存の設定は削除、変更してはならない。
セカンダリアドレスを追加するなどのアドレス割り当てを変更することは禁止です。

事象の確認

ピアが確立していないのかを双方で確認してみます。

RT-01#sh bg ipv4 uni sum | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.2.2        4        65002       0       0        1    0    0 00:15:20 Idle (PfxCt)
 
RT-02#sh bg ipv4 uni sum | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.2.1        4        65001       0       0        1    0    0 00:16:12 Idle

両方とも状態が Idle なのですが、RT-01 側だけ「 Idle (PfxCt) 」ってなってますね。ここが鍵になりそう。

原因調査

PfxCt が何かわかりませんが、とりあえずログ見てみます。BGP 関連に絞るため、パイプでつなげた後に i(include) で BGP と言う文字列を含む行だけ出力させてみます。

RT-01#show logging | i BGP
*Jan  1 06:44:23.791: %BGP-4-NORTRID: BGP could not pick a router-id. Please configure manually.
*Jan  1 06:45:48.427: %BGP-5-NBR_RESET: Neighbor 10.1.2.2 active reset (BGP Notification sent)
*Jan  1 06:45:48.427: %BGP-5-ADJCHANGE: neighbor 10.1.2.2 Up
*Jan  1 06:45:48.431: %BGP-4-MAXPFX: Number of prefixes received from 10.1.2.2 (afi 0) reaches 2, max 2
*Jan  1 06:45:48.431: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.1.2.2 (afi 0): 3 exceeds limit 2
*Jan  1 06:45:48.431: %BGP-3-NOTIFICATION: sent to neighbor 10.1.2.2 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 000002
*Jan  1 06:45:48.431: %BGP-5-NBR_RESET: Neighbor 10.1.2.2 reset (Peer over prefix limit)
*Jan  1 06:45:48.431: %BGP-5-ADJCHANGE: neighbor 10.1.2.2 Down Peer over prefix limit
*Jan  1 06:45:48.431: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.2.2 IPv4 Unicast topology base removed from session  Peer over prefix limit
*Jan  1 06:46:04.315: %BGP-5-NBR_RESET: Neighbor 10.1.2.2 passive reset (BGP Notification sent)
*Jan  1 06:46:04.315: %BGP-5-ADJCHANGE: neighbor 10.1.2.2 passive Down AFI/SAFI not supported
*Jan  1 06:46:51.427: %BGP-5-NBR_RESET: Neighbor 10.1.2.2 passive reset (BGP Notification sent)
*Jan  1 06:46:51.427: %BGP-5-ADJCHANGE: neighbor 10.1.2.2 passive Down AFI/SAFI not supported
*Jan  1 06:47:46.727: %BGP-3-NOTIFICATION: sent to neighbor 10.1.2.2 passive 2/8 (no supported AFI/SAFI) 3 bytes 000101 (timer expired)

あれ、3 行目で一度ピア確立（neighbor 10.1.2.2 Up ）が出ていますね。その後 %BGP-4-MAXPFX や %BGP-3-MAXPFXEXCEED の出力で何らかの問題を検知し、最終的には以下の行にあるとおりプレフィックス数制限を超えたために Down 状態になったと言うことがわかります。

%BGP-5-ADJCHANGE: neighbor 10.1.2.2 Down Peer over prefix limit

これは BGP の最大プレフィックス機能によるものです。

BGP最大プレフィクス機能の設定

このドキュメントでは、ボーダーゲートウェイプロトコル(BGP)の最大プレフィクス機能の設定とトラブルシューティングについて説明します。

商用では warning-only オプションを使って「想定以上のプレフィックスを受信した時に、警告は出すが BGP セッションは維持する」と言う使い方をするかと思いますが、この問題環境ではどうなっているかというと…？

RT-01#show bgp ipv4 unicast neighbor 10.1.2.2 | i prefix
  Peer had exceeded the max. no. of prefixes configured.
  Maximum prefixes allowed 2
  Reduce the no. of prefix and clear ip bgp 10.1.2.2 to restore peering

警告なしに即切断する設定になっているようです。もし warning-only が設定されていたら2行目の出力は以下のようになるはずです。

 Maximum prefixes allowed 2 (warning-only)

と言うことで、RT-01 は RT-02 から3つ以上のプレフィックスを受信したため、警告なしに BGP セッションを切断してしまったと言うことがわかりました。

対処方法

さて、発生している状況と原因は見えましたが、制約によって取れる対処が限られます。

RT-01 で prefix-list を設定し、RT-02 から受信するプレフィックスを制限する。
→ 「対処完了後、RT-02 の Loopback への到達性があること。」となっているため、NG
RT-01 の maximum-prefix 設定を変更して受け入れ上限を増やすか、そもそも削除してしまう。
→ 「既存の設定は削除、変更してはならない。」となっているため、NG
そもそも、設問に「検証用の設定を入れているので設定は変えないようにと言われている」とあるので、検証作業に影響の出そうな設定変更（Loopback インターフェースの shutdown や削除など）はNG

ですが、やりたいこととやるべきことは「55.55.0.1 から 55.55.10.1 までの到達性を維持したまま RT-02 から受け取るプレフィックス数を削減する」ですので、単純に RT-02 から通知する経路数を絞ればいいのです。BGP には「経路集約（aggregation）」と言う機能があり、しかも「集約した経路だけを伝える」ことができますので、この条件にぴったりです。

Cisco IOS IP Routing: BGP Command Reference - BGP Commands: A through B [Support]

ありがたいことに、RT-02 が広報しているプレフィックスは連続した10個なので1つの集約経路にまとめて問題なさそうです。

RT-02#show bgp ipv4 uni | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.1.2.0/30      0.0.0.0                  0         32768 i
 *>   55.55.0.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.1.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.2.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.3.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.4.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.5.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.6.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.7.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.8.0/24     0.0.0.0                  0         32768 ?
 *>   55.55.9.0/24     0.0.0.0                  0         32768 ?

と言うことで、RT-02 側で経路集約をします。範囲は特に指定されていませんが、10個より大きいぐらいで足りるので /20 ぐらいでいきましょうか。

RT-02#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
RT-02(config)#router bgp 65002
RT-02(config-router)#aggregate-address 55.55.0.0 255.255.240.0 summary-only
RT-02(config-router)#end

この設定を入れただけでは maximum-prefix limit がかかったネイバとのピアリングは回復しません。前のドキュメントの最下部あたりにこんな記述があります。

注：ピア機能を復元するには、次のコマンドを使用します。
Router_B#clear ip bgp 10.0.0.1

clear ip bgp {ネイバIPアドレス} は、BGP セッションを切断し再接続から始めるための「ハードリセット」動作をさせるためのコマンドです。再接続をする際は互いに多数の経路情報交換を行う負荷の高い処理が実行されるため、おそらく商用環境では投入に制限がかけられているコマンドかと思います。しかし、本問題の環境では

maximum-prefix による Down 解消には本コマンドの投入が必要と公式ドキュメントに明記されている。
NETCON問題環境（非商用環境）であり、コマンド投入に制限はかかっていない。
設問の制約として投入不可とされていない。

のように、当該コマンドの実行を妨げるものは何もなく、逆に「回復に必須のコマンドである」根拠まで存在しています。その状況であれば実施しないわけにはいかないでしょう。と言うことで、RT-01 でハードリセットを実施します。

RT-01#clear bgp ipv4 unicast 10.1.2.2
RT-01#
*Jan  1 07:44:26.767: %BGP-5-ADJCHANGE: neighbor 10.1.2.2 Up
*Jan  1 07:44:26.771: %BGP-4-MAXPFX: Number of prefixes received from 10.1.2.2 (afi 0) reaches 2, max 2
RT-01#show bgp ipv4 unicast summary | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.2.2        4        65002       6       5        7    0    0 00:00:33        2
RT-01#sh bg ipv4 uni | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *    10.1.2.0/30      10.1.2.2                 0             0 65002 i
 *>                    0.0.0.0                  0         32768 i
 *>   55.55.0.0/20     10.1.2.2                 0             0 65002 i

ちゃんとピアも回復し、集約経路の 55.55.0.0/20 も受信できているので、到達性もバッチリです！ふーやれやれ。

コンフィグ

各機器のコンフィグです。

RT-01

version 15.7
!
hostname RT-01
!
interface GigabitEthernet0
 ip address 10.1.2.1 255.255.255.252
 no shutdown
 duplex auto
 speed auto
!
router bgp 65001
 bgp log-neighbor-changes
 network 10.1.2.0 mask 255.255.255.252
 neighbor 10.1.2.2 remote-as 65002
 neighbor 10.1.2.2 soft-reconfiguration inbound
 neighbor 10.1.2.2 maximum-prefix 2
!
!
end

RT-02

version 15.7
!
hostname RT-02
!
interface Loopback0
 ip address 55.55.0.1 255.255.255.0
!
interface Loopback1
 ip address 55.55.1.1 255.255.255.0
!
interface Loopback2
 ip address 55.55.2.1 255.255.255.0
!
interface Loopback3
 ip address 55.55.3.1 255.255.255.0
!
interface Loopback4
 ip address 55.55.4.1 255.255.255.0
!
interface Loopback5
 ip address 55.55.5.1 255.255.255.0
!
interface Loopback6
 ip address 55.55.6.1 255.255.255.0
!
interface Loopback7
 ip address 55.55.7.1 255.255.255.0
!
interface Loopback8
 ip address 55.55.8.1 255.255.255.0
!
interface Loopback9
 ip address 55.55.9.1 255.255.255.0
!
interface GigabitEthernet0
 ip address 10.1.2.2 255.255.255.252
 no shutdown
 duplex auto
 speed auto
!
router bgp 65002
 bgp router-id 10.1.2.2
 bgp log-neighbor-changes
 network 10.1.2.0 mask 255.255.255.252
 redistribute connected
 neighbor 10.1.2.1 remote-as 65001
 neighbor 10.1.2.1 soft-reconfiguration inbound
!
end

小ネタ

今回 RT-02 では10個の Loopback インターフェースを作りましたが、手入力は正直めんどくさいです。こんな時には、ENOG 27 で土屋師子生さんが発表された資料にある tclsh を活用すると便利です。今回私も使いましたが、たったこれだけのスクリプトで作れるのは気軽で良いですね。

tclsh

for {set i 0} {$i < 10} {incr i 1} {
ios_config "interface Loopback $i" "ip address 55.55.$i.1 255.255.255.0"
}

ENOG27 Meeting を開催しました – Echigo Network Operators' Group