AWS 専用線アクセス体験ラボでCisco CSRを触ってみました
はじめに
こんにちは、AWS事業本部の島川です。
11月26日にAWS様主催のAWS 専用線アクセス体験ラボトレーニングに参加してきました。こちらのハンズオンは定期的に行われていて、弊社からも過去何人か参加しています。
ハンズオンの流れ等については既に紹介されていますので、そちらご参照ください。(何個かレポート貼っておきます↓↓↓)
今回はAWS側の作業ではなくオンプレ側の作業としてCisco CSRを初めて触ってみたので、そこで設定した内容を振り返りついでにまとめてみました。
過去の参加レポート
Cisco CSRとは
Cisco Cloud Service Routerの略で、いわゆるソフトウェアルータです。VMwareなどの仮想マシン上に展開されて動作します。
Cisco CSR 1000V シリーズ クラウド サービス ルータ ソフトウェア コンフィギュレーション ガイド Cisco IOS XE Release 3.9S
仮想的に展開することで、物理的な作業が減ったり障害時の対応もスムーズだったりメリット多いと思います!何より今回のハンズオンでは80以上の環境が必要でした。こういった大規模な環境を一度に展開するとなると、仮想ルータは必須だと思います。
今回のブログには登場しませんが、CiscoのCSRの他にJuniperのvSRXも使用していました。こちらも仮想で動くものです。
Cisco CSRの設定
前提としてAWS側の作業を完了している必要があります。
AWS 専用線アクセス体験ラボ ハンズオントレーニングで学んだことをまとめたが参考になります。
設定する流れ
- インターフェースの設定
- BGPピアの設定
- 設定確認
- 疎通確認
今回設定する箇所
オンプレ側のCSRに設定を投入して、AWS側に作成したEC2とオンプレ側のUbuntuが通信できればOKです。
インタフェースの設定
- sshでCSRにログイン
csr#
- 設定モードに移行
csr# configure terminal csr(config)#
- WANのインターフェースを有効にする
csr(config)# interface GigabitEthernet 1 csr(config-if)# no shutdown csr(config-if)# exit csr(config)#
- サブインターフェースを切ってVLAN-IDとIPアドレスを設定。
- VLANIDはAWS側の環境と合わせておく必要があります。
csr(config)# interface GigabitEthernet 1.xx csr(config-subif)# encapsulation dot1Q <vlanid> csr(config-subif)# ip address 169.254.100.6 255.255.255.252 csr(config-subif)# exit csr(config)# exit csr#
BGPピアの設定
- 設定モードに移行
csr# configure terminal csr(config)#
- BGPの設定モードに移行
csr(config)# router bgp 65001 csr(config-router)#
- AWS側のルータのIPとAS番号を設定
csr(config-router)# neighbor 169.254.100.5 remote-as 64512
- BGPパスワードを設定
csr(config-router)# neighbor 169.254.100.5 password hogehoge
- eBGPで広告するルーティング情報を設定(自分のネットワーク環境)
csr(config-router)# network 192.168.10.0 mask 255.255.255.0 csr(config-router)# exit csr(config)# exit csr#
設定確認
- BGPピアの状態を確認
csr#show ip bgp neighbors BGP neighbor is 169.254.100.5, remote AS 64512, internal link BGP version 4, remote router ID 192.168.10.30 BGP state = Established, up for 20:30:17 ...
BGP state = EstablishedとなっていればOKです!
- AWSから受信されているルート情報を取得
csr#show ip bgp neighbors 169.254.100.5 routes BGP table version is 20, local router ID is 192.168.10.30 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 172.16.0.0 169.254.100.5 100 0 64512 i * 172.17.0.0 169.254.100.5 100 0 64512 i Total number of prefixes 2
2つのルート情報をAWSからもらっていることが確認できます。
- AWSに送信しているルート情報を取得
csr#show ip bgp neighbors 169.254.100.5 advertised-routes BGP table version is 20, local router ID is 192.168.10.30 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 192.168.10.0 0.0.0.0 0 32768 i Total number of prefixes 1
AWS側へ伝えているルート情報が確認できます。
疎通確認
この状態でマネジメントコンソールの仮想インターフェースを確認するとdownからavailableになっていることが確認できます。 問題なさそうなので、UbuntuサーバからAWSに立てたEC2にpingを打っていきます。
- ルーティング情報を追加
AWS側はルーティングテーブルがありそこで制御してくれるので、OS側の設定は必要ありませんがオンプレ側ではルーティングの設定が必要です。※セキュリティグループは空けておかないとです!
ubuntu:~$ sudo route add -net 172.16.0.0/16 gw 192.168.10.30 ubuntu:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.251.7.250 0.0.0.0 UG 0 0 0 eth1 10.0.0.0 10.251.7.250 255.255.0.0 UG 0 0 0 eth1 10.251.0.0 0.0.0.0 255.255.248.0 U 0 0 0 eth1 172.16.0.0 192.168.10.30 255.255.0.0 UG 0 0 0 eth0 <---これがあればOK 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
AWS側に立てたEC2のプライベートIPは172.16.0.100なので、そこに向けてpingを打ちます。
ubuntu:~$ ping 172.17.0.100 PING 172.17.0.100 (172.17.0.100) 56(84) bytes of data. 64 bytes from 172.17.0.100: icmp_seq=1 ttl=243 time=75.0 ms 64 bytes from 172.17.0.100: icmp_seq=2 ttl=243 time=72.1 ms 64 bytes from 172.17.0.100: icmp_seq=3 ttl=243 time=70.2 ms 64 bytes from 172.17.0.100: icmp_seq=4 ttl=243 time=73.2 ms 64 bytes from 172.17.0.100: icmp_seq=5 ttl=243 time=71.7 ms 64 bytes from 172.17.0.100: icmp_seq=6 ttl=243 time=70.2 ms ^C --- 172.17.0.100 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5008ms rtt min/avg/max/mdev = 70.270/72.126/75.076/1.682 ms
通りました!
AWS側のEC2からも打ってみます。
[ec2-user@ip-172-16-0-100 ~]$ ping 192.168.10.100 PING 192.168.10.100 (192.168.10.100) 56(84) bytes of data. 64 bytes from 192.168.10.100: icmp_seq=1 ttl=61 time=9.63 ms 64 bytes from 192.168.10.100: icmp_seq=2 ttl=61 time=7.71 ms 64 bytes from 192.168.10.100: icmp_seq=3 ttl=61 time=5.85 ms 64 bytes from 192.168.10.100: icmp_seq=4 ttl=61 time=8.40 ms 64 bytes from 192.168.10.100: icmp_seq=5 ttl=61 time=6.82 ms ^C --- 192.168.10.100 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 5.858/7.687/9.634/1.294 ms
通りました!
最後に
DirectConnectの基礎を抑えたい!という方にはとてもおすすめのハンズオンでした。AWSにおける基本のネットワークの構築もハンズオンの中に含まれているので、AWS⇔オンプレミスのネットワークを一気に学ぶことができました。
社内評判が良くみんな参加するといいよーと言ってくれていた通り本当に参加してよかったです。
余談ですが、このハンズオンの環境はAWS Loft Tokyoの入り口すぐ左のデモ環境で動いてるとのことでした。ただ、全部VMwareで動いているのであまりイメージは沸かないかもしれません笑
また今回のハンズオン設定したルータはCiscoとJuniper製品でしたが、YAMAHA等他のベンダーの製品も取り扱い予定とのことです!ユーザーの声でハンズオンもアップデートされている模様です。