【MiraiNet】JANOG55 NETCON 2-4 問題解説
あいさつ
みなさんこんにちは。ミライネット技術部ネットワークチームの篠田です。
今回はJANOG55で開催されたNETCONにスタッフとして参加し、問題を2問作成しましたので
本記事ではオンライン問題:2-4について解説を書いていきます。
(もう一つの現地問題4の解説についてはコチラ)
問題文
あなたの後輩A君は古くなったSV-10をSV-20に移行するため、一時的にRT-01とRT-03を接続するRT-02を準備しました。
RT-01はBGPが動いていたので、RT-01/RT-02間はBGPを、RT-03はstatic routeしか使用できない機器だったのでRT-02/RT-03間はstatic routeを用いて設定を行いました。
各RT間、RTとサーバ間のリンクはアップしましたが、SV-10とSV-20で通信ができません。
SV-10(192.168.0.10)とSV-20(192.168.1.20)の間で通信ができるように設定を修正しましょう。
達成条件
・SV-10とSV-20の間でpingによる疎通確認が取れること
SV-10 ping 192.168.1.20
SV-20 ping 192.168.0.10
制約
・RT-01の設定変更禁止
・RT-03へのログイン不可
解説
この問題はSV-10とSV-20の疎通性がない状態を修正するという問題です。
まずは状態確認から
SV-10からSV-20への到達性の確認
SV-10:~# traceroute -q1 -n -m5 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 5 hops max, 46 byte packets
1 192.168.0.1 0.005 ms
2 *
3 *
4 *
5 *
SV-10:~# ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
^C
— 192.168.1.20 ping statistics —
4 packets transmitted, 0 received, 100% packet loss, time 3098ms
SV-10:~# ip r
10.1.2.0/24 via 192.168.0.1 dev eth1
10.255.0.0/29 via 192.168.0.1 dev eth1
172.20.20.0/24 dev eth0 proto kernel scope link src 172.20.20.6
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.10
192.168.1.0/24 via 192.168.0.1 dev eth1
SV-20からSV-10への到達性の確認
SV-20:~# ip r
10.2.3.0/24 via 192.168.1.1 dev eth1
10.255.0.0/29 via 192.168.1.1 dev eth1
172.20.20.0/24 dev eth0 proto kernel scope link src 172.20.20.5
192.168.0.0/24 via 192.168.1.1 dev eth1
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.20
SV-20:~#
SV-20:~#
SV-20:~#
SV-20:~# ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
^C
— 192.168.0.10 ping statistics —
4 packets transmitted, 0 received, 100% packet loss, time 3069ms
SV-20:~# traceroute -q1 -n -m5 192.168.0.10
traceroute to 192.168.0.10 (192.168.0.10), 5 hops max, 46 byte packets
1 192.168.1.1 0.004 ms
2 10.2.3.2 0.675 ms
3 *
4 *
5 *
SV-10からSV-20への通信はRT-01のeth2までの到達性があることが分かり、
SV-20からSV-10への通信はRT-02のeth2までは到達性があることが確認できます。
このことからRT-01、RT-02間で何らかの問題がおきていそうなことが分かります。
次にRT-01、RT-02の経路を確認します。
root@RT-01> show route table inet.0
inet.0: 11 destinations, 11 routes (9 active, 0 holddown, 2 hidden)
+ = Active Route, – = Last Active, * = Both
10.1.2.0/24 *[Direct/0] 00:10:29
> via eth2
10.1.2.1/32 *[Local/0] 00:10:29
Local via eth2
10.255.0.1/32 *[Direct/0] 00:10:29
> via lo
10.255.0.2/32 *[Static/5] 00:10:29
> to 10.1.2.2 via eth2
10.255.0.3/32 *[Static/5] 00:10:29
> to 10.1.2.2 via eth2
172.20.20.0/24 *[Direct/0] 00:10:30
> via eth0
172.20.20.4/32 *[Local/0] 00:10:30
Local via eth0
192.168.0.0/24 *[Direct/0] 00:10:29
> via eth1
192.168.0.1/32 *[Local/0] 00:10:29
Local via eth1
RT-02#sh ip ro | b Gateway
Gateway of last resort:
S 0.0.0.0/0 [1/0]
via 172.20.20.1, Management0
C 10.1.2.0/24
directly connected, Ethernet1
C 10.2.3.0/24
directly connected, Ethernet2
C 10.255.0.2/32
directly connected, Loopback0
C 172.20.20.0/24
directly connected, Management0
B E 192.168.0.0/24 [200/0]
via 10.1.2.1, Ethernet1
S 192.168.1.0/24 [1/0]
via 10.2.3.3, Ethernet2
RT-01のルーティングテーブルを確認すると192.168.1.0/24の経路がない為、
RT-01を経由してSV-20が接続されているセグメントへの到達性がなくなっているようです。
RT-02は192.168.0.0/24の経路をRT-01から受け取れているため、問題なさそうです。
このことからRT-01とRT-02の間で経路交換がうまくいっていないということが分かります。
問題文をみるとRT-01とRT-02間でBGPによる経路交換をしているはずなので、
RT-01とRT-02のネイバー状態を確認します
root@RT-01> show bgp neighbor 10.1.2.2
Peer: 10.1.2.2+179 AS 65002 Local: 10.1.2.1+57261 AS 65001
Group: janog55 Routing-Instance: master
Type: External State: Established Flags:
Export: [ advertise_to_RT-02 ] Import: [ receive_from_RT-02 ]
Receive eBGP Origin Validation community: Reject
Peer ID: 10.255.0.2 Local ID: 10.255.0.1 Active Holdtime: 90
Peer supports 4 byte AS extension (peer-as 65002)
Table inet.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 2
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 1
BGPネイバーは確立できていそうですが、
Received prefixes: 2
Accepted prefixes: 0
となっています。
このことからRT-01はRT-02から何らかの経路は受信しているものの破棄しているように見えます。
次にRT-01でRT-02からBGPで受信している経路を確認します
root@RT-01> show route receive-protocol bgp 10.1.2.2 all detail
inet.0: 11 destinations, 11 routes (9 active, 0 holddown, 2 hidden)
0.0.0.0/0 (1 entry, 0 announced)
Nexthop: 10.1.2.2
AS path: 65002 ?
Hidden reason: Rejected by import policy
192.168.1.0/24 (1 entry, 0 announced)
Nexthop: 10.1.2.2
AS path: 65002 ?
Hidden reason: Rejected by import policy
0.0.0.0/0と192.168.1.0/24の経路を受信していますが、Rejected by import policy(経路は受信しているもののimport policyにより経路を破棄) となっています。
import policyにより経路を破棄しているようなので
import policyを確認します。
先程のRT-01のネイバー状態の確認で
Export: [ advertise_to_RT-02 ] Import: [ receive_from_RT-02 ]
と出力されているので
import policyには receive_from_RT-02 が適用されていることが分かります
該当のポリシーを確認すると
root@RT-01> show policy receive_from_RT-02
Policy receive_from_RT-02: [CHANGED/RESOLVED/]
Term reject_origin_incomplete:
from origin Incomplete
then reject
Term accept_routes:
from
route filter:
192.168.1.0/24 exact
then accept
Term reject_all:
then reject
・origin属性がincompleteのものは破棄
・192.168.1.0/24に完全一致する経路のみ許可
・それ以外はすべて破棄
となっています。
このことからRT-02から192.168.1.0/24の経路は広報されているが、
origin属性がincompleteの為、RT-01で経路が破棄されルーティングテーブルに経路がのっていないようです。
問題の制約としてRT-01の設定変更が不可となっているので、
RT-02の方で
・origin属性がincomplete以外
・プレフィックスが192.168.1.0/24に完全一致
を満たす経路として経路を広報するよう修正します。
RT-02でBGPテーブルを確認すると
RT-02#sh ip bgp detail
BGP routing table information for VRF default
Router identifier 10.255.0.2, local AS number 65002
BGP routing table entry for 192.168.1.0/24
Paths: 1 available
Local
10.2.3.3 from – (0.0.0.0)
Origin INCOMPLETE, metric -, localpref -, IGP metric -, weight 0, tag 0
Received 00:52:25 ago, valid, local, best, redistributed (Static)
Rx SAFI: Unicast
192.168.1.0/24はstatic経路を再配布していて、origin属性はincompleteになっています。
再配布する経路はroute-mapを使用し属性を調整することができるので
RT-02でRT-01に広報する経路のorigin属性をincomplete以外に変更するroute-mapを作成し再配布する経路に適用します。
route-map origin_igp permit 10
set origin igp
router bgp 65002
redistribute static route-map origin_igp
修正コンフィグ適用後にRT-02のBGPテーブルを確認すると
RT-02#sh ip bgp det
BGP routing table information for VRF default
Router identifier 10.255.0.2, local AS number 65002
BGP routing table entry for 192.168.1.0/24
Paths: 1 available
Local
10.2.3.3 from – (0.0.0.0)
Origin IGP, metric -, localpref -, IGP metric -, weight 0, tag 0
Received 00:58:43 ago, valid, local, best, redistributed (Static)
Rx SAFI: Unicast
192.168.1.0/24の経路のorigin属性が IGPに変わっていることが分かります。
この状態でRT-01のルーティングテーブルを確認すると
root@RT-01> show route table inet.0
inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)
+ = Active Route, – = Last Active, * = Both
10.1.2.0/24 *[Direct/0] 00:59:09
> via eth2
10.1.2.1/32 *[Local/0] 00:59:09
Local via eth2
10.255.0.1/32 *[Direct/0] 00:59:09
> via lo
10.255.0.2/32 *[Static/5] 00:59:09
> to 10.1.2.2 via eth2
10.255.0.3/32 *[Static/5] 00:59:09
> to 10.1.2.2 via eth2
172.20.20.0/24 *[Direct/0] 00:59:10
> via eth0
172.20.20.4/32 *[Local/0] 00:59:10
Local via eth0
192.168.0.0/24 *[Direct/0] 00:59:09
> via eth1
192.168.0.1/32 *[Local/0] 00:59:09
Local via eth1
192.168.1.0/24 *[BGP/170] 00:00:03, localpref 100
AS path: 65002 I, validation-state: unverified
> to 10.1.2.2 via eth2
無事に192.168.1.0/24の経路が増えました
この状態でSV-10からSV-20への疎通性を確認すると・・・
SV-10:~# traceroute -q1 -n -m5 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 5 hops max, 46 byte packets
1 192.168.0.1 0.005 ms
2 10.1.2.2 0.002 ms
3 10.2.3.3 0.741 ms
4 192.168.1.20 0.717 ms
SV-10:~# ping -c 4 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=1 ttl=61 time=1.09 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=61 time=0.969 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=61 time=1.03 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=61 time=0.950 ms
— 192.168.1.20 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.950/1.010/1.087/0.054 ms
無事にSV-10とSV-20で通信できるようになりました。
感想
本問題ではBGPの属性でNETCONで取り上げられたことがなさそう？なものを使って問題を作ってみました
別解ができるだけ出ないように色々と制限をつけさせてもらったのですが、
BGP得意な方々はささっと解かれていた印象でした。
※解説書いてて思いましたが、0.0.0.0/0はフィルターしておいたほうが良かったですね・・・
本問に挑戦いただいた方々ありがとうございました。
またどこかで作問する機会があれば細部までこだわって作り込みしようと思います。
