配置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覆盖了另一端，导致的结果是从一端可以发起连接，从另一端却无法发起。