Problems with RED QoS

Hi, pmcdaniel, and welcome to the User BB!

Could you show a pic of the QoS configuration for the RED interface?  Do you have 'Download equalizer' or 'Uplink optimizer' checked for it?  Is there anything in the 'Intrusion Prevention' log when this happens?

Cheers - Bob

I seem to have narrowed it down to the bandwidth pool.  I can toggle it on and off and see download speed go from .2 Mbps to 1.4 Mbps in an instant.

Here's the info you asked for:

QoS
Status Tab
Edit Interface

Interface REDS1: 
Downlink kbit/sec: 1500
Uplink kbit/sec: 1500
Limit uplink checked
Automatic QoS: 
Download Equalizer unchecked
Upload Optimizer unchecked

Bandwidth Pools tab

Name: Toshiba IP
Interface: REDS1
Position: 1
Bandwidth (kbit/s): 512 (I have set this as low as 1)
Specify upper bandwidth limit checked
Limit (kbit/s): 1400 (I have set this as low as 5 and also disabled)
Traffic selectors: Ping (We have selectors setup for DSCP tagging for VOIP but for testing purposes I'm only trying standard stuff like ping or smtp)

I am not seeing anything in the IPS log while doing the speed tests.

Here's an interesting note though.  I went to delete that bandwidth pool and got an error: 

The QoS bandwidth pool object 'Toshiba' is still used by the QoS interface object 'unnamed'. Proceed with object deletion anyway?

Are you sure that you want to delete the QoS bandwidth pool object 'Toshiba'?

I said yes of course.

After creating a new pool for the REDS1 interface, the problem still exists.

Here's what Alan Toews (the author of most of the QoS articles in the KnowledgeBase) had to say about this situation:

Currently, we can’t do much with RED and QoS, except guarantee outbound bandwidth for all RED tunnel packets. VOIP traffic in an IPsec tunnel can be detected and QoS’d because we copy the TOS bits from the VOIP packet onto the encrypted IPsec packet. We don’t do that with RED currently, so VOIP packets inside a RED tunnel are not distinguishable from any other traffic in the tunnel.

Creating QoS rules on a RED interface is possible on some ASG versions, but on current v8 versions it is no longer possible. It was removed, because it does not make logical sense to try to guarantee bandwidth on an interface that does not have a guaranteed available bandwidth itself, since it is a virtual interface. 

In other words, all you really can do is guarantee/limit the outbound bandwidth of the RED connection from the ASG.  You might want to visit the Astaro Gateway Feature Requests site and add a suggestion.

If you can identify traffic from the remote site that is drowning out the VoIP traffic, it might be possible to limit that with an appropriate rule on the ASG's Internal interface.

Cheers - Bob

Well that's not quite the answer we wanted, but it's an answer!

I guess our next step is to put a switch between the RED and the T1 router so we can split the VOIP traffic out from the RED tunnel, and setup QoS on the T1 router to prioritize VOIP over all RED traffic.  I assume it will work correctly in this configuration.

Considering that we got the RED and paired it with a T1 line to replace our existing MPLS, this is a bit disappointing, but we can work around it.

I would like to clarify the outgoing VOIP QoS from the HQ though.  Here's what we have:

QoS
Status Tab
Edit Interface

Interface External (WAN):
Downlink kbit/sec: 6000
Uplink kbit/sec: 6000
Limit uplink checked
Automatic QoS:
Download Equalizer unchecked
Upload Optimizer unchecked

Traffic Selectors Tab
Name: VOIP
Selector Type: Selector
Source: Any
Service: Any
Destination: Any
TOS/DSCP: DSCP-Bits
DSCP-Bits: DSCP Value
DSCP value: 46

Bandwidth Pools tab

Name: VOIP
Interface: External (WAN)
Position: 1
Bandwidth (kbit/s): 512
Specify upper bandwidth limit checked
Limit (kbit/s): 1400
Traffic selectors: VOIP

Also, what steps would I take to guarantee HQ WAN bandwidth gets reserved for the RED tunnel?  I've been messing with QoS so much the past couple of days I don't know which way is up now.

We still haven't had much luck with getting VOIP to work reliably with the RED.  Is it possible to add a separate WAN connection to the ASG220 and route only RED traffic to that interface?  My thinking is that if I added a separate T1 independent of our HQ WAN link that having identical pipes on each end of the RED link would make it easier for the QoS to work properly.  

I guess the biggest issue is that I still have no control over the traffic inbound from the RED site unless I have another router with QoS behind the RED limiting shaping traffic before it enters the RED.

Is it possible to add a separate WAN connection to the ASG220 and route only RED traffic to that interface

Yes.  The trick here is that the RED initiates the connection, which determines the WAN interface that the tunnel will be created over.  One of the RED settings in Astaro is ASG hostname.  You would need to enter the external address or internet resolvable FQDN (would also need an external DNS A record) that would point to your separate T1 interface.

Ok, so our current configuration has the WAN IP of the Astaro set as the ASG Hostname in Device Configuration.  If we connect a second WAN router to eth2 and configure the static IP for that interface, and then change the ASG Hostname to match that IP, the RED will automatically reconnect to the new IP?

While I'm thinking about it, could we also configure that separate T1 as a standby interface in Uplink Balancing for a backup WAN connection?

You shouldn't even need to change the ASG hostname.  Connect the new WAN line to a different interface in your ASG, then either 1)  Just enter the IP of the new WAN in the RED config or 2)  Publish a new A record to your external DNS like RED..com pointing to the IP of the new WAN, then enter that FQDN into the red config.

configure that separate T1 as a standby interface

No, when an interface is configured as a standby interface, it is actually put into standby mode and no traffic can pass unless the active interface goes down.  You could use multipath rules to pass other traffic over that secondary interface if you'd like.

BTW, as stated in both the admin manual and in the WebAdmin interface, the hostname should be an FQDN, not an IP address. 

It should be a fully qualified DNS hostname, including a domain. It should be resolveable in public DNS

From the admin manual, RED Management > Device Configuration:

ASG Hostname: You need to enter a public IP address or hostname where the ASG is accessible.

I took that to read that it acts independently of the ASG host name configured in Management > System Settings > Host name.  That is correctly setup as a FQDN.  If I used the current FQDN of the ASG, it would point to the current primary WAN IP, which would be pointless for this scenario.