RV Routers: Custom Services and QoS

[panos.asproulis]

I have some questions regarding the addition of custom services and their use in QoS for RV routers (I use the RV220W)

Suppose I create a custom service as:

Name: MyService

Port: TCP 60000

1. Does this port number refer to the port number used by my LAN computer or the port number on the other side e.g. some computer on Internet I am using this service to connect to? Some services use the same port number on the side that initiates the service and the receiving end but there are services that use different ports for the initiating and receiving end. So, what is the meaning of the port number when creating a custom service?

LAN Computer : (port TCP 60000) <----> Internet computer : (some TCP port, not necessarily 60000)

- or -

LAN Computer : (some TCP port, not necessarily 60000) <----> Internet computer : (TCP port 60000) ?

2. Suppose I create a QoS profile binding configuration with respect to this custom service for a specific IP address on my LAN. QoS is applied to the outgoing network traffic only. How is this profile going to work?

A. Applied to traffic originating from my LAN device with the specified IP address and port TCP 60000

- or -

B. Applied to traffic originating from my LAN device with the specified IP address to another computer's port TCP 60000 ?

Thanks in advance

Sent from Cisco Technical Support iPad App

[panos.asproulis]

Nobody from Cisco knows how the custom services are defined in their RV routers?

[Tom Watts]

Hello Panos,

The service is both for the WAN and LAN. Although the WAN service is much more flexible because of port translation. Server A accepting request for 60000 will also need to accept that port number on the LAN. If you prefer a straight port forward external 60000 to internal 60000 this is valid for the WAN as well. You may also translate, lets say external port 60011 to internal port 60000, which would be implemented if you have Server A and B running the same port on the LAN.

The QoS you're referencing is neither of your scenarios. This is for outbound WAN traffic only.

-Tom

[panos.asproulis]

Thank you for your reply.

Regarding the meaning of the custom service, it is still not clear to me what is actually the case. For example, you are running a BitTorrent client on your LAN talking to various Internet clients and you have specified for your client to use port TCP/UDP 65000. So, you are going to have traffic from the LAN to the WAN and then to Internet from your local port 65000 to various ports on other clients, not necessarily port 65000.

LAN client TCP/UDP 65000 <--------> an Internet client TCP/UDP 6090

                                         <--------> an Internet client TCP/UDP 64000

                                         etc

If I now define the custom service:

Name: BitTorrent

Port TCP/UDP 65000

it makes a big difference whether this port refers to the port used by the LAN or the one used by the Internet clients. If it refers to the LAN port then I can capture this traffic. If not I cannot capture it. In IOS terms, I can capture this traffic using:

ip access-list extended IPV4_FROM_P2P_PORTS

remark --- IPv4 Traffic from P2P ports ---

permit tcp any eq 65000 any

permit udp any eq 65000 any

In my view, it would make sense when defining a custom service to have the following settings:

Name of the service

Port type

Port number used by the computer on the LAN

Port number used by the computer on the WAN

in which case my example would have been defined as

BitTorrent

TCP/UDP

LAN: 65000

WAN: any number

while a service like HTTP could have two versions:

HTTP for LAN Server

TCP

LAN: 80

WAN: any number

HTTP for a WAN Server

TCP

LAN: any number

WAN: 80

Regarding the QoS settings, suppose I have created the custom service BitTorrent as above and then I create a QoS binding for this service as:

Class: Low (for example)

Service: BitTorrent

Starting IP: 10.0.0.10

Ending IP: 10.0.0.254

what is going to be the effect of that? Is it going to apply A or B ?

A. Traffic from the WAN, originating from the LAN, to an Internet BitTorrent client listening at port TCP 65000.

B. Traffic from the WAN, originating from the LAN, at port TCP 65000 to an Internet BitTorrent client at the port it is listening.

[Tom Watts]

Panos,

When setting the service, the custom service port is what it is. The part which will address port translation would be the external and internal port on the forwarding section of the firewall. The difference is, your LAN port is not changing.  Which in the case, if you do specify a forwarding you can make any inbound port whatever you want to translate to the LAN port being used as indicated by my original reply.

For the WAN QoS profile, if you chose priority, this is where the high, medium low come in by what %. Then setting the profile table, you can bind this to the profile.

This will ONLY affect your upload speed, not download speed. So, if you are specifying "low" which by default is 10% you shouldn't have more than 10% of your total bandwidth upload.

-Tom

[panos.asproulis]

I understand what QoS is going to affect. My question is which outgoing traffic is it going to capture in my example:

A. Traffic from the WAN, originating from the LAN, to an Internet BitTorrent client which is listening at port TCP/UDP 65000.

- or -

B. Traffic from the WAN, originating from the LAN, at port TCP/UDP 65000 to an Internet BitTorrent client at the port it is listening, whatever that port number is.

My impression is that it will capture traffic A and not B which is the one I want to affect.

In IOS terms it is easy to identify the two different outgoing traffic types e.g. in my example the appropriate QoS should be like this:

Traffic of type B:

============

policy-map QOS_OUTGOING_POLICY

description --- Quality of Service Policy for Outgoing Traffic ---

...

class QOS_OUTGOING_P2P_CLASS

  bandwidth remaining percent 1

  set dscp cs1

class class-default

  fair-queue

class-map match-any QOS_OUTGOING_P2P_CLASS

description --- Outgoing P2P Traffic for QoS ---

match access-group name IPV4_FROM_P2P_PORTS

ip access-list extended IPV4_FROM_P2P_PORTS

remark --- IPv4 Traffic from P2P ports ---

permit tcp any eq 65000 any

permit udp any eq 65000 any        (i.e. from LAN port 65000 to any port on the other side)

In terms of the RV series is there a way to specify the above outgoing traffic to QoS?

[Tom Watts · Accepted solution]

Panos, it should be your example A.

-Tom

[panos.asproulis]

Thank you. That's what I thought! Which means that I cannot apply QoS for this type of traffic. I can apply QoS only for traffic I know the destination port i.e. the port used by the computer on the WAN. Which means that the custom service settings, in terms of QoS, refer to the destination port. Only when applying firewall rules and I refer to incoming traffic I can specify the LAN port by port forwarding translation.

So, it would have been much better if one could specify both source and destination port numbers when defining a custom service in order to be able to specify and capture all types of traffic.

[Tom Watts]

Panos, on the custom service you may specify start and finish port;

Name: BitTorrent

Type: xxx

Start: 60000

Finish: 65000

This will apply if you know what port ranges will be affected

-Tom

[panos.asproulis]

Still, the start and finish ports refer to the destination ports and there are cases when these ports are unknown and can be anything. This is the case with BitTorrent but also other with services.

For example, I have no idea what destination ports Skype is using but I can select the port that the Skype application on my PC uses. So, I cannot capture my outgoing Skype traffic for QoS purposes because the router only checks for the destination port (or port range) and not the source port which is the only one I know. For SIP it is ok because both source and destination ports are specific and known.

So, it would be a better option to allow the user to specify either source or destination ports (or range of ports) rather than just the destination port which may not be known, not even as a possible range.