/

問題文

通信事業者である「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と呼ばれる設定をする必要があります。今回は以下の設定がそれぞれの機器に行われていました。

  • C1941
  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
  • 1841-A
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を用いてピアを張る必要があるため、追加で設定を加える必要があります。 実際に追加する必要がある設定は以下になります。

  • C1941
ipv6 route fd00:173::/64 fd00:171::2
neighbor fd00:173::1 update-source loopback 0
neighbor fd00:173::1 ebgp-multihop 2
  • 1841-A
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 2

EBGPピアを張る際の送るメッセージのTTL(Time to Live)はデフォルトで「1」に設定されています。そのため、Loopbackを用いてピアを張る場合、TTLが1より大きくなってしまうためパケットが捨てられてしまいメッセージが宛先に届きません。そのため、この設定によってTTLの数を増やす必要があります。因みに、最後の値の部分を指定しないと、「255」に設定されます。

以上の設定によって、ピアを張ることができます。


さらに、今回の問題では、ピアを張ることが出来たら1841-Aの「Loopback 1」のネットワークをMP-BGPによって共有を行うという指定がありました。それを踏まえてルート共有を行う設定は以下のとおりです。

  • 1841-A
router bgp 2
 address-family ipv6 unicast
 network fd00:174::/64

この設定を行うとMP-BGPでのルート共有が行われます。

回答例

  • C1941
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
  • 1841-A
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

採点基準

  • 各ルータのLoopback 0に向けてIPv6でのstatic routeが設定されている(30%)
  • neighborを張る送信元をそれぞれの Loopback 0に設定した(60%)
  • ebgp-multihopを2以上に設定している(90%)
  • BGPによって受け取ったルート情報でR1からR2のloopback 1に疎通性が取れる(100%)
 /

問題文

あなたの部署では IPv6 のネットワークを使用しており、ルータ以下に fd00:10::/64fd00:11::/64 の2つのサブネットがあり、それぞれのサブネットに端末がある。fd00:10::/64 には端末1が存在し fd00:11::/64 には端末2が存在している。

fd00:11::/64 のサブネットでは今まで静的に IPv6 アドレスを割り当てていたが、自動的な割り当てに切り替えることになった。ところが、切り替え作業時にオペレーションミスが発生してしまい、端末2が IPv6 アドレスを失ってしまったらしく、端末1から端末2へアクセスできなくなってしまった。

この状態から切り替え作業を完了させ、端末2に fd00:11::/64 の IPv6 アドレスを自動的に割り当てて端末1からアクセスできるようにしてほしい。なお端末2のアドレスとしては fd00:11::100 - fd00:11::199 の範囲のみが使用を許可されている。

情報

ルータ

IPアドレス: 192.168.10.1
ユーザー: admin
パスワード: w4HcAsJS

端末1

IPアドレス: fd00:10::2
ユーザー: admin
パスワード: w4HcAsJS

ルータからアクセスすることが可能です。

端末2

ユーザー: admin
パスワード: w4HcAsJS

構成

10_ryo_image.png

トラブルの概要

  • 端末2に静的に割り当てていた IPv6 アドレスが消えている
  • DHCPv6 の設定が入っていない

解説・解答例

まず、問題文を読めば以下の事項が要求されているとわかります。

  1. サーバ2に自動的にIPv6アドレスを割り当てる
  2. 自動的に割り当てるIPV6アドレスは fd00:11::100 - fd00:11::199 でなければならない

IPv4であれば、自動的にアドレスを割り当てる場合にはDHCPを利用します。一方でIPv6アドレスを自動的に割り当てる方法としては以下の二つがあります。

  1. Router Advertisement (RA) を利用したステートレス自動割り当て
  2. DHCPv6 を利用したステートフル自動割り当て

ステートレス自動割り当てではサーバがルータからRAというメッセージを受け取り、RAで配布された情報とサーバのインターフェースのMACアドレスを組み合わせてIPv6アドレスを生成します。そのため、特定の範囲内のアドレスを使わせることが不可能です。したがってDHCPv6を使わなければならないことがわかります。

そこでルータの fd00:11::/64 のインターフェースにDHCPv6の設定を行いましょう。

まずはルータにsshします。

$ ssh admin@192.168.10.1
Welcome to VyOS

sshの際にルータがVyOS であることがわかります。VyOS のコマンドで設定していきましょう。

$ show conf
ethernet eth2 {
address fd00:11::1/64
duplex auto
smp_affinity auto
speed auto
}

コンフィグを見るとeth2fd00:11::/64のインターフェースだとわかります。

$ conf
$ set service dhcpv6-server
$ set service dhcpv6-server shared-network-name eth2 subnet fd00:11::/64 address-range start fd00:11::100 stop fd00:11::199
$ edit interfaces ethernet eth2
$ set ipv6 router-advert send-advert true
$ set ipv6 router-advert managed-flag true
$ set ipv6 router-advert other-config-flag true
$ exit
$ commit; save

address-rangeでIPv6アドレスの範囲を指定します。これは、問題文に指定されている通り fd00:11::100 - fd00:11::199 にしましょう。

またeth2においてRAを有効にします。これは、DHCPv6による割り当てを使う場合でもまずはサーバがルータからRAを受け取る必要があるからです。DHCPv6でIPv6アドレスを配布するにはさらにmanaged-flagを有効にする必要があります。other-config-flagはDHCPv6サーバでネームサーバなどの情報を配布するかどうかのオプションであるため、ここでは有効にしていますが、無効でも良いです。なお VyOS ではother-config-flagに関わらず、デフォルトゲートウェイがRAを配布したインターフェースに設定されるようです。

さて、これでサーバ2にアドレスが割り振られるはずなので見てみましょう。以下のコマンドで割り当てられてい DHCPv6アドレスを確認することができます。

$ show dhcpv6 server leases
There are no DHCPv6 leases.

ところが、予想に反して、割り当てられているIPv6アドレスがありません。ルータとサーバ2の間に何らかのトラブルが発生していることが想定されます。サーバ2にsshしてトラブルシューティングを行いたいところです。しかし「サーバ2が IPv6 アドレスを失ってしまったらしく、サーバ1からサーバ2へアクセスできなくなってしまった」とあるように、サーバ2に割り当てられていた静的なIPv6アドレスは失われてしまっています。

ここで、IPv6のリンクローカルアドレスを使います。IPv6が有効になっている全てのインターフェースには、MACアドレスから自動生成されたリンクローカルアドレスが割り当てられています。これは、その名の通り同じL2にいるインターフェース同士の通信に使用することができます。したがって、ルータからであればサーバ2のリンクローカルアドレスにアクセスすることができます。

サーバ2のリンクローカルアドレスはわからないので探しましょう。そのためには、IPv6のマルチキャストが有効です。IPv6にはリンクローカルなマルチキャストアドレスがあらかじめいくつか定義されており、同じL2に存在する特定の種類のインターフェース全てに通信することができます。ここでは、リンクローカルな全てのノードのアドレスを調べるためにeth2からff02::1に ping します。

$ ping6 -I eth2 ff02::1

これを実行すると1つ以上のインターフェースから応答があるはずです。なお、一度通信したことのあるインターフェースのアドレスは以下のコマンドでも調べられます。RAを有効にした後であれば、上記のpingのマルチキャストを行わなくても複数のインターフェースを見つけられるかもしれません。

$ show ipv6 neigh

ここまででサーバ2のインターフェースの候補がわかるはずなので、あとは地道にsshを試していきます。与えられたユーザとパスワードでログインできるのがサーバ2です。なお、リンクローカルアドレスにsshするときはアドレスの末尾に%eth2を追記して、インターフェースを明示する必要があります。

$ ssh admin@{{link local address}}%eth2
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-45-generic x86_64)

ログインに成功するとUbuntu 18.04であることがわかります。iproute2のコマンドでインターフェースを見ると、アドレスが振られていないのがわかります。

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:5e:e0:21:7e brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:5eff:fee0:217e/64 scope link
valid_lft forever preferred_lft forever

Ubuntu 18.04ではネットワークインターフェースの管理にNetplanというソフトウェアを使っています。設定ファイルは/etc/netplan/以下にあります。今回は/etc/netplan/99-network-config.yamlが存在し、以下のように書かれています。

network:
version: 2
ethernets:
eth0:
dhcp4: false
accept-ra: false
gateway6: fd00:11::1

ここからRAが無効になっているとわかります。これではDHCPv6によるアドレス割り当てを行うことができません。そこで、RAとDHCPv6を有効にします。また、ゲートウェイはRAによって設定されるので、静的な設定は消してしまいます。

network:
version: 2
ethernets:
eth0:
dhcp4: false
dhcp6: true
accept-ra: true

書き換えて保存したら、以下のコマンドで設定を反映させます。

$ sudo netplan apply

すると今度はDHCPv6によって割り当てられたアドレスが確認できるはずです。

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:5e:e0:21:7e brd ff:ff:ff:ff:ff:ff
inet6 fd00:11::199/128 scope global dynamic noprefixroute
valid_lft 43196sec preferred_lft 26996sec
inet6 fe80::5054:5eff:fee0:217e/64 scope link
valid_lft forever preferred_lft forever

問題が解決したかどうか確かめるために、サーバ1からこのアドレスにpingしてみましょう。

$ ssh admin@fd00:10::2
$ ping fd00:11::199
PING fd00:11::199(fd00:11::199) 56 data bytes
64 bytes from fd00:11::199: icmp_seq=1 ttl=63 time=1.38 ms
64 bytes from fd00:11::199: icmp_seq=2 ttl=63 time=1.17 ms

成功していれば、問題解決です。当初の目的通りに、サーバ2に特定の範囲のIPv6アドレスを自動的に割り当てることができました。

採点基準

想定解法の場合

  • サーバでRAを設定している: 60点
  • サーバでDHCPv6を設定している: 70点
  • 端末2にリンクローカルアドレスで接続している: 70点
  • クライアントを正しく設定している: 40点

その他の解法の場合

  • IPv6アドレスが正しく割り当てられている: 140点
  • 端末1から端末2へpingが通る: 100点

参考

この問題を解く、あるいは解説を理解するにあたって参考となるウェブページを上げておきます。

  • RAとDHCPv6について: https://www.infraexpert.com/study/ipv6z5.html
  • IPv6ユニキャストアドレスについて: https://www.infraexpert.com/study/ipv6z3.html
  • IPv6マルチキャストアドレスについて: https://www.infraexpert.com/study/ipv6z10.html
 /

問題文

あなたが所属している会社では、社内専用のWebサイトを別のサーバにリプレイスしました。Webサイトの移行はトラブルなく完了しましたが、後輩が担当していたネットワーク部分が上手く動作せず、社内ネットワークからWebサイトへアクセスできません。自分では手に追えなくなった後輩があなたに泣きついてきました。

