Hello,
I have some DMVPN WAN topology (EIGRP based) running over the Internet. Initialy there was only one global routing table and simple multipoint tunnel interface on all spokes. It worked fine. Now, we added Remote Ingress Shaping (RIS) feature to provide ingress QoS for spokes. After implementing it, two things happened. First, shaping on internal tunnel is not working at all. Shaper is set to 256k, but the traffic axceeds even above 1.5Mb. It's not a problem with displaying policy counters as the relevant traffic is also observed on thysical interfaces (WAN and LAN).
TEST#show policy-map interface tunnel 6
Tunnel6
Service-policy output: qos-shaping-lan
Class-map: class-default (match-any)
64494 packets, 59307655 bytes
30 second offered rate 504000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 256000, bc 25600, be 0
target shape rate 256000
Second, which is worse, the traffic becomes very unstable. The configuration itself seems to be OK, as pings can go from LAN PC to the hub. However, larger, mixed traffic is not working. Actualy it is quite hard to find a single point of issue. I mean, I can ping local LAN from the hub, I can even do RDP to remote workstation. Also, copying files from the HUB to that workstation using CIFS is OK. However, when I try for example to connect to the Exchange server, or update AD policy (miscelanous TCP/UDP ports are used), it just stops working. Wireshark shows many duplicate and fragmented packets. When I remove that internal tunnel and VRF from LAN interface, everything starts working fine. So, what I can see is that DMVPN tunnel is OK, but additional, internal tunnel breaks the traffic somehow. Here is relevant code:
interface Loopback5
description Source for RIS inside VRF
ip address 1.1.1.1 255.255.255.255
interface Loopback6
description Source for RIS inside Global
ip address 2.2.2.2 255.255.255.255
interface Tunnel0
[...]
description DMVPN#1 via Internet
bandwidth 256
ip mtu 1400
ip tcp adjust-mss 1360
tunnel path-mtu-discovery
tunnel protection ipsec profile IPSEC-DMVPN shared
[...]
interface Tunnel5
description Tunel RIS VRF
ip vrf forwarding LAN
ip address 3.3.3.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback5
tunnel destination 2.2.2.2
interface Tunnel6
description Tunel RIS global
bandwidth 256
ip address 3.3.3.2 255.255.255.252
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 1.1.1.1
service-policy output qos-shaping-lan
interface GigabitEthernet0/0
description Internet access
bandwidth 256
[...]
service-policy output qos-shaping-wan
interface GigabitEthernet0/1
description LAN Switch
interface GigabitEthernet0/1.10
description Workstations
encapsulation dot1Q 100
ip vrf forwarding LAN
ip address 10.0.0.1 255.255.255.0
[...]
ip route 0.0.0.0 0.0.0.0 x.x.x.x name Def_towards_internet
ip route 10.0.0.0 255.255.255.0 Tunnel6 name LAN_Net
ip route vrf LAN 0.0.0.0 0.0.0.0 Tunnel5 name Def_towards_global
policy-map qos-shaping-wan
class class-default
shape average 256000 25600 0
service-policy qos-wan-out
policy-map qos-shaping-lan
class class-default
shape average 256000 25600 0
service-policy qos-lan-out
I played with different MTUs, MSS, and path-mtu discover on that internal tunnel. It seems that some bug in IOS (2901, 15.1(4)M3) makes this internal tunnel to misbehave. Has anyone implemented RIS feature using internal tunnels? Is there anything wrong with the above config?
Cheers,
Krzysztof
