pingを受信できているのにリプライが届かない!(解決済)
設定(全ルータのrunning-config)
背景
マルチホーム環境でのSite-of-originについて検証したく、CE-PE間をBGPで接続するMPLSを組んでいた。
概要
pingが通らない。なのにルーティングテーブルに経路は載っているし、なんなら双方向でICMPを受信できていて、リプライを送信している。
互いにリプライできてるならそれはもう疎通できているってことでは……?
iosv-6#sh ip ro | b Gate
Gateway of last resort is not set
4.0.0.0/32 is subnetted, 1 subnets
B 4.4.4.4 [20/0] via 192.168.60.10, 00:27:56
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/0] via 192.168.60.10, 00:21:13
6.0.0.0/32 is subnetted, 1 subnets
C 6.6.6.6 is directly connected, Loopback0
192.168.60.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.60.0/24 is directly connected, GigabitEthernet0/0
L 192.168.60.6/32 is directly connected, GigabitEthernet0/0
iosv-6#
iosv-6#debug ip icmp
ICMP packet debugging is on
iosv-6#
*Aug 7 14:44:14.511: ICMP: echo reply sent, src 6.6.6.6, dst 192.168.24.4, topology BASE, dscp 0 topoid 0
iosv-6#
*Aug 7 14:44:16.499: ICMP: echo reply sent, src 6.6.6.6, dst 192.168.24.4, topology BASE, dscp 0 topoid 0
iosv-6#
*Aug 7 14:44:18.490: ICMP: echo reply sent, src 6.6.6.6, dst 192.168.24.4, topology BASE, dscp 0 topoid 0
iosv-6#
*Aug 7 14:44:20.468: ICMP: echo reply sent, src 6.6.6.6, dst 192.168.24.4, topology BASE, dscp 0 topoid 0
iosv-6#
*Aug 7 14:44:22.464: ICMP: echo reply sent, src 6.6.6.6, dst 192.168.24.4, topology BASE, dscp 0 topoid 0
iosv-6#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
iosv-4#sh ip ro | b Gate
Gateway of last resort is not set
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
B 6.6.6.6 [20/0] via 192.168.24.2, 00:29:49
192.168.24.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.24.0/24 is directly connected, GigabitEthernet0/0
L 192.168.24.4/32 is directly connected, GigabitEthernet0/0
iosv-4#
iosv-4#debug ip icmp
ICMP packet debugging is on
iosv-4#
*Aug 7 14:43:05.366: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
iosv-4#
*Aug 7 14:43:07.334: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
iosv-4#
*Aug 7 14:43:09.307: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
iosv-4#
*Aug 7 14:43:11.257: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
iosv-4#
*Aug 7 14:43:13.221: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
iosv-4#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
考察
天才の私は考えた。
「リプライの送信までは確認できてるけど、リプライの受信は確認できていない。じゃあ、リプライの送信ログにあるsourceとdestを使って改めてpingを送ってみてはどうだ?」
iosv-6だと、リプライのsourceは6.6.6.6、destが192.168.24.4になっているので、ping 192.168.24.4 source 6.6.6.6で検証。
iosv-6#ping 192.168.24.4 source 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.24.4, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6
.....
Success rate is 0 percent (0/5)
iosv-4#debug ip icmp
ICMP packet debugging is on
iosv-4#
疎通せず、今回はリクエストすら受信していない。
解決
さらに考えた。
「なんでdestは物理アドレスなんや?」
iosv-6#ping 4.4.4.4 source 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/15 ms
iosv-6#
*Aug 7 15:01:18.253: ICMP: echo reply rcvd, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:01:18.267: ICMP: echo reply rcvd, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:01:18.279: ICMP: echo reply rcvd, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:01:18.293: ICMP: echo reply rcvd, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:01:18.305: ICMP: echo reply rcvd, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
iosv-4#debug ip icmp
ICMP packet debugging is on
iosv-4#
*Aug 7 14:57:51.846: ICMP: echo reply sent, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 14:57:51.863: ICMP: echo reply sent, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 14:57:51.878: ICMP: echo reply sent, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 14:57:51.894: ICMP: echo reply sent, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
*Aug 7 14:57:51.909: ICMP: echo reply sent, src 4.4.4.4, dst 6.6.6.6, topology BASE, dscp 0 topoid 0
疎通!!!!
きもち~~~~~↑↑↑
原因
よくよく考えてみれば、CEの物理アドレスはBGPのnetworkで広告していない。
iosv-0#sh run | sec bgp
mpls bgp forwarding
router bgp 100
<略>
!
address-family ipv4 vrf A
neighbor 192.168.60.6 remote-as 200
neighbor 192.168.60.6 activate
exit-address-family
iosv-6#sh run | sec bgp
router bgp 200
bgp log-neighbor-changes
network 6.6.6.6 mask 255.255.255.255
neighbor 192.168.60.10 remote-as 100
neighbor 192.168.60.10 allowas-in
IGPとは違い、BGPはピアリングしてもnetworkで明示的に指定しない限り他所へ広告されることはない。
iosv-4(config)#router bgp 200
iosv-4(config-router)#net 192.168.24.0 mask 255.255.255.0
iosv-4(config-router)#end
iosv-4#
*Aug 7 15:11:39.378: %SYS-5-CONFIG_I: Configured from console by console
iosv-4#sh ip ro | b Gate
Gateway of last resort is not set
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
B 6.6.6.6 [20/0] via 192.168.24.2, 00:58:49
192.168.24.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.24.0/24 is directly connected, GigabitEthernet0/0
L 192.168.24.4/32 is directly connected, GigabitEthernet0/0
B 192.168.60.0/24 [20/0] via 192.168.24.2, 00:00:27
iosv-4(config)#router bgp 200
iosv-4(config-router)#net 192.168.24.0 mask 255.255.255.0
iosv-4(config-router)#end
iosv-4#
*Aug 7 15:11:39.378: %SYS-5-CONFIG_I: Configured from console by console
iosv-4#sh ip ro | b Gate
Gateway of last resort is not set
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
B 6.6.6.6 [20/0] via 192.168.24.2, 00:58:49
192.168.24.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.24.0/24 is directly connected, GigabitEthernet0/0
L 192.168.24.4/32 is directly connected, GigabitEthernet0/0
B 192.168.60.0/24 [20/0] via 192.168.24.2, 00:00:27
iosv-6#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 13/15/23 ms
iosv-6#
*Aug 7 15:16:12.453: ICMP: echo reply rcvd, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:16:12.466: ICMP: echo reply rcvd, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:16:12.479: ICMP: echo reply rcvd, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:16:12.493: ICMP: echo reply rcvd, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
*Aug 7 15:16:12.516: ICMP: echo reply rcvd, src 4.4.4.4, dst 192.168.60.6, topology BASE, dscp 0 topoid 0
実際、CE-PE間の物理アドレスをnetworkで広告してあげると、ping実行時に送信元を明示的に指定しなくてもpingが通るようになった。
まとめ:流れ
1) ping、送信元を指定していないので物理アドレスが送信元に自動でセットされる。
2) リクエストを受信した対向CEで送信元(物理アドレス)をチェック。
3) リクエスト内の送信元(物理アドレス)をリプライの宛先にセットする。
4) CEのPE側物理アドレスは、bgp networkで指定されておらず広告されていないため、互いのルーティングテーブルに載っていない。
5) 結果、宛先不明でリプライパケットが破棄される。
感想
debugコマンドは偉大。running-configを眺めるだけだと絶対に解決しなかった。
トラブルの切り分けを上手に、迅速に行うためにはdebugとshow各種(show run以外)を使いこなす必要があると実感した1件だった。