「Webサイトには 『 http://192.168.15.125 』 でアクセスするんですが、社内ネットワークからアクセスすることが出来なくて……。多分、ルータのNAT周りの設定がおかしいと思うんですがどこを直したらいいんでしょうか……? 先輩助けてください!」

トラブルの原因を突き止めて、サイトが正常に閲覧できるようにしてください。

情報

  • 使用する手元機材 : AR2050V
  • ユーザー : admin
  • パスワード : IWgrk2Dz
  • 社内ネットワーク
  • IPアドレス:DHCPで配布
  • AR2050VのLANポートに接続すると社内ネットワークに入れる
  • Webサーバ
  • 社内ネットワークからWebサーバへアクセスするためのIPアドレス:192.168.15.125
  • なおWebサーバの本来のホストは192.168.15.125ではなく、192.168.15.32である。
  • Webサーバを操作することはできない

問題に関する禁止事項

  • NATルールを変更しない
  • 物理配線を変更しない
  • IPアドレスを変更しない
  • DHCPを変更しない

報告書を書く際の必須事項

  • 追記・修正するためのコンフィグ
  • 『 http://192.168.15.125 』にアクセスした結果

トラブルの概要

双方向NATをするための以下の要素が正しく設定されていないため、参加者PCからWebサーバへアクセスできません。

  • proxy arp の設定が漏れている
  • zone localの内容が間違っている
  • zone globalの内容が間違っている

解説

Webサーバへアクセスできないのは、双方向NATするための条件が揃っていないことが原因です。

双方向NATとは、1台のNATデバイスで「内部の送信元アドレス変換」と「外部の送信元アドレス変換」を同時に行うNATのことです。双方向にアドレスが変換されることから、内部ホストと外部ホストの双方ともお互いのIPアドレスを知ることなく通信することが可能になります。

双方向NATの条件がそろっていないことが原因ということですが、NATの設定から順を追ってみていこうと思います。

NATの確認

まずはNATの設定を確認しましょう。

今回のNAT設定は以下のようになっていました。

nat
rule 10 masq any from private to global with src global.wan.client
rule 20 portfwd any from private to local.lan.server with dst public.wan.server

今回は、スタティックNATで双方向NATを実現しています。

1行ずつ見ていきましょう。

「内⇒外」方向のスタティックNAT

rule 10 masq any from private to global with src global.wan.client

上記の設定は、

  • rule コマンドで masq アクションを指定されているため、「内⇒外」方向へのスタティックNATである。
  • すべてのアプリケーションの送信元エンティティー「from private」で宛先エンティティー「to global」のとき、送信元IPアドレスを「with src global.wan.client」に変換する。

を表します。

次に、このNATに関するエンティティーの内容を確認します。

zone private
network lan
ip subnet 192.168.15.64/26
host client
ip address 192.168.15.70
ip address 192.168.15.71
ip address 192.168.15.72
ip address 192.168.15.73
ip address 192.168.15.74
ip address 192.168.15.75
ip address 192.168.15.76
ip address 192.168.15.77
ip address 192.168.15.78
ip address 192.168.15.79
ip address 192.168.15.80
!
zone global
network wan
ip subnet 192.168.15.0/24
host client
ip address 192.168.15.125

送信元エンティティーである「private」は、ルータのLANポートに接続したときに降ってくるDHCPが指定されています。

宛先エンティティーである「global」は、NATの設定通りであるとすると、送信元IPアドレスを変換するための条件(ネットワーク定義にWebサーバが属するネットワークアドレス、ホスト定義に特定のipアドレス)が設定されているはずですが、でたらめな条件になっていることが分かります。

よって、このゾーン定義の内容を修正する必要があります。

no zone global
zone global
network wan
ip subnet 192.168.15.0/26
host client
ip address 192.168.15.33

送信元ipアドレスを変換するための「with src global.wan.client」は、show runnning-configを確認すると ip route 192.168.15.33/32 eth1 が設定されているので、192.168.15.33 を指定すると良さそうです。

「外⇒内」方向のスタティックNAT

rule 20 portfwd any from private to local.lan.server with dst public.wan.server

上記の設定は、

  • ruleコマンドで portfwd アクションを指定されているため、「外⇒内」方向へのスタティックNATである。
  • すべてのアプリケーションの送信元エンティティー「from private」で宛先エンティティー「to local.lan.server」のとき、宛先IPアドレスを「with dst public.wan.server」に変換する。

を表します。

次に、このNATに関するエンティティーの内容を確認します。

zone local
network lan
ip subnet 192.168.15.0/24
host server
ip address 192.168.15.33
!
zone private
network lan
ip subnet 192.168.15.64/26
host client
ip address 192.168.15.70
ip address 192.168.15.71
ip address 192.168.15.72
ip address 192.168.15.73
ip address 192.168.15.74
ip address 192.168.15.75
ip address 192.168.15.76
ip address 192.168.15.77
ip address 192.168.15.78
ip address 192.168.15.79
ip address 192.168.15.80
!
zone public
network wan
ip subnet 192.168.15.0/26
host server
ip address 192.168.15.32
!

送信元エンティティーである「private」は、1行目のNATのときと同じなので割愛します。

宛先エンティティーである「local.lan.server」は、問題文に書かれていた、社内ネットワークからWebサーバにアクセスするときのIPアドレス192.168.15.125 が当てはまるはずですが、1行目のNATと同様に、ネットワーク定義もホスト定義もでたらめになっています。

よってこのゾーン定義を修正する必要があります。

no zone local
zone local
network lan
ip subnet 192.168.15.64/26
host server
ip address 192.168.15.125

宛先ipアドレスを変換するための「with dst public.wan.server」は、Webサーバの本来のipアドレスが指定されているので、修正する必要はありません。

代理応答機能を追加する

Firewallはすべてのエンティティー間を許可しているので問題ないため、NAT周りはすべて修正出来ました。

双方向NATでは、ルータ本体に設定されていないIPアドレスを使用しています。

よって、そのIPアドレスに対してルータが代理応答する必要があります。

特定のIPアドレス範囲を代理応答させるためには local-proxy-arp コマンドを用いて設定する必要があります。

しかし、show runnning-configを確認した限り、設定されていないようなので、追加設定をしなければなりません。

local-proxy-arp 192.168.15.125/32
local-proxy-arp 192.168.15.33/32

上記の設定を有効にするためには、該当するインターフェースに対してリミテッドローカルプロキシーARPを有効にする必要がありますが、インターフェースvlan43とインターフェースeth1どちらとも有効になっているので、設定する必要はありません。

回答例

!
local-proxy-arp 192.168.15.125/32
local-proxy-arp 192.168.15.33/32
!
no zone global
zone global
network wan
ip subnet 192.168.15.0/26
host client
ip address 192.168.15.33
!
no zone local
zone local
network lan
ip subnet 192.168.15.64/26
host server
ip address 192.168.15.125
!

採点基準

  • proxy arp の設定が正しく追加されている(30%)(計30%)
  • zone global の設定が正しく修正されている(15%)(計45%)
  • zone local の設定が正しく修正されている(15%)(計60%)
  • client から 192.168.15.125 にブラウザからアクセスするとWebページが閲覧できる(40%)(計100%)

 

 /

問題文

日本拠点とベネチア拠点間にGREトンネルを開通する。
しかし、うまく疎通性の確認が取れない。
あなたは今から日本拠点のトンネル構築をするルータである 892J-A の設定を調査して解決し、何が原因だったのか報告してほしい。

情報

  • 892J-A

ポート: FastEtheret0〜7
ユーザー: admin
パスワード: 1Fa3Iiik

892J-Aのみ操作を行う

問題のゴール状態

PCから192.168.4.255 への疎通性がある

提出すべきもの

  • 設定したコンフィグ
  • 参加者PCから 192.168.4.255 までのトレースルートの結果

構成

禁止行為

  • 物理配線・論理構成(IPアドレス・VRFなど)の変更

トラブルの概要

  • tunnel vrf コマンドを入れていない為、GREトンネルがアップしない
  • +VRF tunnel にスタティックルートを書いてない為、192.168.4.255にPingが飛ばない

解説

今回のトラブルは、この中のGREトンネルのインターフェース(892J-Aのtunnel80)がLinkUpせず、PCから 192.168.4.255 へ疎通できないものでした。

まず、CiscoのGREトンネルの挙動についてのおさらいですが、GREトンネルはそれ自体のIPアドレスとは別にカプセル化したパケットの宛先IPと送信元IPもしくは送信元インターフェースを指定する必要があります。トンネルのインターフェースがLinkUpする条件は、この宛先IPアドレスへの経路がルーティングテーブルにインストールされているかどうかとなります。

これはVRF-Liteと呼ばれるルーティングテーブルを仮想的に分割する技術を使用していても使用することは可能ですが、その場合はカプセル化したパケットの宛先IPアドレスがどのルーティングテーブルに従って送信するかを明示的に指定する必要があります。今回の場合カプセル化したパケットはVRF global に従うように設定する必要があります。

その部分の解答コンフィグを以下に示します。

interface tunnel80
tunnel vrf global
exit

また、トンネルインターフェースとPCを接続するインターフェースが所属するVRF tunnel に、192.168.4.255 への経路が書かれていなかったため、それを手動で追加する必要があります。

その部分の解答コンフィグを以下に示します。

ip route vrf tunnel 192.168.4.255 255.255.255.255 192.168.4.201

以上のコマンドを入力することで、PCから192.168.4.255まで疎通することができるようになります。その時のtracerouteの結果は以下のようになります。

192.168.4.255 へのルートをトレースしています。経由するホップ数は最大 30 です

1 <1 ms <1 ms <1 ms 192.168.4.1
2 <1 ms <1 ms <1 ms 192.168.4.255

トレースを完了しました。

ここまでのコマンドとtracerouteの結果を示すことで、この問題は完答となります。またコマンドはこの通りでなくても同じことができるものであれば得点としています。

回答例

int tunnel 80
tunnel vrf global
exit
ip route vrf tunnel 192.168.4.255 255.255.255.255 192.168.4.201

採点基準

  • tunnel vrf コマンドを正しく入力している。:60%
  • スタティックルートまで正しく入力し、想定通りのtraceroute結果を示している。:満点
 /

問題文

監視サーバを建ててルータの先にある892JをSNMPで監視しようとしたら上手く監視ができない。
監視サーバからSNMPのMiBを取得できるようにしてくれ。

情報

監視サーバのアドレス

http://192.168.2.129:8080
– ユーザー Admin
– パスワード: zabbix

1841-B

ユーザー: admin
パスワード: iK8Cjr3B

892J-A

監視対象IP: 192.168.2.100

問題のゴール状態

ZabbixのUI上でSNMPの監視が行えることを確認する

トラブルの概要

