[rbak-nsp] QoS policies (metering/policing) on dot1q child circuits
Tanan Satayapiwat
tsatayap at redback.com
Mon Feb 23 10:53:04 EST 2009
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
More information about the redback-nsp
mailing list