QoS - Guaranteed bandwith

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

QoS - Guaranteed bandwith

L2 Linker

Hi Team!

 

I'd like to ask about QoS Guaranteed Egress, because I'm not sure I understand the topic well. (used devices PA-220 and VM-100)

 

Here's what I need to do:

 

My branch office bandwith is limited by the ISP to 30Mbit/sec (ethernet1/1 WAN interface). I need to shape traffic to guarantee some bandwith to different kind of traffic classes, eg. 2 Mbit to class1, 10 Mbit to class2, 10 Mbit to class 3, etc. This is all download traffic, so the egress interface is the internal interface (ethernet1/2, LAN), and I set the QoS profile on this interface.

 

Bandwith limiting (egress max) is working fine, but guaranteed egress dosen't seem to be working. If, lets say class 4 traffic goes to 30 Mbit/sec, class 1, 2 and 3 becomes slow and can't reach the configured guaranteed bandwith.

 

Q1. I need to set the configured QoS profile on the egress interface (in this case ethernet1/2), right?

Q2. I read here , that to guaranteed egress to kick in, there has to be congestion on the interface. Since it's a 1 Gbit/sec LAN interface, the egress max is 1000 Mbit/sec. Is this true? Do I need configure egress max (30 Mbit) on ethernet1/2 to create an "artifical bottleneck", to create congestion?

Q3. If I set egress max 30 on ethernet1/2, I limit the download speed of the interface from 1000 to 30 Mbit. That doesn't seem right. What if there are multiple internal interfaces (ethernet1/3 for eg.) and traffic must flow from ethernet1/3 to ethernet1/2 with 1000 Mbit/sec speed (download as well, so egress interface is ethernet1/2 again)?

Q4. You can configure multiple QoS profiles to a physical interface and set source interface. What does source interface means in this case? It's from the perspective of the flow of the packets? In case of download, the traffic egresses the internal interface so source means the ingress  (in this case the external) interface? Or it's the interface where the traffic is originating from, where the original SYN packet was sent?

 

Thanks

 

Kind regards, 

Attila

 

Thanks

 

1 accepted solution

Accepted Solutions

Hi @PozsonyiAttila 

First of all few key notes to remember when working with Palo QoS:
- QoS is applies always only on egress interface

- QoS profiles define each class bandwidth allocation

- QoS policy rules (Policy tab -> QoS) are tagging traffic with QoS classes. Any traffic that is not explicitly tagged (doesn't match any rule) will automatically be tagged with class 4 (that is why with gray text you will see "class 4 is default class")

- QoS policy rules are session oriented - rules will match session, which means any packet that belongs to this session will be tagged with corresponding class. Rule must match initiation direction, but replies are automatically tagged with same class.


Now regarding your questions:
- To control the download you need QoS profile on the inside interface, yes. It may want to have second profile on outside interface to control the upload as well

- Egress max define what is the actual throughput of that interface. I would say your assumption and understanding is correct.

- You don't have to limit the inside interface to 30Mbps. You should set it to 1Gbps, for the exact reason you mentioned - it will affect traffic between internal networks over the same interface. Here the "QoS interface rules" comes in hand. (more in the next anwser)

- When creating QoS interface (Network -> QoS -> Add), on first tab you specify the default QoS profile that this interface will use. On Clear Text (and tunnel) you have an option to define more granular control and apply different QoS profiles for specific traffic. Any traffic that does not match any of these "rules" will use the default profile (set in physical int tab). Here source address and interface are per packet (not per session), which means those will match the direction of the packet. As you assume here you can define a rule matching any source and outside interface - this will match the return traffic for your Outbound/Internet traffic. This way you can apply QoS profile with corresponding classess and limits. Any other traffic that pass over this internal interface (traffic between internal vlan/networks) will not match this "rule" and will use the default QoS profile, which you can leave without any classes so it will not apply any restrictions.

View solution in original post

4 REPLIES 4

L4 Transporter

Hello @PozsonyiAttila 

 

In order to have a correct idea and concept of the implementation. To correctly apply the profiles you must consider:

The external interfaces, the Untrust WAN interfaces, is where you apply the "Upload" topics.

 

The Trust/LAN interface(s) is where you apply the QoS profile, to correctly enforce the "Download" issues.

Then you generate the QoS policies that match the desired traffic and the desired class.

 

Regards

High Sticker

Thanks @Metgatz for reassuring me on upload and download.

 

Any idea about the other questions?

Hi @PozsonyiAttila 

First of all few key notes to remember when working with Palo QoS:
- QoS is applies always only on egress interface

- QoS profiles define each class bandwidth allocation

- QoS policy rules (Policy tab -> QoS) are tagging traffic with QoS classes. Any traffic that is not explicitly tagged (doesn't match any rule) will automatically be tagged with class 4 (that is why with gray text you will see "class 4 is default class")

- QoS policy rules are session oriented - rules will match session, which means any packet that belongs to this session will be tagged with corresponding class. Rule must match initiation direction, but replies are automatically tagged with same class.


Now regarding your questions:
- To control the download you need QoS profile on the inside interface, yes. It may want to have second profile on outside interface to control the upload as well

- Egress max define what is the actual throughput of that interface. I would say your assumption and understanding is correct.

- You don't have to limit the inside interface to 30Mbps. You should set it to 1Gbps, for the exact reason you mentioned - it will affect traffic between internal networks over the same interface. Here the "QoS interface rules" comes in hand. (more in the next anwser)

- When creating QoS interface (Network -> QoS -> Add), on first tab you specify the default QoS profile that this interface will use. On Clear Text (and tunnel) you have an option to define more granular control and apply different QoS profiles for specific traffic. Any traffic that does not match any of these "rules" will use the default profile (set in physical int tab). Here source address and interface are per packet (not per session), which means those will match the direction of the packet. As you assume here you can define a rule matching any source and outside interface - this will match the return traffic for your Outbound/Internet traffic. This way you can apply QoS profile with corresponding classess and limits. Any other traffic that pass over this internal interface (traffic between internal vlan/networks) will not match this "rule" and will use the default QoS profile, which you can leave without any classes so it will not apply any restrictions.

@aleksandar.astardzhiev 

 

Thank you for your clear and detailed answers, I got enlightened! 🙂

After some testing everything is working as expected.

 

Now I got another question came to my mind.

 

What if I have two (or more) internal interfaces and I need to guarentee for eg. 10 Mbit/sec download bandwith for one of the internal interfaces (class1, external -> internal1 direction), no matter what happens, but at the same time guarantee another 10 Mbit/sec to internal2 (same direction external -> internal2) without limiting egress max, so if there's no traffic on internal1, internal2 can use the full 30 Mbit/sec. 

 

Can I do that?

 

Thanks

  • 1 accepted solution
  • 2750 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!