この問題は1841-Bの192.168.2.1のIPアドレスが設定されているインタフェースにSNMPで使用されているポートがaccess-listによって遮断されているトラブルです。

解答例

ACLが設定されているインターフェースには以下のルールが書かれていました。
1841-B(抜粋)

interface FastEthernet0
ip address 192.168.2.1 255.255.255.192
ip access-group 100 in
access-list 100 permit tcp any eq 22 any
access-list 100 permit tcp any eq telnet any
access-list 100 deny udp any eq snmp any
access-list 100 deny udp any eq snmptrap any

Cisco機器のAccess control(ACL)は全ての条件にマッチしなかった場合にパケットを破棄するルール(暗黙のDeny)があるので、access-list 100 denyは書かなくてもDenyになります。
しかし、今回の問題ではあえてトラブルに気づかせる目的で明示的に書いてあります。
ゴールになる解答例はいくつかあります。

  • インタフェースに設定されているACLの設定を消す
interface FastEthernet0
no ip access-group 100 in
  • ACLの設定を「全ての通信を許可」にする
no access-list 100
access-list 100 permit any
  • 現在のACLに加えてSNMPで使うポートを許可する
no access-list 100
access-list 100 permit tcp any eq 22 any
access-list 100 permit tcp any eq telnet any
access-list 100 permit udp any eq snmp any
access-list 100 permit udp any eq snmptrap any

今回は特に制約がなく、Zabbixから監視ができればゴールとしていたためどの方法でも正解としています。

講評

この問題は1次予選・2次予選に引き続いて出した問題です。
既に学ばれている分野もあり正答率は高かったです。

 /

問題文

あなたはとある会社のNOCに所属しています。
ある日、どこぞのセミナーから帰ってきた無能な上司に「知ってる? IPv4アドレスって数が少なくて枯渇してるんだよ? これからはIPv6の時代! 社内LANではIPv4禁止ね。 明日までによろしく!」と言い渡された。

さて、やれと言われたらやらなくてはならない。
しかし、クライアントがIPv6アドレスしか持たなくなると、IPv4アドレスしか持ってないWebサイトにアクセスできなくなってしまう。
どうやら、NAT64/DNS64という技術を使うといいらしい。

NAT64/DNS64を検証せよ。

情報

C

IPアドレス: 192.168.3.1
ユーザー: admin
パスワード: admin

R1

IPv6アドレス: fd00:31::71
ユーザー: admin
パスワード: admin
備考: Clientを踏み台にする必要あり

問題のスタート状態

  • C,R1にsshできる
  • R1からS1,S2それぞれにIPでpingが通る
  • Cはeth0にIPv4アドレスとeth1にIPv6アドレスを持っている(R1から配布)
  • R1にはunboundとjoolを導入済み

問題のゴール状態

R1でNAT64,DNS64の設定をして、CからS1,S2にドメインでアクセスできる
R1のDNS64はR2のDNSを参照する

curl server1.local
curl server2.local

構成

トラブル概要

この問題は要約すると「NAT64/DNS64を構築してIPv6クライアントからIPv4サーバーにドメインでアクセスせよ」となります。
構築と言いましたが、問題の開始時点でR1にJool(NAT64用)とunbound(DNS64)の導入とルーティングが済ませてあるので、実際にはR1にJoolとunboundのコンフィグを書くだけというシンプルな構成になっています。

解説

NAT64/DNS64とはIPv6移行技術の1つで、今回の環境のような「クライアントにはIPv6アドレスのみ割り振られているがIPv4アドレスのみで動作しているサービスにアクセスしたい」という場合に利用されます。
以下の図がNAT64/DNS64の概要です。
DNS64はAレコード(IPv4)にプレフィックスを付けてAAAAレコード(IPv6)に変換します。
NAT64はDNS64でプレフィックスを付加されてIPv6になったアドレスを元のIPv4アドレスに変換してアクセスします。

回答例

unboundでのDNS64の設定

6行目でdns64のプレフィックスを設定し、13行目で上流のDNSにR2を指定しています。

server:
  verbosity: 2
  pidfile: "/var/run/unbound.pid"
  use-syslog: yes
  module-config: "dns64 iterator"
  dns64-prefix: 64:ff9b::/96
  dns64-synthall: no
  interface: ::0
  access-control: ::0/0 allow

forward-zone:
  name: "."
  forward-addr: 192.168.3.131

JoolでのNAT64の設定

sudo modprobe jool
sudo jool instance add default --netfilter -6 64:ff9b::/96

採点基準

以下を基準として採点を行いました。

  • NAT64/DNS64の設定が正しく行われている
  • R1のunboundがR2に問い合わせに行くようになっている

まとめ

この問題を解くポイントはNAT64/DNS64の概要を把握することとJoolの公式ドキュメントを読むことです。私も作問時にJoolの使い方を調べましたが、記事の多くは内容が古く最新のJoolでは動作しない設定が載っていまいた。提出された回答の中にはそういった古い情報に惑わされたであろうものがいくつか有りました。
結果は満点が5チームと部分点が1チームで、1/3のチームが満点を取得していました。

余談ですが、懇親会で参加者の方々から「IPv6が嫌いになった」という悲しい声が聞こえましたが、私も作問時にIPv6のDNS周りのバグを踏みまくり少し嫌いになりました。

IPv6流行るといいですね?

 /

問題文

あなたが勤めている株式会社ティーユーでは、組織体制の変更により業者にネットワーク変更を依頼しました。翌日、出勤すると何やら慌ただしい様子です。

