I’ve spent the past week trying to get per subscriber shaping working on the Juniper MX. It took me a lot longer to get working than it should have done.
My goal was to have a subscribers traffic shaped to 1Gbps that is terminated using a PPPoE session over an MPLS pseudowire. A lot of the configuration used to actually get the subscriber terminating can be found in my previous post.
Since we are shaping a customers traffic, we probably want to configure a custom scheduler to define attributes such as queue depth, WRED profiles, as well as any of the other various Juniper CoS tools such as classifiers, rewrite rules etc. These are all defined under the standard class-of-service hierarchy. Below you can see that I’ve got a fairly basic scheduler configured that defines a drop profile for customers traffic.
class-of-service {
drop-profiles {
CORE_STANDARD {
fill-level 70 drop-probability 25;
}
}
forwarding-classes {
class STANDARD queue-num 0;
}
scheduler-maps {
SUB_MAP {
forwarding-class STANDARD scheduler SUBSCRIBER_STANDARD;
}
}
schedulers {
SUBSCRIBER_STANDARD {
drop-profile-map loss-priority any protocol any drop-profile CORE_STANDARD;
}
}
}
The per subscriber traffic control profile is configured under the dynamic profile. Here you can reference the previously defined scheduler, as well define parameters such as the shaping rate, guaranteed rate. While this could be defined at the global level with the rest of the configuration, it is likely that each customer may get a different shaping rate provided by RADIUS. In this case, the statically defined values would be swapped out with the variables that JunOS populates from RADIUS.
This traffic control profile is then attached to the subscriber interface.
dynamic-profiles {
pppoe-profile {
class-of-service {
traffic-control-profiles {
1G {
scheduler-map SUB_MAP;
shaping-rate 1g burst-size 32k;
guaranteed-rate 500m burst-size 32k;
}
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
output-traffic-control-profile 1G;
}
}
}
}
}
}
Finally hierarchical scheduling needs enabling on the logical interface that the pseudowire interface is anchored to. If the subscribers are connecting over a physical port, then this configuration should be added to that port.
interfaces {
lt-1/1/0 {
hierarchical-scheduler maximum-hierarchy-levels 2;
}
}
To see the shaper is working you can run the ‘show class-of-service interface’ command on the virtual interface. This will provide the usual mountain of information, including details about which classifiers, rewrite rules and schedulers are applied, as well as detailed per queue statistics.
dave@bng> show subscribers
Interface IP Address/VLAN ID User Name LS:RI
ps1.3221317665 0x8100.5 0x8100.101 default:default
pp0.3221317666 1.2.3.4. user@domain default:default
{master}
dave@bng> show class-of-service interface pp0.3221317666 comprehensive
Logical interface pp0.3221317666 (Index 536965870) (SNMP ifIndex 200094958) (Generation 94742)
Flags: Up Point-To-Point Encapsulation: PPPoE
PPPoE:
State: SessionUp, Session ID: 6,
...
Logical interface pp0.3221317666 (Index 536965870) (SNMP ifIndex 200094958)
Forwarding classes: 16 supported, 7 in use
Egress queues: 0 supported, 7 in use
Burst size: 0
Queue: 0, Forwarding classes: STANDARD
Queued:
Packets : 0 0 pps
Bytes : 0 0 bps
Transmitted:
Packets : 0 0 pps
Bytes : 0 0 bps
Tail-dropped packets : 0 0 pps
RL-dropped packets : 0 0 pps
...
Logical interface: pp0.3221317666, Index: 3221317666
Object Name Type Index
Traffic-control-profile 1G_UID7558 Output 4294969317
Traffic control profile: 1G_UID7558, Index: 2021
Shaping rate: 1000000000
Shaping rate burst: 32000 bytes
Guaranteed rate: 500000000
Guaranteed rate burst: 32000 bytes
...
In summary, getting this working is a fairly straightforward task. As usual good documentation is lacking from Juniper.
There are far more complicated configurations you can get into should the need arise. Junipers CoS configuration is very detailed and flexible and should be able to support any services that can be dreamed up.