[rbak-nsp] QoS Marking for ICMP and Other problems

Alireza Soltanian soltanian at gmail.com
Wed Jan 22 04:17:32 EST 2014


Hi Everybody

We managed to mark the traffic before our SE-800 with different marks based
on application. For example HTTP will have AF41 and Torrent will have AF21.
For ICMP we mark the packet on SE with following configuration:

 

context local

policy access-list MARK

  seq 10 permit icmp any any class ICMP

!

qos policy MARK metering 

access-group MARK local

    class ICMP

   mark dscp cs7

!

This policy is assigned to PPPOE subscribers via "subscriber default"

Now for each subscriber, we have two other policies:

1)      One PWFQ policy for download rate

2)      One Metering policy for upload rate

 

Before going through the configuration, I must mention, we are using
following queue-map for assigning PD to queues:

 

qos queue-map QM

num-queues 4

  queue 0 priority 0 1 2 

  queue 1 priority 3 4 

  queue 2 priority 5 

  queue 3 priority 6 7

 

Following sample shows the PWFQ configuration:

 

qos policy 128UnlimitedFairRX pwfq 

 rate maximum 128

weight 2

num-queues 4

queue-map QM

queue 0 priority 0 weight 100

queue 1 priority 1 weight 100

queue 2 priority 2 weight 100

queue 3 priority 3 weight 100

 

each subscribers is connected to SE inside of a QinQ VLAN, following
configuration shows a sample:

 

port ethernet 2/1 

 mtu 1400

no shutdown

medium-type copper

encapsulation dot1q

dot1q pvc 545 profile MARK-COS encapsulation pppoe 

  bind authentication pap context INTERNET maximum 8000

dot1q pvc 4011 profile MARK-COS encapsulation 1qtunnel 

  qos rate maximum 551670

  qos weight 2155

  qos policy queuing GROUP#1

  dot1q pvc 4011:148 profile MARK-COS encapsulation pppoe 

   bind authentication pap context INTERNET maximum 8000

   qos rate maximum 48770

   qos weight 161

   qos policy queuing Exchange#1

 

As you can see for dot1q pvc and dot1q tunnel we have PWFQ policies and
rates as well.

Now the point is since ICMP packet is marked with CS7 which is the highest
standard DSCP mark, we expect that the PING time from Subscriber to SE must
always be good, even in the time of congestion inside PPPoE session,dot1q
pppoe and dot1q tunnel.

Congestion inside of dot1qs are simulated by using qos rates and pwfq
policies. But the problem is this behavior is not what we got always.
Sometime it is OK but sometimes we have jitter or packet loss from
Subscriber to SE when dot1q pppoe is congested and sometimes when it is not
congested.

Is there anybody here who had this issue before?

 

Device is SE-800 XCRP4 and SEOS version is 6.4.1.4

 

Thank you

Alireza

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/redback-nsp/attachments/20140122/008a249d/attachment.html>


More information about the redback-nsp mailing list