話を聞いてみると、経理部の社内PCからインターネットに接続することが出来ないようです。急遽、経理部の社内PCを確認したところ、IPアドレスが割り振られていないようでした。また経理部と同じスイッチングハブに接続されている総務部の社内PCには、経理部に割り振るはずのIPアドレスが割り振られていました。

スイッチングハブ(2960-B)か、その先のルータ(892J-B)のどちらかに設定を行い、経理部及び総務部の社内PCに割り振る予定のIPアドレスが配られるようにしてください。各部署に割り振る予定のアドレスは以下の通りです。

トラブルの概要

スイッチングハブとルータのNative vlanの設定の不一致によって各VLANに割り当てたいアドレスを正しくDHCPで割り振ることができない。

解説

この問題は、「Native Vlan の mismatch」が原因で起こる問題でした。

本問題では、経理部と総務部でVlanを分けて「892J-B」と「2960-B」にそれぞれVlan及びNative Vlanの設定を行いました。 実際に設定されていたコンフィグは以下の通りです。

  • 892J-B
interface fa8.68
  encapsulation dot1q 68 native
  • 2960-B
interface gi0/1
 switchport trunk native vlan 69

上記のコンフィグを見ると、Native VlanのVlan idが一致していません。 892J-Bは「68」としていますが、2960-Bは、「69」となっています。 このとき、892J-BではVlan68のパケットを、2960-Bに向けてタグなしで送ります。

タグなしのパケットを受け取った2960-Bは、そのパケットを自身のNative VlanであるVlan 69のパケットであると判断します。

結果、本来意図していないVlanへパケットが送られてしまいます。

この状態で、892J-BはDHCPによって各部署にIPアドレスを割り振るように設定されていました。

本来であれば、各部署に合わせたネットワークのIPアドレスが割り振れるはずですが、先程のようにVlan 68のパケットは、Vlan 69に送られてしまいます。

そのため、総務部には経理部のネットワークのIPアドレスが割り振られ、経理部へはIPアドレスが割り振られない状況となっていました。

この問題は、「Native Vlanの mismatch」が原因であるため一致させることで解決します。 よって、892J-Bもしくは2960-BのNative Vlanの ID を片方に合わせる必要があります。

Native Vlan の IDを一致させると、各部署に向けて正常にIPアドレスが割り振らます。

因みにこの問題は「Native Vlan」の設定を両方の機器から外すことでも解決することが可能です。

回答例

  • 892J-Bの設定を変更する場合
interface fa8.68
  no encapsulation dot1q 68
  encapsulation dot1q 68
  ip address 192.168.23.1 255.255.255.128
  exit
interface fa8.69
  no encapsulation dot1q 69
  encapsulation dot1q 69 native
  ip address 192.168.23.129 255.255.255.128

  • 2960-Bの設定を変更する場合
interface gi0/1
  no switchport trunk native vlan 69
  switchport trunk native vlan 68

  • 各機器の設定を削除する場合

892J-B

interface fa8.68
  no encapsulation dot1q 68
  encapsulation dot1q 68
  ip address 192.168.23.1 255.255.255.128

2960-B

interface gi0/1
  no switchport trunk native vlan 69

採点基準

    • Native vlanの値の不一致に気付く(50%)
  • DHCPでそれぞれ正しく各部署にアドレスが割り振られている (100%)
 /

問題文

上記のトポロジー図の通りに配線してある機材に設定を投入しましたが、Router-Bから対外への疎通が取れません。
そのため、Router-Bから対外疎通がとれるようにしたいと考えています。
Router-AにGigabitEthernet1側が外部ネットワーク、
GigabitEthernet2側が内部ネットワークとなるようにNATの設定を書き加え、
Router-Bからインターネット(例えばIPアドレス8.8.8.8)へpingを飛ばせるようにしてください。
pingを飛ばす際、経路はRouter-Aを経由します。
Router-AでIPアドレスの設定変更をする必要はありません。

解答メールを送る際は、
・参加者が設定したコンフィグ
・Router-Bからのpingコマンド実行結果
を添えて下さい。

ゴール

Router-AにNATの設定を書き加え、Router-BからRouter-Aを経由してインターネットにpingを飛ばせるようにする。

トラブルの概要

Router-Bから、Router-Aを経由して対外接続がはかれない。

解説

今回はCiscoのルータにNATの設定を書き加えてもらう問題でした。
Router-Bは、Router-AにNATの設定を施すことによって対外疎通が可能になります。
こちらの解説では、当初想定していた回答とよく見られた別解を説明します。

まず、当初想定していたNAPT(PAT)の説明をします。
NAPTの設定をする際はまずNAPT変換対象とする送信元IPアドレスをAccess-listで定義する必要があります。
access-list 1 permit any
例えば上記のように設定すると、全ての送信元IPアドレスを許可します。
続いて先程定義したAccess-listと外部インターフェースを関連付けさせます。
ip nat inside source list 1 interface GigabitEthernet1 overload
最後にどのインターフェースを「内部ネットワーク」または「外部ネットワーク」に指定するのか定義します。
ip nat outside
ip nat inside

続いてよく見られた別解であるスタティックNATを説明します。
NAT変換する 「 内部ローカルアドレス 」 と 「 内部グローバルアドレス 」を定義します。
ip nat inside source static 10.0.0.100 192.168.0.100
上記では最も多かった192.168.0.100を内部グローバルアドレスとして定義しています。
最後にどのインターフェースを「内部ネットワーク」または「外部ネットワーク」に指定するのか定義します。
ip nat outside
ip nat inside

