Booches.nl

Strange VPDN-GROUP behavior

I noticed some strange behavior in a vpdn-group configuration on a Cisco 876 router. I have a router with the following vpdn-group configuration:

vpdn-group pptp-group
! Default PPTP VPDN group
description pptp vpn users
accept-dialin
protocol pptp
virtual-template 10

The configuration is working perfectly and users can dialin using a PPTP connection. Backups of the configuration are made by Kiwi CatTools. Lately I noticed that the following command l2tp tunnel receive-window 256 is added to the configuration, like displayed below:

Cisco has the following explanation for the command:

“Use the l2tp tunnel receive-window command to set the size of the advertised control channel receive window. The receive window size controls the number of L2TP control packets that can be queued by the system for processing. Increasing the size of the control channel receive window allows the system to open PPP sessions more quickly; a smaller size is desirable on networks that cannot handle large bursts of traffic… Source”

Two days later the command is gone again. I asked the network engineers if they made any changes to the configuration, but they didn’t. I looked at the configuration and tried to add the command, but I am not able to add the command.

cisco-876(config)#vpdn-group pptp-group
cisco-876(config-vpdn)#l2tp tunnel receive-windows 256
^
% Invalid input detected at ‘^’ marker.

cisco-876(config-vpdn)#

I searched a little further and the command can only be added, when the dial-in protocol is changed from pptp to l2tp. Looking at the configuration above, you can see clearly that the dial-in protocol pptp is configured and the l2tp command is added.

I cannot explain this behavior. I hope some of you can…….

QoS matching for VoIP

Voice over IP is, as you know for sure, very time-sensitive traffic. That is why VoIP signaling and payload traffic should receive enough bandwidth and as less jitter and delay as possible.

QoS is an important tool to assign VoIP traffic more preference over “normal” traffic. Important for QoS tools to function correctly is placing different kinds of traffic in different queues. To place traffic in different queues, traffic should be classified. All VoIP traffic should be classified and placed in the same queue or given the same priority. I usually use the following ACL’s to match VoIP signaling and payload traffic.

VOIP SIGNALING

ip access-list extended VOIP-SIGNALING
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060

VOIP PAYLOAD

ip access-list extended VOIP-PAYLOAD
permit udp any any range 16384 32767

The following table gives some basic explanations for the different permit statements: