[rbak-nsp] QoS policies (metering/policing) on dot1q child circuits
Tanan Satayapiwat
tsatayap at redback.com
Tue Feb 24 09:15:19 EST 2009
Hi Ronald,
Actually, Hierarchical scheduling is more for what you mentioned on Feb 19. Quoted from your email
" If for some reason both 1950:100 and 1950:101 are both bursting above the 10mbit (which is possible, since both child-circuits don't know how much bandwidth is available), so traffic *needs* to get dropped, to get to the maximum of 20mbit."
In this scenario, you can assign 10Mb metering to both 1950:100 and 1950:101. Then you assign another 20Mb Metering to 1950. The result is combining traffic amount cannot exceed 20 mbit on VLAN1950 level.
If what you want is to give absolute priority to voice traffic so that burst from data VLAN does not eat into voice VLAN, then you should assign different priority to 1950:100 and 1950:101. The difference in priority will be carried over to 1950 level and then you can apply strict mode so that higher priority will go first. So it should looks something like this
[local]Redback(config)#port ethernet 5/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 1950 encapsulation 1qtunnel
[local]Redback(config-port)#qos rate maximum 10000
[local]Redback(config-port)#qos hierarchical mode strict
[local]Redback(config-port)#dot1q pvc 1950:100 <--- voice
[local]Redback(config-dot1q-pvc)#qos policy queuing high_priority
[local]Redback(config-dot1q-pvc)#exit
[local]Redback(config-port)#dot1q pvc 1950:101 <--- data
[local]Redback(config-dot1q-pvc)#qos policy queuing low_priority
This comes out of the top of my head and I didn't have time to verify anything much so better to test it first.
Tanan
-----Original Message-----
From: Ronald Voermans [mailto:R.Voermans at global-e.nl]
Sent: Monday, February 23, 2009 9:27 PM
To: Tanan Satayapiwat
Subject: Re: [rbak-nsp] QoS policies (metering/policing) on dot1q child circuits
Tanan,
Thanks for your answers. Nice to see someone from Redback on this list!
I asked this question for the following: I use 1950:100 as an Internet VLAN and 1950:101 as a Voice VLAN. I've configured the policies as stated. However, when the end-users uses some application (in this case an online backup application), voice-traffic qualtiy decreases dramatically. It seems the 1 mbit I've configured for the voice-vlan is 'over-ruled' by the burst of the data-vlan polcies(of cource, the data-vlan policies have no knowing of the voice-vlan policies). So if I'll use hierarchical scheduling I can overcome this (I limit VLAN 1950 to 10mbit, and police VLAN 1950:100 to 9mbit and VLAN 1950:101 to 1 mbit)? I'm sorry to probably ask the same question again, but I want to make sure this is going to work without interrupting some service for the customer!
Thanks again,
Best regards,
Ronald Voermans
On 23-02-09 16:53, "Tanan Satayapiwat" <tsatayap at redback.com> wrote:
Hi Ronald,
First answer: Yes, makes sense since the formula is burst = rate/8 *1.5
Second answer: For your reason, it again makes sense to police/meter at the aggregate level of both 1950:100 and 1950:101. This can be done by hierarchical scheduling.
Tanan
-----Original Message-----
From: redback-nsp-bounces at puck.nether.net [mailto:redback-nsp-bounces at puck.nether.net] On Behalf Of Ronald Voermans
Sent: Thursday, February 19, 2009 3:47 PM
To: 'redback-nsp at puck.nether.net'
Subject: Re: [rbak-nsp] QoS policies (metering/policing) on dot1q child circuits
Oops,
Forget the question(s) below. After staring at it for the last days, I thought there was some problem on the Redback. After posting this message, I looked once again at the configuration, and discovered that the qos-policies missed the 'counters' statement in the rate-configuration!
However, I do have one other question about it:
Suppose the 1950 dot1q tunnel needs to be a 20Mbit (policed en metered) vlan, with dot1q child circuits 100 and 101 (so 1950:100 and 1950:101). Both child circuits will be pppoe-circuits (we distinguish different services as different child circuits, so 100 for 'internet' and 101 for 'voip'). At the moment I have 1950:100 policed and metered at 10mbit (see below) and 1950:101 policed and metered at 10mbit.
The rate and burst parameters for 10mbit are (resp.) 10000 and 1875000.
First question: do the burst parameters make any sense?
Next question: the dot1q tunnel needs to be 20mbit. Do I have to police/meter this circuit also? I ask this because of the following: If for some reason both 1950:100 and 1950:101 are both bursting above the 10mbit (which is possible, since both child-circuits don't know how much bandwidth is available), so traffic *needs* to get dropped, to get to the maximum of 20mbit.
I hope this makes any sense?!
Beste regards,
Ronald Voermans
Global-e BV
-----Oorspronkelijk bericht-----
Van: redback-nsp-bounces at puck.nether.net [mailto:redback-nsp-bounces at puck.nether.net] Namens Ronald Voermans
Verzonden: donderdag 19 februari 2009 14:26
Aan: redback-nsp at puck.nether.net
Onderwerp: [rbak-nsp] QoS policies (metering/policing) on dot1q child circuits
Hello,
I have a question regarding our SSE100 (6.1.1.4).
We've configured several on-demand dot1q tunnels. Via radius we apply different QoS-policies on these circuits. When I do a 'show qos circuit', I se that the policies are applied to the circuit:
'show qos circuit 2/3 vland-id 1950:100 pppoe 6357 detail':
Circuit: 2/3 vlan-id 1950:100 pppoe 6357
----------------------------------------------------------
Policy Name : sub10Mbit_UP
Policy Type : policing
Hierarchical Type : None
Rate : 10000 Rate Source : local
Burst : 1875000 Excess Burst :
Policy Name : sub10Mbit
Policy Type : metering
Hierarchical Type : None
Rate : 10000 Rate Source : local
Burst : 1875000 Excess Burst :
However, when I look at the counters of this circuit, I do not see any conforms or exceeds. My guess is that the policies aren't really applied to this circuit?
'show dot1q counters 2/3 vlan-id 1950:100 pppoe 6357 detail':
Circuit: 2/3 vlan-id 1950:100 pppoe 6357, Internal id: 3/2/102, Encap: ether-dot1q-tunnel-pppoe-ppp-combined
Packets Bytes
-------------------------------------------------------------------------------
Receive : 19852276 Receive : 2330263580
Receive/Second : 0.67 Receive/Second : 235.90
Transmit : 24350719 Transmit : 28784702132
Xmits/Queue Xmits/Queue
0 : 24350719 0 : 28784702132
1 : 0 1 : 0
2 : 0 2 : 0
3 : 0 3 : 0
4 : 0 4 : 0
5 : 0 5 : 0
6 : 0 6 : 0
7 : 0 7 : 0
8 : 0 8 : 0
Transmit/Second : 0.73 Transmit/Second : 464.92
IP Multicast Rcv: 0 IP Multicast Rcv: 0
IP Multicast Tx : 0 IP Multicast Tx : 0
Unknown Encaps : 0 Unknown Encaps : 0
Down Drops : 0 Down Drops : 0
Unreach Drops : 0 Unreach Drops : 0
Adj Drops : 0 Adj Drops : 0
WRED Drops Total: 0 WRED Drops Total: 0
WRED Drops/Queue WRED Drops/Queue
0 : 0 0 : 0
1 : 0 1 : 0
2 : 0 2 : 0
3 : 0 3 : 0
4 : 0 4 : 0
5 : 0 5 : 0
6 : 0 6 : 0
7 : 0 7 : 0
Tail Drops Total: 0 Tail Drops Total: 0
Tail Drops/Queue Tail Drops/Queue
0 : 0 0 : 0
1 : 0 1 : 0
2 : 0 2 : 0
3 : 0 3 : 0
4 : 0 4 : 0
5 : 0 5 : 0
6 : 0 6 : 0
7 : 0 7 : 0
IP Counters
Soft GRE MPLS : 0 Soft GRE MPLS : 0
Not IPv4 drops : 0 Not IPv4 drops : 0
Unhandled IP Opt: 0
Bad IP Length : 0
Bad IP Checksum : 0
Broadcast Drops : 0
PPP Counters
Cntrl Rcv : 541413 Cntrl Rcv : 22739358
Cntrl Tx : 541414 Cntrl Tx : 22739446
Cntrl Drops Rcv : 0
Retries Rcv : 0
Termreqs Rcv : 0
PPPoE Counters
Cntrl : 2 Cntrl : 151
Session Drops : 0
PADT Sent : 0
PADR Drops : 0
PADI Drops : 0
PADT Drops : 1
Bad Code : 0
ARP Counters
Drops : 0 Drops : 0
Unreachable : 0 Unreachable : 0
Rate Refresh Interval : 60 seconds
Whereas some circuits do have policing and metering policies applied, and they do show up in the counters:
Circuit: 2/3 vlan-id 1952:101 pppoe 13207, Internal id: 3/2/71, Encap: ether-dot1q-tunnel-pppoe-ppp-combined
Packets Bytes
-------------------------------------------------------------------------------
Receive : 9951654 Receive : 2145452540
Receive/Second : 0.15 Receive/Second : 10.37
Transmit : 9612154 Transmit : 2121365794
Xmits/Queue Xmits/Queue
0 : 9612154 0 : 2121365794
1 : 0 1 : 0
2 : 0 2 : 0
3 : 0 3 : 0
4 : 0 4 : 0
5 : 0 5 : 0
6 : 0 6 : 0
7 : 0 7 : 0
8 : 0 8 : 0
Transmit/Second : 0.13 Transmit/Second : 8.58
IP Multicast Rcv: 0 IP Multicast Rcv: 0
IP Multicast Tx : 0 IP Multicast Tx : 0
Unknown Encaps : 4 Unknown Encaps : 140
Down Drops : 258 Down Drops : 9804
Unreach Drops : 0 Unreach Drops : 0
Adj Drops : 0 Adj Drops : 0
WRED Drops Total: 0 WRED Drops Total: 0
WRED Drops/Queue WRED Drops/Queue
0 : 0 0 : 0
1 : 0 1 : 0
2 : 0 2 : 0
3 : 0 3 : 0
4 : 0 4 : 0
5 : 0 5 : 0
6 : 0 6 : 0
7 : 0 7 : 0
Tail Drops Total: 0 Tail Drops Total: 0
Tail Drops/Queue Tail Drops/Queue
0 : 0 0 : 0
1 : 0 1 : 0
2 : 0 2 : 0
3 : 0 3 : 0
4 : 0 4 : 0
5 : 0 5 : 0
6 : 0 6 : 0
7 : 0 7 : 0
Policing Counters
Conform : 291685 Conform : 58774631
Exceed : 0 Exceed : 0
Exceed Drop : 0 Exceed Drop : 0
Metering Counters
Conform : 281917 Conform : 58861551
Exceed : 0 Exceed : 0
Exceed Drop : 0 Exceed Drop : 0
IP Counters
Soft GRE MPLS : 0 Soft GRE MPLS : 0
Not IPv4 drops : 0 Not IPv4 drops : 0
Unhandled IP Opt: 0
Bad IP Length : 0
Bad IP Checksum : 0
Broadcast Drops : 0
PPP Counters
Cntrl Rcv : 6538 Cntrl Rcv : 248510
Cntrl Tx : 934302 Cntrl Tx : 35508582
Cntrl Drops Rcv : 0
Retries Rcv : 0
Termreqs Rcv : 0
PPPoE Counters
Cntrl : 907 Cntrl : 62608
Session Drops : 7
PADT Sent : 4
PADR Drops : 0
PADI Drops : 0
PADT Drops : 241
Bad Code : 0
ARP Counters
Drops : 0 Drops : 0
Unreachable : 0 Unreachable : 0
Rate Refresh Interval : 60 seconds
There is, as far as I can tell, absolutely no difference in both circuits. Am I doing something wrong/overlooking something, or can someone tell me why there are no counters (and thus apparently no applied policies) in most of the circuits?
Thanks in advance,
Regards,
Ronald Voermans
Global-e BV
_______________________________________________
redback-nsp mailing list
redback-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/redback-nsp
_______________________________________________
redback-nsp mailing list
redback-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/redback-nsp
More information about the redback-nsp
mailing list