ICTSC2021 冬の陣にご参加いただいた学生の皆様、お疲れ様でした。
今回のICTSC2021 冬の陣は前回のICTSC2021の運営、それに加えて機材の提供や作問などでご助力いただいたスポンサー様方のおかげでなんとか開催し無事終了することができました 。参加していただいた方々につきましては、ここで培った知識・技術を今後に活かしていただければと思います。
今回出題した問題の問題文、及び問題解説を公開します。
ぜひ今後の研鑽にご利用いただければと思います。
ICTSC2021 夏の陣にご参加いただいた学生の皆様、お疲れ様でした。
今回のICTSC2021 夏の陣は前回のICTSC2020の運営と新しいメンバー、それに加えて機材の提供や作問などでご助力いただいたスポンサー様方のおかげでなんとか開催し無事終了することができました 。参加していただいた方々につきましては、ここで培った知識・技術を今後に活かしていただければと思います。
今回出題した問題の問題文、及び問題解説を公開します。
ぜひ今後の研鑽にご利用いただければと思います。
Container
k8s
Linux
Program
iscsi
Routing
Security
DHCPv6
SSH
VPN
Web
ICTSC2020 本選にご参加いただいた学生の皆様、お疲れ様でした。
今回のICTSC2020を以ってICTSCは活動休止となり、学生の皆様は非常に驚かれたと思います。我々運営としても、こういった活動の場が無くなってしまうのは非常に寂しいですが、ここで培った知識・技術を今後に活かしていただければと思います。
今回出題した問題の問題文、及び問題解説を公開します。
ぜひ今後の研鑽にご利用いただければと思います。
Container
DNS
FTP
k8s
Linux
LoadBalancer
Program
Routing
Tunnel
Web
ICTSC2020の予選にご参加いただいた皆様、お疲れ様でした。
本戦に出場が決定した皆様、おめでとうございます。本戦で存分に力を発揮してもらいたいと思います。
また、残念ながら本戦出場ラインに到達できなかった皆様はぜひ経験をバネとし、次回以降のICTSCにご応募いただければと思います。
今回出題した問題の問題文、及び問題解説を公開します。
過去の問題を解いた上で学習し、ぜひ今後の研鑽にご利用いただければと思います。
ルーティング
ウェブ
コンテナ
データベース
プログラミング
ICTSC2019 本選に参加してくださった皆さん、お疲れ様でした！また、参加していただきありがとうございました！！
以下はICTSC2019 本選で出題した問題の各解説へのリンク集です。ICTSC2019 本選に参加していただいたみなさんの復習や、次回以降参加する方の参考になれば幸いです。
各問題の解説は順次投稿します。2020年 3/1 中に投稿を完了する予定です。
一日目
コンテナ
ウェブ
トンネリング
パケットフィルタ
ルーティング
データベース
メール
その他
二日目
コンテナ
トンネリング
パケットフィルタ
ルーティング
データベース
IPv6
その他
/
カテゴリー
問題名
インターネットにつながらない！
概要
あなたはネットワーク開発部で働いています。すると、上司があなたに次のようなことを言ってきました。
最近、BGP unnumberedを使って大規模なネットワークを作るのが流行っているらしい。
BGP unnumberedを支える技術の一つにRFC5549という仕様があるらしくて、ちょっとそれを試す環境を作ってみたんだが、上手く通信できないんだ。
君はネットワークが詳しいらしいし、何が原因なのか調べてくれないかい？
上司はそういうと、メモとトポロジ図をおいてどこかに行ってしまいました。原因を解決してあげてください。
上司からのメモ
- probrt, rt01, rt02には、FRRがインストールされている
- それぞれのルータはmgmt VRFを切っているため、普通にはインターネットに接続することができない
- apt updateをしたいならば、以下のようなコマンドを実行する必要がある
sudo ip vrf exec mgmt apt update
- apt updateをしたいならば、以下のようなコマンドを実行する必要がある
- probrt, rt01には正しい設定が入っているので、それに合わせてrt02の設定を行ってほしい
- 再起動しても、問題なく動作するように設定を行ってほしい
トポロジ図
前提条件
- sv01, rt02のmgmt VRFに対する操作を行わない
- 問題環境に接続できなくなる可能性があるので
- eth0をmgmt VRFから外さない等
- BGP以外の方法を用いて経路の設定を行わない
初期状態
- sv01からインターネットにアクセスすることができない
- 下記のコマンドが正常に実行できない
ping 1.1.1.1
- 下記のコマンドが正常に実行できない
終了状態
- sv01からインターネットにアクセスすることができる
- ここでは、下記のコマンド群が正常に実行でき、適切な結果を返す
ping 1.1.1.1dig @1.1.1.1 A contest.ictsc.netcurl https://www.icttoracon.net
- 解答には、これらのコマンドの実行結果も示してください
- ここでは、下記のコマンド群が正常に実行でき、適切な結果を返す
- rt02を再起動しても、設定が維持されるようにしてほしい
想定解答
この問題では、三つの原因によってsv01のインターネットへの疎通性が失われていました。
- rt02がrt01に対し、Extended Nexthop capabilityを送信していない
- rt02でIP転送が許可されていない
- rt02にprobrtとの経路制御に利用するポリシーが設定されていない
これらを設定することでsv01からインターネットに通信することができるようになります。
1. rt02がrt01に対し、Extended Nexthop capabilityを送信していない
sudo vtysh を利用して以下の設定をFRRに投入します。
router bgp 65182 neighbor fc00:1:: capability extended-nexthop
2. rt02でIP転送が許可されていない
以下の設定を/etc/sysctl.confに追記します。
net.ipv4.conf.all.forwarding = 1
3. rt02にprobrtとの経路制御に利用するポリシーが設定されていない
sudo vtysh を利用して以下の設定をFRRに投入します。
router bgp 65182 no bgp ebgp-requires-policy
4. 設定の永続化とロード
1~3で行った設定を永続化したりロードしたりするために、以下のコマンドを実行します。
$ sudo sysctl -p $ sudo vtysh -c "write" -c "clear ip bgp *"
これらの設定を行うことで、sv01からインターネットへ通信を行うことができるようになります。以下は、それぞれのコマンドの出力結果です。
（コマンドの出力結果は省略します）
解説
この問題は、BGP unnumberedの背景にあるRFC5549に関する設定やちょっとしたネットワークのトラブルが原因の問題でした。想定解法にもある通り、以下の三つの原因で問題が発生していました。
- rt02がrt01に対し、Extended Nexthop capabilityを送信していない
- rt02でIP転送が許可されていない
- rt02にprobrtとの経路制御に利用するポリシーが設定されていない
RFC5549（RFC8950）について
問題の詳しい解説に入る前に、RFC5549とは何なのかについて簡単に解説します。RFC5549とは、Multiprotocol BGP（MP-BGP）において、IPv4プレフィックスの経路のnexthopにIPv6アドレスを指定できるようにする拡張仕様です。もうちょっと噛み砕いた言い方をすると「172.16.0.0/24宛のパケットはfc00::1に転送してね」というような経路をBGPで広報できるようにする仕様です。
問題文中にもある通り、この仕様はBGP unnumberedという技術に利用されています。従来、BGPでは対向ルータのアドレスを指定する必要がありましたが、BGP unnumberedでは、その代わりに「eth1に接続されたルータ」のようにインターフェースを指定してBGPピアを指定することができるようになります。通信に使われるアドレスは、そのインターフェースから受信したRouter Advertisementに含まれるリンクローカルアドレスが利用されます。
BGP unnumberedを利用すると、大量のスイッチが収容されるデータセンターなどのネットワークにおいて、対向のスイッチのアドレスを意識することなく設定を行うことができるため、設定の簡素化を実現することができます。以下の記事でとても詳しく解説が行われているため、より詳しいことが知りたい場合には目を通してもらえたらと思います。
この背景を踏まえた上で、今回の問題について見ていきましょう。
想定解法の解説
まずは、sv01から1.1.1.1に対してパケットを送信するときに、どこまでパケットが到達しているのかを調べてみます。tracerouteを使って調べてみると、次のような結果が得られます。
[email protected]:~$ traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets 1 _gateway (172.16.0.254) 0.859 ms !N 0.820 ms !N *
これより、172.16.0.254（rt01）からDestination Net Unreachableが返っていていることが確認できます。問題設定から、rt02はrt01に対してdefault routeを広報しているはずです。このこととtracerouteの結果から、パケットが転送されない原因として以下のような原因が考えられます。
- そもそもrt02がdefault routeを広報していない
- rt02が広報している経路がおかしい
- rt02から広報した経路がrt01のFIBに入っていない
- …
問題の設定よりrt01には適切な設定が入っているとされているため、三つ目の原因が起こることはないだろうと考え、上の二つの原因について考えていきます。
まずは、一つ目の原因について考えてみましょう。これを確かめるためには、rt02がrt01に対して広報している経路を確認すればよいです。その結果を以下に示します。これを見ると、Originating default network 0.0.0.0/0 とあるため、広報自体は行われていそうです。
rt02# show bgp ipv4 unicast neighbors fc00:1:: advertised-routes
BGP table version is 0, local router ID is 192.168.20.3, vrf id 0
Default local pref 100, local AS 65182
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Originating default network 0.0.0.0/0
次に、二つ目の原因について考えてみましょう。rt02が広報した経路がおかしいことを確認するためにはいくつかの方法がありますが、ここでは実際にBGPパケットを見て確認してみましょう。rt02がrt01に対してdefault routeを広報しているUPDATEメッセージを見ると、NEXT_HOPに192.168.20.3というアドレスが指定されていることが分かります。ですが、rt01とrt02の間はIPv6のリンクで接続されているため、rt01はrt02にパケットを転送することができません。これらの情報から、RFC5549が利用できない状態になっているのではないかと推測することができます。
Frame 37: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits) on interface eth1, id 0
...
Internet Protocol Version 6, Src: fc00:2::, Dst: fc00:1::
0110 .... = Version: 6
...
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 46
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 22
Path attributes
Path Attribute - ORIGIN: IGP
Flags: 0x40, Transitive, Well-known, Complete
0... .... = Optional: Not set
.1.. .... = Transitive: Set
..0. .... = Partial: Not set
...0 .... = Extended-Length: Not set
.... 0000 = Unused: 0x0
Type Code: ORIGIN (1)
Length: 1
Origin: IGP (0)
Path Attribute - AS_PATH: empty
Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
0... .... = Optional: Not set
.1.. .... = Transitive: Set
..0. .... = Partial: Not set
...1 .... = Extended-Length: Set
.... 0000 = Unused: 0x0
Type Code: AS_PATH (2)
Length: 0
Path Attribute - NEXT_HOP: 192.168.20.3
Flags: 0x40, Transitive, Well-known, Complete
0... .... = Optional: Not set
.1.. .... = Transitive: Set
..0. .... = Partial: Not set
...0 .... = Extended-Length: Not set
.... 0000 = Unused: 0x0
Type Code: NEXT_HOP (3)
Length: 4
Next hop: 192.168.20.3
Path Attribute - LOCAL_PREF: 100
Flags: 0x40, Transitive, Well-known, Complete
0... .... = Optional: Not set
.1.. .... = Transitive: Set
..0. .... = Partial: Not set
...0 .... = Extended-Length: Not set
.... 0000 = Unused: 0x0
Type Code: LOCAL_PREF (5)
Length: 4
Local preference: 100
Network Layer Reachability Information (NLRI)
0.0.0.0/0
NLRI prefix length: 0
NLRI prefix: 0.0.0.0
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 0
これを確かめるために、rt01とrt02の間でどのような設定でBGPピアが確立しているのかを確認してみましょう。Extended nexthopの欄を見てみると、advertised and receivedではなく、receivedとなっています。この事から、rt02はRFC5549の動作に必要なExtended Nexthop capabilityをrt01に対して送っていないことが分かります。
rt02# show bgp neighbors fc00:1::
BGP neighbor is fc00:1::, remote AS 65182, local AS 65182, internal link
Hostname: rt01
BGP version 4, remote router ID 172.16.0.254, local router ID 192.168.20.3
BGP state = Established, up for 00:50:43
Last read 00:00:43, Last write 00:00:43
Hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
Extended Message: advertised and received
AddPath:
IPv4 Unicast: RX advertised and received
Extended nexthop: received
Address families by peer:
IPv4 Unicast
Route refresh: advertised and received(old & new)
Enhanced Route Refresh: advertised and received
Address Family IPv4 Unicast: advertised and received
Hostname Capability: advertised (name: rt02,domain name: n/a) received (name: rt01,domain name: n/a)
Graceful Restart Capability: advertised and received
Remote Restart timer is 120 seconds
Address families by peer:
none
...
FRRでExtended Nexthop capabilityを有効にするには、以下のコマンドを実行します。
rt02# conf t rt02(config)# router bgp 65182 rt02(config-router)# neighbor fc00:1:: capability extended-nexthop
再度、rt01とrt02の間でどのようにBGPのピアが接続されているのかを確認してみましょう。今度は、advertised and receivedとなっています。これによって、rt01でもrt02から広報された経路を利用することができそうです。
BGP neighbor is fc00:1::, remote AS 65182, local AS 65182, internal link
Hostname: rt01
BGP version 4, remote router ID 172.16.0.254, local router ID 192.168.20.3
BGP state = Established, up for 00:00:13
Last read 00:00:12, Last write 00:00:12
Hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
Extended Message: advertised and received
AddPath:
IPv4 Unicast: RX advertised and received
Extended nexthop: advertised and received
Address families by peer:
IPv4 Unicast
Route refresh: advertised and received(old & new)
Enhanced Route Refresh: advertised and received
Address Family IPv4 Unicast: advertised and received
Hostname Capability: advertised (name: rt02,domain name: n/a) received (name: rt01,domain name: n/a)
Graceful Restart Capability: advertised and received
Remote Restart timer is 120 seconds
Address families by peer:
none
実際に、この設定を加えてからtracerouteを再実行してみると、次のように転送が続いていることが分かります。
[email protected]:~$ traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets 1 _gateway (172.16.0.254) 0.796 ms 0.880 ms 0.840 ms 2 * * * 3 * * * 4 * * *
ですが、rt02でtcpdumpをしてみても、eth1で受信したパケットがeth2から送信されていないことが分かります。
[email protected]:~$ sudo tcpdump -ni eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 10:41:10.189211 IP 172.16.0.1 > 1.1.1.1: ICMP echo request, id 3, seq 1, length 64 10:41:11.191493 IP 172.16.0.1 > 1.1.1.1: ICMP echo request, id 3, seq 2, length 64 10:41:12.215471 IP 172.16.0.1 > 1.1.1.1: ICMP echo request, id 3, seq 3, length 64 10:41:13.725684 IP6 fe80::9ea3:baff:fe30:152e > ff02::1: ICMP6, router advertisement, length 56 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel [email protected]:~$ sudo tcpdump -ni eth2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel
Linuxでパケットが転送されない場合、以下のような原因が考えられます。
- そもそもパケットが転送される設定になっていない
- パケットの宛先への経路が存在しない
- iptablesなどでパケットがDROPしている
- …
これらの原因を一つずつ考えてみましょう。一つ目の「そもそもパケットが転送される設定になっていない」というのは、sysctlを使って確かめることができます。以下に結果を示します。rt02はパケットが転送されるような設定になっていないことが分かります。
[email protected]:~$ sudo sysctl -a | grep ipv4 | grep forwarding net.ipv4.conf.all.bc_forwarding = 0 net.ipv4.conf.all.forwarding = 0 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.default.bc_forwarding = 0 net.ipv4.conf.default.forwarding = 0 net.ipv4.conf.default.mc_forwarding = 0 net.ipv4.conf.eth0.bc_forwarding = 0 net.ipv4.conf.eth0.forwarding = 0 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.eth1.bc_forwarding = 0 net.ipv4.conf.eth1.forwarding = 0 net.ipv4.conf.eth1.mc_forwarding = 0 net.ipv4.conf.eth2.bc_forwarding = 0 net.ipv4.conf.eth2.forwarding = 0 net.ipv4.conf.eth2.mc_forwarding = 0 net.ipv4.conf.lo.bc_forwarding = 0 net.ipv4.conf.lo.forwarding = 0 net.ipv4.conf.lo.mc_forwarding = 0 net.ipv4.conf.mgmt.bc_forwarding = 0 net.ipv4.conf.mgmt.forwarding = 0 net.ipv4.conf.mgmt.mc_forwarding = 0
また、FRRの設定からも転送が有効になっていないことが確認できます。
rt02# show running-config Building configuration... Current configuration: ! frr version 8.1 frr defaults traditional hostname rt02 log syslog informational no ip forwarding no ipv6 forwarding service integrated-vtysh-config
この原因を解決するためには、以下のようなコマンドを実行すればよいです。
[email protected]:~$ echo 'net.ipv4.conf.all.forwarding=1' | sudo tee -a /etc/sysctl.conf net.ipv4.conf.all.forwarding=1 [email protected]:~$ sudo sysctl -p net.ipv4.conf.all.forwarding = 1
次に、二つ目の「パケットの宛先への経路が存在しない」について考えてみましょう。Linuxのルーティングテーブルを表示させてみると、default routeが存在していないことがわかります。この経路はprobrtから広報されているはずなのですが、何らかの理由で経路がルーティングテーブルに入っていないことが分かります。
[email protected]:~$ ip route show 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 172.16.0.0/24 nhid 214 via inet6 fc00::1 dev eth1 proto bgp metric 20
BGPのピアの様子を次のコマンドで確認してみると、10.0.0.2（probrt）とやり取りしている経路（PfxRcd, PfxSnt）の欄に(Policy)と書かれていることが分かります。多くのルータでは、eBGPピアに経路を広報する際に、どんな経路を送信/受信してよいかを示したprefix-listを付ける必要があります。今回はその設定が抜けているため、probrtから広報された経路をrt02で受信することができなくなっていました。
rt02# show bgp summary IPv4 Unicast Summary (VRF default): BGP router identifier 192.168.20.3, local AS number 65182 vrf-id 0 BGP table version 1 RIB entries 1, using 184 bytes of memory Peers 2, using 1446 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc 10.0.0.2 4 65971 118 118 0 0 0 00:50:16 (Policy) (Policy) N/A fc00:1:: 4 65182 121 125 0 0 0 00:14:14 1 1 N/A Total number of neighbors 2
この問題を解決するためには、以下の二つの方法が考えられますが、ここでは簡単に最初の方法で解決をします。
- eBGPでもprefix-list無しで経路を送受信できるようにする
- prefix-listを設定する
rt02# conf t rt02(config)# router bgp 65182 rt02(config-router)# no bgp ebgp-requires-policy
この設定を行った後に、probrtとのBGPピアをリセットすると問題が解決します。
rt02# clear ip bgp 10.0.0.2
補足
FRRのIP転送の挙動について
解答を送信してきたほぼ全てのチームで、vtyshから以下のコマンドを実行してIP転送を許可していました。
ip forwarding
このコマンドを実行すると、確かにIP転送されるようになりますし、writeすると永続化しているように感じるのですが、実際には再起動をしてもIP転送は無効の状態で起動します。この奇妙な挙動にハマって永遠と270点で採点されたチームもいるかと思います。問題として意図したものではないのですが、ハマるポイントなので注意する必要があります。
RFC5549とBGP unnumberedについて
よく誤解されるポイントなのですが、RFC5549とBGP unnumberedは別のものを指しています。
RFC5549は「MP-BGPでIPv4のプレフィックスのnexthopにIPv6アドレスを指定できるようにする仕様」のことを指しています。
それに対し、BGP unnumberedは「RFC5549やRAによるアドレス学習を用いてBGPピアをインターフェース名から自動で設定する技術」のことを指しています。unnumberedという言葉は、インターフェースに明示的なアドレスを設定しないことから来ています。
そのため、今回の問題のようにIPv6アドレスを設定しているような場合には「BGP unnumberedを利用している」と表現するのは適切ではないです。問題文中でも上司が「BGP unnumberedを支える技術の一つにRFC5549という仕様があるらしいんだが」というように説明をしています。
問題文中のRFC5549という表記について
ここまで長々とRFC5549について解説してきましたが、現在ではRFC5549はobsoluteされており、RFC8950という仕様になっています。変更点は非常に小さなものなので、大枠は変わらないのですが、問題文中では古い番号を参照し続けています。解説では問題文と一貫性を保つために、RFC5549と呼び続けていますが、この点について注意してもらえたらと思います。
採点基準
- (40%) Extended Nexthop capabilityがないことに気づき、設定を行う
- (40%) IP転送が許可されていないことに気づき、設定を行う
- vtyshで
ip forwardingを実行した場合でも、sysctlをいじった場合でも等しく点数を与えています
- vtyshで
- (20%) probrtからのdefault routeを受信できるように設定を行う
no bgp ebgp-requires-policyでも明示的にprefix-listを書いた場合でも等しく点数を与えています
- (-10%) FRRの設定が永続化されていない
- (-10%) IP転送の設定が永続化されていない
作問者からのコメント
本当はちゃんとBGP unnumberedな問題として出題したかったのですが、環境等の制約からExtended Nexthopに関する部分だけで出題することになりました。この問題の背景には、これまでのデータセンターネットワークの発展の軌跡が隠れているため、楽しんでいただけたならとても嬉しいです。
/
カテゴリー
問題名
cilium-bgp
概要
cilium+BGPをdocument(https://docs.cilium.io/en/stable/gettingstarted/bgp/) 通りに構築したが、うまくいかない。
何が間違っているのかと、Ingress Nginxまで構築、検証してほしい。
- ingress-nginxを構築する際には、helmを利用し構築すると良い。
helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace
前提条件
問題の意図から外れないこと。
初期状態
一部のPodがContainerCreatingの状態から進まない。
終了状態
Nginx IngressをService Type LoadBlancerで構築し、該当のexternal IP(192.168.26.10)に踏み台サーバからアクセスをすると404が返ってくる。
解説
調査
CNIである、ciliumのPodがcrashしているため他のPodが立ち上がらない。
ciliumのPodのLogを確認しみる。
kubectl logs cilium-x6trf -n kube-system
すると以下のログが見れる。
level=fatal msg="Failed to open BGP config file" error="open /var/lib/cilium/bgp/config.yaml: no such file or directory" subsys=bgp-speaker
修正
原因はciliumのbgp-configというConfigMapが誤っていたことによるもの。
MetalLBのconfig-mapに似ているが、違う点がある。
修正前
apiVersion: v1
kind: ConfigMap
metadata:
namespace: kube-system
name: bgp-config
data:
config: |
peers:
- peer-address: 192.168.26.254
peer-asn: 65020
my-asn: 65021
address-pools:
- name: default
protocol: bgp
addresses:
- 192.168.26.10/31
修正後
apiVersion: v1
kind: ConfigMap
metadata:
namespace: kube-system
name: bgp-config
data:
config.yaml: |
peers:
- peer-address: 192.168.26.254
peer-asn: 65020
my-asn: 65021
address-pools:
- name: default
protocol: bgp
addresses:
- 192.168.26.10/31
diff
7c7 < config: | --- > config.yaml: |
また、修正しNginx Ingressを構築してcurlなどでIngressから404が返ってくることを確認する。
/
カテゴリー
問題名
応答なし
概要
生きているマシンからICMP応答が返ってこない！
前提条件
- default gatewayなどの設定を変えてはならない。
- 永続化されていること
初期状態
host01からhost02へpingコマンドで応答がない。
終了状態
host01からhost02へping コマンドで応答が確認できる。
また、host01を再起動しても問題なく応答する。
解説
問題環境の、以下のファイルにある設定が問題でした。
# /etc/sysctl.d/10-network-security.conf net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1
このフィルタはの設定値では、パケットの入ってくる経路と出て行く経路が違う(非対称なルーティング)場合に破棄するようになっています。
今回、host01は2つNICを持っており、非対称なルーティングの設定が行われていたためパケットの破棄が行われていました。
rp_filterは以下の数値の設定があります
0 => 無効
1 => Strict Mode
2 => Loose Mode
また、OSによるdefaultの値は以下です。
Ubuntu2004のDefault => 2(Loose Mode)
CentOS7のDefault => 1(Strict Mode)
今回は、0 もしくは 2 を設定すれば解決します。
/
カテゴリー
問題名
無限クリック
概要
thunarからダブルクリックでHTMLファイルを開きたいが、ダブルクリックしてもないもうまくファイルを開けません。原因を特定して解決してください。
前提条件
対象端末への接続はVNCを使用してください。
初期状態
thunarからファイルをダブルクリックした際にfirefoxでhtml開いてくれない。
終了状態
thunarからファイルをダブルクリックした際にfirefoxでhtml開き、ファイルを閲覧できる。
解説
X windows systemdでは、mimeと呼ばれる設定ファイルを使い、拡張子とアプリケーションの紐付けを行います。それが間違った紐付けになっていたのが原因でした。
xdg-mime default firefox.desktop text/htmlを実行することで、正しい紐付けになります。
mimeapps.listを直接編集することや、GUIのファイルエクスプローラーなどから右クリックで設定することもできるので、それらの解答も正解としました。