topic Re: QoS help - non voice related in ExtremeSwitching (EXOS/Switch Engine)

QoS help - non voice related

treese — Thu, 09 Jan 2020 06:36:50 GMT

I have a site connected with a transparent LAN circuit with minimal bw. We just deployed some servers that sync across the link but saturates the connection sometimes. The traffic is mostly SSL . I need to configured some traffic control and believe the best way to do this is to configure qp2 and qp3 and create an ACL with the 2 sources and single destination for the attributes then assign to the correct qp and physical port on the switch. If this is the recommended way to do this I would like to know. Also I’m having trouble understanding the min and max bandwidth. I plan on applying the config ingress too. If I give each source a minimum of 20 and max of 50 then essentially the pipe could be over subscribed if both source servers kicked off at the same time. The sync are not on a schedule.

configure qosprofile QP2 minbw 20 maxbw 50 ports 1:1
configure qosprofile QP3 minbw 20 maxbw 50 ports 2:1

entry WEB1-QP2 {
if match all {
source-address 2.2.2.2/32 ;
destination-address 1.1.1.1/32 ;
}
then {
qosprofile QP2 ;
}
}
entry WEB2-QP3 {
if match all {
source-address 3.3.3.3/32 ;
destination-address 1.1.1.1/32 ;
}
then {
qosprofile QP3 ;
}
}

The devices on each end are 440’s and we do have other traffic traversing the link. These 2 servers are the ones that saturate the link but other traffic is important and don’t want to degrade the remaining traffic. This traffic is not voice related. If you could point me to the right solution or forum and have suggestions it would be most appreciated. Thank you

Re: QoS help - non voice related

FredrikB — Thu, 09 Jan 2020 22:03:10 GMT

Are the server ports tagged or untagged? If not tagged, you could just put the port in a QP and have that traffic prioritized with a lower prio than the rest of the traffic. I normally stay away from shaping/policing unless I have to and work with prio instead. Why limit to a certain percent if you can say that other traffic should go first, and then the less important traffic can use whatever is left (up to 100 ? I don’t have the time right now to come up with a command set for you, but if you answer these questions you might get some good help:

Are the server ports tagged or untagged?

Is the inter-switch port/connection tagged or untagged?

What is the actual capacity of the link between the switches and what is the link speed? (Could be 2 Mbps actutal, 1 G link speed)

Do you have any other prio (802.1p) on tagged traffic coming in to any of the switches?

/Fredrik

Re: QoS help - non voice related

treese — Thu, 09 Jan 2020 22:24:32 GMT

Untagged traffic and no ISL port in this design, the servers live behind a network unmanaged by us. The LAN on that side hits a pair of ASA FW’s which I have my 440 stack connected too, then the other end connects to my 440 stack at my location. I use a transit vlan to move the destination networks to and from. The transit vlan is tagged but this won’t help when the destination networks are e.g. 172.x.100.x/24, 172.x.101.x/24, 172.x.102.x/24 which live on the other side. Routes on the DC440 send the traffic back to HQ to our subnets. The port interfaces on the DC440 are 1Gb and the other side is DC440G2 10Gb. The circuit is 20Mb metro E. Which are in process of bumping up to 100Mb but I still want QoS in place to not saturate the circuit when the syncs kick off. Thanks

Re: QoS help - non voice related

FredrikB — Thu, 09 Jan 2020 22:32:07 GMT

Ok, then I see the need for an ACL to classify traffic. You use the minbw setup for the ports. Beware that this is the percentage of the link speed, not the 20 (or later 100) Mbps you have on the metro link. To get, say, 10 Mbps on a 1 Gbps interface you can set minbw 1 %, but you can’t get any more granular than that (and I don’t know how precise that will be in reality) and you won’t be able to set anything lower than 100 Mbps on the 10 G side as 1 % of 10 G is 100 M, so that method won’t work for you. I think prio is the way to go and it’s not any more complicated anyway.

Re: QoS help - non voice related

treese — Thu, 09 Jan 2020 22:42:29 GMT

I plan on moving the config to the FW interfaces which are 100Mb each and not the 10Gb uplink. That way the configs on each side can be the same if I need to build on that side too. I’ve ran the this setup before but my question is more about when setting up the qp’s with config I put out there could hamper the connection at peak times.

configure qosprofile QP2 minbw 20 maxbw 50 ports 1:1
configure qosprofile QP3 minbw 20 maxbw 50 ports 2:1

How do I give priority to 2 servers with say subnet of .152 over all other traffic. Lots of different traffic traverse this link. Would rate limiting be the way to go? What would this config look like? Thank you

Re: QoS help - non voice related

treese — Thu, 09 Jan 2020 23:41:51 GMT

Would creating a meter percentage and limit the bandwidth that way be a more sound set up?

Re: QoS help - non voice related

FredrikB — Fri, 10 Jan 2020 17:31:49 GMT

I thought you said you wanted to have the two servers that were syncing to NOT starve other traffic. Which traffic is most important? You could even set up filters that let the servers sync with low prio (specific IP to IP) but other traffic to/from those exact same IPs (servers) to other IPs can have a higher prio. The problem is that the X440 (G2 or not) can only do egress policing, not ingress. If you specify an ingress rate, it will be applied to the traffic when it leaves the switch, not as it enters it:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-basic-rate-limiting-on-a-port-for-ingress-and-egress

For prioritizing to work, you need to configure the egress interface to match the circuit. In your case you need to do this on both sides:

configure port X rate-limit egress 20 Mbps

You can then work with prio to make sure all traffic is forwarded in an acceptable manner. Failing to limit the egress will mean that you still push traffic to the carrier at 1 or 10 Gbps and no prio will be needed by your switch as there will be no queing up of packets. You need to control the queing in order to control which packets that may step ahead of the queue.

Re: QoS help - non voice related

treese — Fri, 10 Jan 2020 21:30:37 GMT

Yes the 2 servers that can starve the network sit behind the LAN I don’t manage but the uplink hit my 440 stacks. From there I have a metro E fiber circuit that sits between the sites. I’ll need to set up QoS on it and I think I can use an ACL to send the 2 sources to a 15Mb meter. The total bw of the link is 20Mb. I believe after getting your suggestions this is the way to go. Let me know if I’m off on this. It’s sort of trial by error because we do plan bumping up the circuit but still want to have some assurance with this traffic.

Re: QoS help - non voice related

treese — Fri, 10 Jan 2020 21:36:04 GMT

On egress rate-limiting the packets comes in hits the meter then goes out lower. This could still be an issue your mentioning because the over port could still be saturated because of this? I could set up the meter on both sides?

Re: QoS help - non voice related

treese — Fri, 10 Jan 2020 21:39:09 GMT

Thought about this a bit more. The 2 ASA’s connect to the 440 stack at 100Mb ports. I can apply here then the the fiber circuit would benefit from the change. I’ll attach a diagram.

Re: QoS help - non voice related

treese — Fri, 10 Jan 2020 22:26:16 GMT

Re: QoS help - non voice related

treese — Fri, 10 Jan 2020 22:48:32 GMT

This untagged traffic comes in thru load balancers and is SSL. I don’t see much differences in the traffic except for the Source and destination IP’s. Its hard for me to differentiate between the traffic to classify which would get priority. I just need the 2 heavy hitters to only use a certain percentage of the pipe.

Re: QoS help - non voice related

treese — Fri, 10 Jan 2020 22:49:55 GMT

app server query’s db on the local side from remote side.