×××第二话:配置L2L ×××感兴趣流ACL的两个特殊现象
配置L2L的×××时,配置感兴趣流的ACL时如果不注意就会出现稀奇古怪的现象。下面的小时候列举了两个。
第一个小实验:动态×××下分支结构的ACL覆盖导致的问题
拓扑:
说明:
1. R1,R2.R3接到一个二层switch上,处于10.1.1.0/24网段。
2. R1,R2,R3分别开启loopback 0模拟内部网络。
3. R1作为总部(hub),R2,R3作为分部(spoke)。
配置:
R1:
version 12.4
hostname R1
!
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set cisco esp-des esp-md5-hmac
!
crypto dynamic-map cisco 10
set transform-set cisco
!
crypto map cisco 10 ipsec-isakmp dynamic cisco
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
crypto map cisco
!
ip route 2.2.2.2 255.255.255.255 10.1.1.2
ip route 2.2.3.0 255.255.255.0 10.1.1.3
ip route 3.3.3.3 255.255.255.255 10.1.1.3
!
R2:
version 12.4
hostname R2
!
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 10.1.1.1
!
crypto ipsec transform-set cisco esp-des esp-md5-hmac
!
crypto map cisco 10 ipsec-isakmp
set peer 10.1.1.1
set transform-set cisco
match address ***
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.0
duplex auto
speed auto
crypto map cisco
!
ip route 1.1.1.1 255.255.255.255 10.1.1.1
!
ip access-list extended ***
permit ip host 2.2.2.2 host 1.1.1.1
R3:
version 12.4
hostname R3
!
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 10.1.1.1
!
crypto ipsec transform-set cisco esp-des esp-md5-hmac
!
crypto map cisco 10 ipsec-isakmp
set peer 10.1.1.1
set transform-set cisco
match address ***
!
interface Loopback0
ip address 2.2.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.3 255.255.255.0
duplex auto
speed auto
crypto map cisco
!
ip route 1.1.1.1 255.255.255.255 10.1.1.1
!
!
ip access-list extended ***
permit ip 2.2.0.0 0.0.255.255 1.1.0.0 0.0.255.255
测试:
1. 首先测试下动态×××的一个小特点,即不能从HUB端发起连接。
R1#ping 2.2.2.2 sou l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)
R1#
R1#ping 2.2.3.3 sou l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)
Ping不通。下面测试从spoke端发起了连接。
2. 先测试从R2发起连接,然后测试从R3发起连接。
R2#ping 1.1.1.1 sou l0 re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
......
*Oct 18 21:42:01.731: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for connection id=1..!!
Success rate is 20 percent (2/10), round-trip min/avg/max = 92/104/116 ms
*不知道是主机问题还是使用了二层交换机的问题,这里有一定程度的丢包,显示是MAC地址错误,不过最终还是通了,R1上MM已经在状态了。
R1#sh cry isa sa
dst src state conn-id slot status
10.1.1.1 10.1.1.2 QM_IDLE 1 0 ACTIVE
3. 现在测试从R3发起连接。
R3#ping 1.1.1.1 sou l0 re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.3.3
..!!!!!!!!
Success rate is 80 percent (8/10), round-trip min/avg/max = 16/37/92 ms
也通了,R1上的两个MM都在状态了。
R1#sh cry isa sa
dst src state conn-id slot status
10.1.1.1 10.1.1.3 QM_IDLE 2 0 ACTIVE
10.1.1.1 10.1.1.2 QM_IDLE 1 0 ACTIVE
好,也就是说在从R2先发起连接是没有问题的,两个spoke都可以与hub正常建立×××连接。
4. 下面先清掉3个设备上的×××连接和访问列表的计数器,然后测试先从R3发起连接的情况。
cle cry isa
cle cry sa
cle access-list coun
5. 从R3发起连接。
R3#ping 1.1.1.1 sou l0 re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.3.3
.!!!!!!!!!
Success rate is 90 percent (9/10), round-trip min/avg/max = 16/45/92 ms
通了。
R1#sh cry isa sa
dst src state conn-id slot status
10.1.1.1 10.1.1.3 QM_IDLE 1 0 ACTIVE
6. 再从R2发起连接。
R2#ping 1.1.1.1 sou l0 re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
..........
Success rate is 0 percent (0/10)
不通!!!但是R1上显示与R2的MM已经在状态了!
R1#sh cry isa sa
dst src state conn-id slot status
10.1.1.1 10.1.1.3 QM_IDLE 1 0 ACTIVE
10.1.1.1 10.1.1.2 QM_IDLE 2 0 ACTIVE
这个实验要的就是这种效果。
7. 为了进步说明问题,我们清掉R3上的ACL计数器,然后从R2上ping 10个包到R1,再来看看R3上的ACL计数器有什么变化。
R2#ping 1.1.1.1 sou l0 re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
..........
Success rate is 0 percent (0/10)
R3#sh ip acces
Extended IP access list ***
10 permit ip 2.2.0.0 0.0.255.255 1.1.0.0 0.0.255.255 (10 matches)
R3的ACL匹配了10个包,我们可以知道这10个包是由R2发出来的。并不是说R2的十个包发给了R3,而是10个包经R1接收后回包时,他没有会给R2而是回给了R3!
这就是ACL覆盖导致的问题!
下面这个小实验也反映了ACL覆盖的导致的问题,他的情况是静态×××,一端的ACL覆盖了另一端,导致的结果是从一端可以发起连接,从另一端却无法发起。
转载于:https://blog.51cto.com/edges/407379