ICTSC2018 参加者の皆様、お疲れ様でした。
ICTSC2018 本戦で出題された各問題の解答と解説記事を公開致します。
お待たせしてしまい申し訳ありません。
ミドルウェアグループ LDAPが動かないについては後日公開となります。3/30 20:30頃に 公開しました！大変お待たせいたしました
それでは、ICTSC2019でお会いできる事を楽しみにしています！
今回のインフラを担当したnasuです。
みなさん１年間コンテストに参加してくださってありがとうございました。
今回のコンテストも楽しんでいただけたでしょうか。
また1日目のコンテストサイトの停止などご迷惑をおかけして申し訳ありませんでした。
引き続き運営委員も改善していきたいと考えています。
今回も引き続き機材提供してくださいました企業様、新規で機材提供して頂いた企業様
誠にありがとうございました。お陰様で無事開催ができ、運営学生もインフラ技術を学ぶことができました。
さてこの記事はインフラ解説記事です。
前回も解説記事は書いたので、トラコンバックボーンについてなどの概要は省き
今回は前回とは違う内容を中心に書いていきたいと思います。
ですので前回作成した解説記事も併せて読んで頂けると幸いです。
また以下のスライドは１日目の懇親会の時にお見せしたスライドです。
今回は対外用ルータとしてJuniper MX5をお借りしました。
Juniper MX5は高機能なルータで主に大規模なネットワークで使われています。
MX5はModular Interface Cards(MIC)スロットというものがあり、そこに利用用途に応じてMICを搭載して利用します。
今回はIX3110とQFX5100を、SFPモジュールを利用して接続したかったのでMIC-3D-20GE-SFPを搭載しました。
利用用途としてHomeNOC様(AS59105)とピアを貼り外部への通信と、内部のルーティングを行っています。
またMX5単体ではStatic NATしかサポートされていなく、PATを使うにはMultiservices MICというMICを取り付ける必要があります。
そのため今回はNAPTを行う為に一旦IPv4の通信はIX3110に折り返させて、IX3110でNAPTを行う必要があり、フルルートを持ったグローバルのルーティングテーブルと内部のルーティングテーブルとを分ける必要がありました。
前回に引き続きJuniper QFX5100を2台お借りしました。
今回サーバにはSFPのNICカードが無かったため、QFX5100の方にSFP-1GE-Tのトランシーバを付けRJ45で接続しました。
また２台ありますが論理的に１台の構成(Multi Chassis)は行わずに、別々のSWとして利用し自作仮想基盤n0stackのノードを半々に分けて接続しています。
そして各チームをVRFで分けて運用しQFX5100両機に同じチームのVRFを展開し外に行く通信はNAVTを経由しています。
VRFの運用とトラコン技術のNAVTとついては前回の解説記事のQFX5100編に詳しく書いてあるのでそちらを御覧ください。
この構成ではQFX5100の両機にTeam01のVRFが存在していて、何もしなかったらお互いのVRFは通信を行うことができません。
それをQFX5100をPEルータとしてMP-BGP L3VPNを利用してお互いのVRF間の通信を行っています。
今回インフラでは特にテーマというものは決めませんでしたが、Segment Routingに挑戦してみたいという話しがありました。
今回挑戦したのはSegment Routing MPLSの方です。
Segment Routing MPLSとはIGPでラベル交換を行うことができセグメントによってラベルパスを表すことができます。
Segment Routing MPLS(以下SR)の利点は主に以下の通りです。
– IGPでラベル広告を行えることで実装が楽
– LDP, RSVPを使った従来のMPLSより設定、操作がシンプルで運用が楽
– SR-TE ECMPがサポートされている
– TI-LFAは複雑なトポロジの障害でもバックアップパスを用意することができる
Segment Routing詳細は下記のURLに詳しくスライドがございますのでぜひ御覧ください。
JANOG40 Meeting in Fukushima Segment Routing チュートリアル
今回はシンプルに４台あるのでIGPを使ってラベル広告をし4つのノードを明示的に以下のようなパス選択をするつもりでした。
Primary
– QFX5100-01 → MX5-01 → MX5-02 → QFX5100-02
Backup
– QFX5100-01 → MX5-02 → QFX5100-02
しかしパス選択のところで上手く設定ができず検証期間が過ぎていき実際本番では最短のQFX5100-01とQFX5100-02間で通信していてSR-TEはできていません。
今回運営として主に監視系の構築を行いました北澤です。
今回は前回・前々回大会の電源トラブルの反省を元に、監視基盤をさくらのクラウド上のサーバに構築し、会場とVPNを貼ることで監視を行いました。
これにより、万が一電源トラブル等でサーバ全台が落ちてしまった場合も監視系は落ちないため、サーバ落ちる直前までのメトリクスを元に問題の解決を行うことが出来ると考えました。
また、今大会ではログやメトリクスの収集を行うサーバの負荷分散と冗長化を目的に、収集サービスやDBを全てコンテナ化しKubernetes上で動作させました。
監視構成は以下になります。
Prometheus、Zabbixともに監視項目に異常が起きた際にはSlackに通知を行うようにしました。これにより、実際に二日目開始直前にVMが落ちていたトラブルを発見し、VMを再起動することで問題なく二日目を迎えることができました。
収集したメトリクスを表示するGrafanaでは以下のようなダッシュボードを作成しました。
サーバ全体を俯瞰するダッシュボードと個々のサーバを見るダッシュボードを用意することで、サーバに以上が生じた際に目で見てどの時間に何が起きているのかを把握しやすくしました。
今年の監視系のまとめとして、去年までサーバに直接インストールしていたサービスを全てKubernetes上で動作させることができました。課題点として、KubernetesのPersistentVolumeとKubernetes上で動作するDBの冗長化が行えていないため、来年以降はこれらにも取り組むことが出来れば良いと考えています。
今回は無線LAN環境を提供するために以下の機材をお借りしました。
– Cisco 5508 Wireless Controller
– Cisco AIR-AP-3802I-Q-K9 5台
今回もみなさんにはICTSC2018というSSIDにユーザ名、パスワード認証で各チームのネットワークに接続してもらいました。
Cisco WLCの設定とRadius認証については前回の記事で解説していますのでそちらを御覧ください。
前回と大きく異なる点は会場と2.4Ghzを提供しなかった点です。
会場のNTT調布研修センターは周りにビルや無線LANを飛ばす施設等が無いため、5Ghz帯は混雑はしていませんでした。
またホットステージ・コンテスト中はDFSを一切受けず無線的にはとても快適な会場でした。
DFSにほぼ気をつける必要が無かったため、急に接続してるチャンネルが変更して通信が途切れるということはありませんでした。
また2.4Ghz帯の提供を干渉されやすい・トラブルの元という観点から提供を行いませんでした。
その為2.4Ghzしか使えないパソコンをお持ちの参加者の方には有線ケーブルでの接続をお願いしました。
これによりほぼ全てのユーザがIEEE802.11acで繋ぐことができ安定し高速な無線環境を提供することができました。
アンケート結果からも前回の比で比べると不便だったというだったという方は10%減りました。
しかし一部の端末で時間が経つと接続が切れるという事象が報告されており、運営側ですぐ再現・原因究明ができなかったため、接続が不安定な方には有線接続をお願いしました。
接続が途切れてしまった方にはご迷惑をおかけしました。
今回もバックボーンネットワークには様々な技術を使って構築しました。
様々な技術を使っての構築は難しいですが、運営にとって問題を提供しやすい環境、参加者が快適に問題が解ける環境を追い求め挑戦していきたいです！
そしてトラブルシューティングコンテスト2019開催決定しています！
ぜひ次回もみなさんからの参加お待ちしております！
皆さんはLDAPを使ったことがありますか？
LDAPとは Lightweight Directory Access Protocol の略で、ディレクトリサービスのためのプロトコルです。ディレクトリサービスというのはその名前の通りディレクトリのようなツリー状の情報を管理するサービスで、その特徴からリソースの場所・設定などの情報を一元管理するのに用いられています。
とりわけ大きな組織においてはこのような情報を管理することにおいて大きなメリットがあります。管理すべき機器やユーザの数が膨大になってきたとき、必要に応じて素早く情報にアクセスできることが要求されるためです。
多くの企業ではディレクトリサービスを用いて情報を管理しており、ディレクトリサービスを提供するためのソフトウェアとしてはActive Directoryが代表的です。優れたGUIと長年Microsoftがメンテナンスしてきたことによる実績があり、何よりWindowsマシンを管理するのに長けているからです。
一方で、昔ながらのOpenLDAPを用いる場合もあります。OpenLDAPはLDAPのオープンソース実装の一つであり、高機能なActive Directoryなどに比べて軽量・高速に動作します。先に挙げたActive DirectoryもLDAPをベースに実装されており、LDAPへの理解を深めることはディレクトリサービスを知る上で欠かせないと言えます。
今回出題したトラブルは、LDAPに関する基本的な操作・知識を問う問題でした。LDAPを運用した経験がないと時間内に解くのはなかなか難しかったのではないかと思います。
最近LDAPを導入して、GitLabの認証とサーバへのSSHをLDAP経由で行えるように設定したのだがどうもうまく動いていないようだ。 原因を突き止めて、GitLabにログインできるようにしてほしい。必要に応じてサーバの設定を変えても構わないが、なるべくセキュリティレベルが下がらないようにしてほしい。また、admin (cn=admin,dc=finals,dc=ictsc) とoperator (cn=operator,ou=users,dc=finals,dc=ictsc) のパスワードが脆弱なので、可能であれば指定したものに変更してほしい。
なお、すべてのサーバはLDAPに登録してあるSSH鍵で入れるようになっているはずだが、こちらも同様に動いてないのでLDAPサーバのみにログインできるアカウントとLDAPに登録したSSH秘密鍵を用意した。必要に応じて使ってほしい。
GitLabにLDAPユーザのoperator (パスワード変更済み) でログインに成功する
今回の問題に登場するサーバは全部で2つです。
それぞれにSSSDがインストールされており、sss_ssh_authorizedkeys コマンドを用いてLDAPに登録されている公開鍵でログインできるようになっているはずが、SSHログインできなくなっている状態がスタートです。
また、GitLabのLDAPログインも同様に動かない (SSL errorが発生する) ので、これらを直してほしいという内容です。
初期状態をまとめると以下の図のようになります。
図で×印がついている部分がLDAPで認証を行う部分であり、これらをすべて復旧するのがゴールです。
問題のゴール自体はGitLabでLDAPログインできるようになることとなっていますが、実際には認証を直してGitLabサーバへのSSHログインができるようにならないとトラブルシューティングが行えないため、まずはSSHログインを復活させるのが１つ目のゴールになります。
GitLabでLDAPログインを試みると以下のようなエラーメッセージが出ます。
Could not authenticate you from Ldapmain because “Ssl connect syscall returned=5 errno=0 state=sslv2/v3 read server hello a”.
これはそもそもSSL接続が確立できていないということなので、opensslで確認してみます。
~$ openssl s_client -connect 192.168.2.10:636 CONNECTED(00000003) 140350580467344:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 289 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1552100789 Timeout : 300 (sec) Verify return code: 0 (ok) ---
これを見ればわかるとおり、そもそも証明書が設定されていないことがわかります。
しかし /etc/ldap/slapd.conf を見ると TLSCACertificateFile=/etc/ldap/ssl/ca.crt などの設定がされているため本来は有効化されているはずですが、これらのパラメータは少なくともdebian系のslapdでは正しく動きません。よって適切なLDIFを書いて、手動で有効化してやる必要があります。
dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ldap/ssl/ca.crt - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/ssl/dc.finals.ictsc.key - add: olcTLSCertficateFile olcTLSCertficateFile: /etc/ldap/ssl/dc.finals.ictsc.crt
SSL証明書のパーミッションも正しくしておきましょう。
~$ ls -lhat /etc/ldap/ssl/ total 24K drwxr-xr-x 2 root root 4.0K Feb 17 02:07 . -rw-r--r-- 1 root root 2.0K Feb 17 02:07 ca.crt -rw-r--r-- 1 root root 5.9K Feb 17 02:07 dc.finals.ictsc.crt -rw------- 1 root root 1.7K Feb 17 02:07 dc.finals.ictsc.key drwxr-xr-x 7 root root 4.0K Feb 17 02:07 .. ... ~$ ls -lhat /etc/ldap/ssl/ total 24K drwxr-xr-x 2 root root 4.0K Feb 17 02:07 . -rw-r--r-- 1 root openldap 2.0K Feb 17 02:07 ca.crt -rw-r--r-- 1 root openldap 5.9K Feb 17 02:07 dc.finals.ictsc.crt -rw-r----- 1 root openldap 1.7K Feb 17 02:07 dc.finals.ictsc.key drwxr-xr-x 7 root root 4.0K Feb 17 02:07 ..
先ほどのLDIFを olcSSL.ldif という名前で保存し、以下のコマンドで適用します。
sudo ldapadd -Y EXTERNAL -H ldapi:/// -f olcSSL.ldif
サーバの/etc/ssh/sshd_configを見ると、AuthorizedKeysCommandディレクティブにsss_ssh_authorizedkeysが設定されていることがわかります。しかし試しにこれを実行してみても公開鍵が出力される様子がありません。
~$ /usr/bin/sss_ssh_authorizedkeys operator ~$
これが原因でSSHログインができないことがわかりますが、なぜ公開鍵が取得できないのでしょうか。LDAPの設定を見直しても公開鍵はちゃんと登録されています。
sss_ssh_authorizedkeysコマンドには実はデバッグオプションが存在します（これはhelpでも出てきません）。--debug 10という引数をつけてコマンドを呼び出すと、詳しいエラーメッセージを見ることができます。
~$ ~$ sss_ssh_authorizedkeys operator --debug 10 (Wed Mar 27 20:25:46:414921 2019) [sss_ssh_authorizedkeys] [main] (0x0040): sss_ssh_format_pubkey() failed (22): Invalid argument
このメッセージから、登録されている公開鍵のフォーマットが正しくないと予想できます。もう一度LDAPに登録されている鍵をみてみましょう。
~$ ldapvi -D 'cn=admin,dc=finals,dc=ictsc' -b 'dc=finals,dc=ictsc' ... loginShell: /bin/bash sshPublicKey:; ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJodlzzbHLCCfldHfG7xKlA4tl6t118hAdjbzuZIYCJELLFTwctlFVOBgZHs4JkT5Cgm7eK1VXL99w7SapNzhMs= operator@dc^M\
よく注意して見ると、公開鍵の末尾に改行が含まれていることがわかります。試しに改行を消してみるとどうなるでしょうか。
~$ sss_ssh_authorizedkeys operator ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJodlzzbHLCCfldHfG7xKlA4tl6t118hAdjbzuZIYCJELLFTwctlFVOBgZHs4JkT5Cgm7eK1VXL99w7SapNzhMs= operator@dc
ちゃんと取得することができました。秘密鍵でSSHログインが可能なことも確認できます。
~$ ssh -i files/id_ecdsa operator@192.168.2.10 Last login: Sun Feb 17 03:38:42 2019 from 192.168.2.1 Could not chdir to home directory /home/operator: No such file or directory operator@dc:/$
これで登録してある公開鍵でログインができるようになりました。
GitLabのトラブルシューティングに移る前にパスワードの変更をしておきます。
ldapviを用いてパスワードを変更しようとするとエラーが発生し変更できなかったり、phpLDAPadminにおいてはエラーすら出なかったりします。（この場合も依然として変更はできていません）
このような場合はアクセスコントロールを疑います。/etc/ldap/ldif/olcAccess.ldifが置いてあるのでこの中身をみてみましょう。
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
# password should not be readable and only user can update
olcAccess: to attrs=userPassword
by self =sw
# uid, uidNumber, gidNumber should not be updated
olcAccess: to attrs=uid,uidNumber,gidNumber
by self read
by users read
# for ssh login
olcAccess: to attrs=sshPublicKey
by self write
by group.exact="cn=servers,ou=sgroups,dc=finals,dc=ictsc" read
# for sudo
olcAccess: to dn.children="ou=sudoers,dc=finals,dc=ictsc"
by group.exact="cn=servers,ou=sgroups,dc=finals,dc=ictsc" read
# not matched
olcAccess: to *
by self read
by users read
by anonymous auth
by * none
注目すべきはuserPasswordに対して設定してある項目です。by self =swはsearchとwriteをユーザー自身に許可する設定なので大丈夫なはずですが、by anonymous authがついていないのでbindができないようになっています。
よってolcAccess.ldifのuserPasswordにby anonymous authを追加してあげるとパスワードの変更が可能になります。
SSSDのエラーを修正したことでGitLabにログインが可能になりますが、GitLabのログインページは依然としてエラーを出します。エラーメッセージを読むと証明書周りのエラーということがわかるので、/etc/gitlab/gitlab.rbの中身を確認します。
LDAPの設定部分にverify_certificates: trueとあるので、証明書がチェックに引っかかっていることが原因のようです。これを回避するためには証明書のチェックを無効にするのが一つの手ですが、セキュリティの観点からはあまり好ましい対策とは言えません。証明書 (dc.finals.ictsc) をシステムのチェーンに登録して有効な証明書とするのがベターです。
~$ sudo -s ~# cd /usr/share/ca-certificates/ ~# openssl s_client -showcerts -connect dc.finals.ictsc:636 2>/dev/null | openssl x509 > rootCA.crt ~# echo "rootCA.crt" >> /etc/ca-certificates.conf ~# update-ca-certificatesGitLab上のユーザブロック解除
証明書のエラーを解決するとようやくLDAP認証が動くようになります。しかしoperatorユーザはなぜかログインできず、ブロックされている旨のメッセージが出ます。
これはすでにローカルでoperatorという名前のユーザが登録されていたことが原因ですが、解除するためにはadminアカウントが必要になります。operatorユーザでSSHログインするとsudoでrootになることができるので、GitLabのrails consoleに直接接続してパスワードを書き換えることができます。
~# gitlab-rails console production user = User.where(id: 1).first user.password = 'strongpassword' user.password_confimation = 'strongpassword' user.save!これでadminとしてログインして、
admin areaにあるユーザの設定でLDAPのoperatorユーザを有効にするとログインできるようになります。採点基準
GitLabサーバにログインできるようになるのが一つ目のゴールなので、ここまで到達した場合は満点の50%が得られます。
今回の問題の一番のポイントはLDAPそのもではなく、Undocumentedな仕様を適切に探し出すことができるかという点にありました。OpenLDAPのslapd.confが意図した通りに動かない、SSSDが解釈できる公開鍵のフォーマットに隠された仕様があるなど、ソフトウェアは思わぬところで予想に反する挙動を示すことがあります。事前に知識を持っている場合はすぐに気づくことができますが、多くの場合はそうではありません。今回はLDAP+SSSD+GitLabという、意外と一般的だが普段は使ってなさそうな技術を意図的に選びました。
もっとも高得点を獲得したのはLDAPのSSL証明書の設定を解決したチームでした。残念ながらGitLabサーバへSSHできるところまでたどり着くチームはいませんでしたが、コンテスト時間がこれだけ短く、問題数が多いことを考えると仕方ないのかなと思います。また、得点の高さをみて手をつけなかったチームも結構いたのではないでしょうか。トラコンでは必ずしも問題を解ききる必要はないので、部分点解法を大量に稼いでいくのも一つの戦略です。
同期から次の依頼がありました。
「会社の上司から勉強用にとサーバーをいただきました！
Webページを立ててみたかったのでNginxをインストールしようとしていたのですが、
sudo apt-get install nginx
をするとエラーが出てしまってインストールできないんです…
どうしたら良いんですかね…?」
問題を解決して、インストールがエラーや警告なしで成功するようにしてください。
Nginxをインストールしようとしたがエラーが発生してインストールが完了しない。
今回のトラブルの原因は /var/log 配下にあるファイル全てにi属性(Immutable属性)が付与されていたからでした。
今回のトラブルが起こる流れとして /var/log配下にあるdpkg.logをアップデートしようとするとコピーなどは成功するが、インストール後スクリプト(post_install)の実行時にdpkg.logファイルの権限変更(chmod)が失敗し、インストール失敗(再インストール)としてマークされます
そして、次回インストール時にpost_installスクリプトが実行されるように予約がされます。
なので、Nginx(その他のパッケージ)をインストールしようとすると再インストールがマークされたdpkgが優先的にインストールされようとしますが、同じ理由で再失敗するのでそれ以降のインストールが無視される(インストール失敗とマークされる)といった流れでした。
ですので、今回は以下のコマンドでdpkg.logのi属性をはずしたらインストールは完了します。
また、今回のゴールはNginxがapt-getによってエラーや警告なしにインストールされているも含まれています。
エラーや警告を解決していない回答が多く見られました。
今回エラーや警告が出ていた原因は/var/logのaptディレクトリにもi属性が付与されていたためです。
なので、aptディレクトリもi属性をはずしたら今回のトラブルは解決です。
$ cd /var/log $ sudo chattr -i dpkg.log
もしくは
$ sudo rm -rf /var/lib/dpkg/info/dpkg.postinst $ sudo rm -rf /var/lib/dpkg/info/dpkg.postrm $ sudo dpkg --configure dpkg
以上のようにNginxのインストールに成功すれば手段は問わず50%の点数を与えました。
$ cd /var/log $ sudo chattr -i * $ sudo apt-get install nginx
2行目が sudo chattr -i aptでも問題ありません。
Nginxのインストール時にエラーや警告がでなければ100%の点数を与えました。
通信事業者である「Ictsc Fiber」では最近、MP‐BGPの検証を行っています。 今日も、Loopbackを用いてピアを張り、ルート共有を行う検証を同僚が行っていました。 ですが、上手くピアを張ることができずあなたに助けを求めに来ました。 原因を究明して解決し、正常にピアを張ってください。またピアを張った後に、図に示す「1841-A」の「Loopback 1」のルート共有を行ってください。
MP-BGPの設定を行い、Loopback間でピアを張ろうとしたが上手く張れません。以下の図に示す「C1941」と「1841-A」に設定を追記し、ピアを正常に張れるようにしてください。 また、1841-Aの「Loopback 1」のルート情報を共有し、C1941から1841-Aの「Loopback 1」へ疎通可能にしてください。
今回の問題では、MP-BGPと呼ばれる技術を用いてルータ間でのIPv6ルートの共有を行おうとしています。 MP-BGPとは正式名称で「Multi Protocol BGP」と呼ばれ、Ipv4以外のプロトコルに対応しています。そのため、IPv6プロトコルを使用することができます。MP-BGPでも、ピアを確立しルート共有を行うという順番は変わりません。
MP-BGPでEBGPピアを張る際には、BGPと同じ様にEBGP Neighborの設定が必要になります。また、BGPと違ってaddress familyと呼ばれる設定をする必要があります。今回は以下の設定がそれぞれの機器に行われていました。
router bgp 1 no bgp default ipv4-unicast bgp router-id 1.1.1.1 neighbor fd00:173::1 remote-as 2 address-family ipv6 unicast neighbor fd00:173::1 activate
router bgp 2 no bgp default ipv4-unicast bgp router-id 2.2.2.2 neighbor fd00:172::1 remote-as 1 address-family ipv6 unicast neighbor fd00:172::1 activate物理インタフェースを用いるのであれば、これらの設定でピアを張ることができます。
ですが、今回の問題はLoopbackを用いてピアを張る必要があるため、追加で設定を加える必要があります。 実際に追加する必要がある設定は以下になります。
ipv6 route fd00:173::/64 fd00:171::2 neighbor fd00:173::1 update-source loopback 0 neighbor fd00:173::1 ebgp-multihop 2
ipv6 route fd00:172::/64 fd00:171::1 neighbor fd00:172::1 update-source loopback 0 neighbor fd00:172::1 ebgp-multihop 2各機器に設定する項目は同じです。これらの設定を加えることでLoopback間でピアを張ることができます。 追加設定の内容について説明していきます。
ipv6 route ipv6_network_address nexthopこの設定は、IPv6でのスタティックルートを追加するものです。EBGPピアを張る際は、ピアの宛先のアドレスに疎通性がないと張ることが出来ません。初期の設定のままでは、疎通性がないためスタティックルートを追加する必要があります。
neighbor ipv6_network_address update-source loopback 0ピアを張る際に送るメッセージを送る送信元は、デフォルトでは物理インターフェースに指定されているためLoopback 0 間でピアを張ることができません。そのため、送信元をLoopback 0に指定する必要があります。
neighbor ipv6_network_address ebgp-multihop 2EBGPピアを張る際の送るメッセージのTTL(Time to Live)はデフォルトで「1」に設定されています。そのため、Loopbackを用いてピアを張る場合、TTLが１より大きくなってしまうためパケットが捨てられてしまいメッセージが宛先に届きません。そのため、この設定によってTTLの数を増やす必要があります。因みに、最後の値の部分を指定しないと、「255」に設定されます。
以上の設定によって、ピアを張ることができます。
さらに、今回の問題では、ピアを張ることが出来たら1841-Aの「Loopback 1」のネットワークをMP-BGPによって共有を行うという指定がありました。それを踏まえてルート共有を行う設定は以下のとおりです。
router bgp 2 address-family ipv6 unicast network fd00:174::/64この設定を行うとMP-BGPでのルート共有が行われます。
回答例
ipv6 route fd00:173::/64 fd00:171::2 router bgp 1 neighbor fd00:173::1 update-source loopback 0 neighbor fd00:173::1 ebgp-multihop 2
ipv6 route fd00:172::/64 fd00:171::1 router bgp 2 neighbor fd00:172::1 update-source loopback 0 neighbor fd00:172::1 ebgp-multihop 2 address-family ipv6 unicast network fd00:174::/64採点基準