なお、Poolを用いたNATやNAPTで設定していても正答となります。

解答例

NAPT(PAT)の場合

!Router-A
!
enable
!
configure terminal
!
!
access-list 1 permit any
ip nat inside source list 1 interface GigabitEthernet1 overload
!
!
interface GigabitEthernet1
ip nat outside
!
exit
!
interface GigabitEthernet2
ip nat inside
!

 

[別解]スタティックNATの場合

!Router-A
!
enable
!
configure terminal
!
!
ip nat inside source static 10.0.0.100 192.168.0.100
!
!
interface GigabitEthernet1
ip nat outside
!
exit
!
interface GigabitEthernet2
ip nat inside
!

採点基準

  • グローバルコンフィグレーションモードでNATの設定をしている(30%)
  • 内部ネットワーク,外部ネットワークの指定を各インターフェースに適切に設定している(30%)
  • 8.8.8.8等グローバルIPアドレスにpingが通る(40%)

講評

こちらはトラブルを解決するのではなく、参加者に一部だけ構築してもらう問題でした。そのためか回答結果がチームによってさまざまでとても面白かったです。回答を提出してくださったチームのうち、正答であるチームは多かったです。

 /

問題文

Router1とRouter2は最近、EBGPピアを張ることを決定しました。Router1に設定を行い、Router2とEBGPピアを張ってください。EBGPピアを張ることができたかどうかは、「show ip bgp summary」で確認できます。
なお、以下の注意事項に沿って設定してください。
・ 設定できるルータはRouter1のみです。
・ Router1のAS番号は「1」で設定してください。
・ Router1のebgp neighborを張る宛先はRouter2のLoopbackを指定してください。

情報

この問題のトポロジー図は以下になります。

「sh ip bgp summary」の結果の一番下の行の右端が「0」になっていれば、ピアを張ることができています。

実行例を以下に記載します。この結果では下の行の右端が「0」になっています。

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 6 8 1 0 0 00:03:39 0

スタート

Router1とRouter2間のEBGPピアの設定を行なっていない状態。

ゴール

Router1とRouter2間でEBGPピアが張ることが出来ている。

トラブルの概要

neighborやremote-asの設定だけでLoopback間のEBGPピアを張ることができない。

解説

Router1からRouter2にEBGPピアを張るには、BGP Neighborの設定が必要です。
今回の問題ではCisco機材を使用しているため、Cisco用のコマンドによる設定になります。
具体的には以下のような設定が必要になります。

enable
configure terminal
router bgp 1
neighbor 2.2.2.2 remote-as 2

ですが、これだけではEBGPピアを確立させることはできません。
本来、EBGPピアは、実際に接続されているインターフェース間で行われることが一般的で、
追加の設定をしない限りは、それを前提にピアを張ろうとします。

しかし、今回の問題では、Loopbackインターフェース同士でピアを張る必要があるため、
追加の設定が必要になります。具体的な設定は以下になります。

ip route 2.2.2.2 255.255.255.255 192.168.1.2
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop

3つの設定をBGPの設定に加えることで、Loopbackインターフェース間でEBGPピアを張ることができるようになります。

上から、説明していきます。

ip route 2.2.2.2 255.255.255.255 192.168.1.2

これは、Router1がRouter2のLoopbackのアドレスを知らないから疎通性がないことを解消するための設定です。ピアを張る際は、そのインターフェースと疎通性が取れないと張ることができないからです。

neighbor 2.2.2.2 update-source loopback 0

BGPメッセージを送る際の送信元をRouter1 のLoopback 0に指定します。デフォルトでは、送信元はRouter1の物理インターフェースに指定されているため、送信元を変える必要があります。

neighbor 2.2.2.2 ebgp-multihop

EBGPでピアを張る際のBGPのメッセージのTTL(Time to live)の数を増やすために設定します。
EBGPピアを張る際のBGPメッセージのTTLはデフォルトで「1」に設定されているため、Loopbackインターフェース間だとTTLが足りなくパケットロスが起きてしまいます。なお、「ebgp-multihop」の後に引数を指定しないと「255」になります。

以上の設定を踏まえて、最終的な解答コンフィグを以下に記載します。

解答例

!Router-A
!
enable
!
configure terminal
!
ip route 2.2.2.2 255.255.255.255 192.168.1.2
!
router bgp 1
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop
!

採点基準

  • Router2のASに向けて、neighborやremote-asのコマンドが正しく設定できている(10%)
  • Router2のLoopbackに向けて静的ルートを追加されている(30%)
  • update-sourceコマンドでLoopbackを指定することでアドレスが一致している(30%)
  • ebgp-multihopコマンドでTTLの値を「1」より大きな値に変更できている(30%)

講評

この問題はBGPでルーティングを行う際に、最初に行うEBGPピアを張ってもらう問題でした。
Loopbackインターフェースを用いることを前提に設定を組んでいたチームが半分を超えていて、出題してよかったと思います。
EBPGピアを張る際に、Loopbackを用いることもできることを知っていただけたら幸いです。

 /

問題文

toporogy.png
この問題の世界では172.20.0.0/16はインターネットで使われるアドレスで、ISPから割り当てられるものとする。192.168.0.0/16はプライベートIPアドレスである。
ある企業に東京本部と大阪支部があり、大阪支部はISPから172.20.1.1、東京本部には172.20.2.1がそれぞれISPから割り当てられている。またどちらもそれぞれルータ osaka , tokyo でNAPTして使用している。

事前準備

VNCサーバにSSHしたら、そこからPCfumidaiにSSHしてください。アクセス情報は以下の通り。
・IPアドレス:192.168.0.10
・ユーザー名:admin
・パスワード:password

このPCfumidaiはルータosaka配下に設置されたPCで、もう一つのIPアドレス192.168.10.1が割り当てられている。
まず疎通確認として、CloudflareのPublicDNS1.1.1.1にtracerouteして下さい。大体以下のようになればOK。

[admin@fumidai:~]%traceroute 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 gateway (192.168.10.254) 1.220 ms 1.138 ms 1.110 ms
2 172.20.1.254 (172.20.1.254) 1.299 ms 1.290 ms 1.298 ms
以下省略

STEP1. GREトンネル開通

現時点では、大阪支部と東京本部では別々にNATしているため、大阪支部から東京にあるサーバにアクセスすることはできない。
これを解決するため、各ルータで拠点間VPNを張る必要がある。(上図紫の部分)
今回は、拠点間VPNの一つであるGRE TunnelをルータosakaにSSHして設定してください。(ルータtokyoの設定は不要)

アクセス情報、および設定要件は以下の通り。
・IPアドレス:192.168.10.254
・ユーザー名:gre
・パスワード:tunnel
・enableパスワード:tunnel

要件
・プロトコル:GRE
・IPアドレス:192.168.100.1/24
・tunnel送信元アドレス:172.20.1.1
・tunnel宛先アドレス:172.20.2.1
・MTU:1400byte

STEP2. default route切替

GRE Tunnelの設定ができましたら、次は、大阪支部から外部へのパケットがすべて東京本部を経由するようにルータosakaに設定してください。

回答項目

以下の内容を回答してください。
・ STEP1で入力したコンフィグ
・ PCfumidaiから東京本部のサーバ192.168.20.1へのtracerouteの結果のコピペ
・ STEP2で入力したコンフィグ
・ 1.1.1.1へtracerouteした結果のコピペ
show running-configのコピペ

ゴール

ゴール (STEP1)

拠点間VPNの一つであるGRE Tunnelをルーターosaka側に設定する

ゴール (STEP2)

大阪支部から外部へのパケットがすべて東京本部を経由するようにルーターosakaに設定する

トラブルの概要

GREトンネルの構築とデフォルトルートの切り替え

解説

GRE(Generic Routing Encapsulation)は、トンネルプロトコルの1つです。トンネルプロトコルにはLayer2トンネリングのL2F、PPTP、L2TPと、Layer3トンネリングのGRE、IPsecなどがあります。このトンネリングとは、あるトラフィックを別のプロトコルでカプセル化して伝送する技術のことです。パケットのカプセル化とその解除はトンネルの両端の機器で行うため、両端の機器が直結しているように見えます。GREトンネリングでは、任意のプロトコルのパケットをIPトンネル内でカプセル化しています。GREトンネリングを行なう両端のルータで、あるトラフィックに対するカプセル化とその解除を行います。
(ネットワークエンジニアとして(https://www.infraexpert.com/study/rp8gre.htm)より)

今回はCiscoのルータでGREトンネルを一から張ってもらい、デフォルトルートを切り替える問題でした。
STEP1はトンネルインターフェースのIPアドレス、GREトンネルの送信元・送信先アドレス、プロトコルとMTUを要件に従って設定するだけで完了します。
STEP2はデフォルトルートの切り替えですが、それだけではGREトンネルでカプセル化されたパケットの経路情報がなくなるため、そのためのスタティックルートを別途設定する必要があります。

解答例

STEP1.

interface Tunnel0
ip address 192.168.100.1 255.255.255.0
tunnel source 172.20.1.1
tunnel destination 172.20.2.1
ip mtu 1400
tunnel mode gre ip
[admin@fumidai:~]%traceroute 192.168.20.1
traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 60 byte packets
 1  gateway (192.168.10.254)  1.766 ms  1.706 ms  1.706 ms
 2  192.168.100.2 (192.168.100.2)  2.638 ms  2.633 ms  2.640 ms
 3  192.168.20.1 (192.168.20.1)  2.875 ms  2.845 ms  2.793 ms
[admin@fumidai:~]%

STEP2.

no ip route 0.0.0.0 0.0.0.0 172.20.1.254
ip route 0.0.0.0 0.0.0.0 192.168.100.2
ip route 172.20.2.1 255.255.255.255 172.20.1.254
[admin@fumidai:~]%traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  gateway (192.168.10.254)  0.753 ms  0.722 ms  0.704 ms
 2  192.168.100.2 (192.168.100.2)  0.891 ms  0.875 ms  0.817 ms
 3  172.20.2.254 (172.20.2.254)  1.389 ms  1.365 ms  1.338 ms
以下省略

送られてきた解答の中にこれかこれに準ずる内容が含まれていたら得点としています。

講評

今回は1次予選ということで、競技ではあるもののどちらかというとハンズオンセミナーのようなイベントで出されそうな問題を意識して作りました。
その中でSTEP1はそこそこのレベル、STEP2は発展レベルの問題という感覚だったのですが、STEP1まで解けたチームがおよそ6割、STEP2まで完答したチームがおよそ3割程度だったので、思ったよりも解けていた印象でした。
今回はすべてIPv4を用いての問題でしたが、このようなトンネリング技術はIPv6移行技術としてもよく用いられる技術であるためこの機会にぜひ勉強してみてください。