Routing

Hi,

 

Well, I have just had this thrown on me..... New remit given (at this late stage)..... "We now want to implement Voice (SIP and RTP) across the network" ....... 

 

Now this means I have to implement QoS for Voice..... I am assuming that will require manipulaiton of traffic utilising DSCP.... So, I am reading through a copy of the "QoS Day one" book and already feeling thouroughly confused......

 

Is there any, basic, known, QoS configuration for VoiP that I can use to start me off then I can work on refining it after that point?

 

Our set up would be:

 

LNS1 --> Core1 --> Core2 --> LNS2

                   |               |

              upstream  upstream

 

So voice can come from upstream and out the LNS and also vice versa.....

 

Any help at all would be great.

 

Thanks

Hi,

 

You can go through few example configuration availabl in Juniper tech pubs:

 

Configuring CoS to Manage VoIP Traffic When Running MX Series Router Cloud CPE Services

 

//Regards

AD

Hi Adwivedi,

 

Thank you for the response. Much appreciated. I'll try and work something out from the "Day-one" book and from the link you have shown here. If anyone else also has some ideas that would be great.... or a working solution .... thanks

 

HI adgwytc,

 

You should try to use consistent CoS implementation across your domain. So if upstream routers are part of your network, I would suggest to review cos implemetation on those routers and evaluate your requirement for implementation.

 

There is no generic cos config for voice as such and it varies from one customer to another. I don't have a ready config specimen but I will try to list down various components very broadly without getting into much detail (unless you have specific question) and what you may be looking in your current requirement.

 

- CoS has three basic functional parts: classification, scheduling and cos rewrite. (You also have shaping, policing and RED but lets look at basic parts first).

 

Classification: Here you match traffic and assisgn them to forwarding-class. Forwarding-class is intern mapped to the queue-number. For now lets say, forwarding-class is a readable names for queue-numbers 0,1,2,3 etc.

You perform classification on ingress port of your router.

There are two types of classifiers, Behavirol Aggregate(BA) and Multifield(MF) classifier. 

 

BA: where you are receiving marked dscp bits and classifying traffic based on earlier markings.

MF: where you use firewal filter to match certain condition and assign to specific forwarding-class.

 

In your case I believe you will receive already marked traffic, so you should be able to use BA classifier.

So based on your requirement, voice/ PTP, you need to identify the queue you want to use for them and assign traffic based on the marking the traffic is carrying.

 

Scheduling: Once traffic is in queue, we need to prioritize traffic for exiting the router. We use scheduler-maps to map forwarding-class to schedulers.

you can define different schedulers for different forwarding-class/ queues. Scheduler defines parameter for the specific queue, for e.g. transmit-rate, priority, delay buffers etc.

 

In your case, depending on traffic volume you need to define transmit-rate for the traffic. And for time-sensitive date you need to have high priority for transmit. Then you will need to define scheduler-map and map the scheduler to the forwarding-class/ queue.

 

CoS rewrite: This is somwhat opposite of classification. Here you match the queue where the traffic is received and re-write CoS values. This you only need when you want to manipulate or change the original cos values.

 

I believe you won't need it in your setup.

 

Hope it will help along with Day one book 🙂 .. If you have any specific question, feel free to write down. 

 

 

Hi Amitsaxena

 

Thank you for your description. Very helpful.....

 

So would something similar to the following be good (as a starter):

set class-of service classifiers dscp voip import default

set class-of-service classifiers dscp voip forwarding-class assured-forwarding loss-priority low code-points 011010

set class-of-service drop-profiles low_drop fill-level 95 drop-probability 0

set class-of-service drop-profiles low_drop fill-level 100 drop-probability 100

set class-of-service drop-profiles med_drop fill-level 75 drop-probability 0

set class-of-service drop-profiles med_drop fill-level 95 drop-probability 30

set class-of-service drop-profiles high_drop fill-level 50 drop-probability 0

set class-of-service drop-profiles high_drop fill-level 95 drop-probability 50

set class-of-service interfaces xe-1/2/5 scheduler-map normal

set class-of-service scheduler-maps normal forwarding-class expedited-forwarding scheduler ef

set class-of-service scheduler-maps normal forwarding-class assured-forwarding scheduler af

set class-of-service scheduler-maps normal best-effort scheduler be

set class-of-service scheduler-maps normal forwarding-class network-control scheduler nc

[edit class-of-service schedulers ef]

set transmit-rate percent 15

set buffer-size percent 15

set priority high

set drop-profile-map loss-priority high protocol any drop-profile high_drop

set drop-profile-map loss-priority medium-high protocol any drop-profile med_drop

set drop-profile-map loss-priority medium-low protocol any drop-profile med_drop

set drop-profile-map loss-priority low protocol any drop-profile low_drop

[edit class-of-service schedulers nc]

set transmit-rate percent 5

set buffer-size percent 5

set priority medium-high

set drop-profile-map loss-priority high protocol any drop-profile high_drop

set drop-profile-map loss-priority medium-high protocol any drop-profile med_drop

set drop-profile-map loss-priority medium-low protocol any drop-profile med_drop

set drop-profile-map loss-priority low protocol any drop-profile low_drop

[edit class-of-service scheduler be]

set transmit-rate remainder

set buffer-size remainder

set priority low

set drop-profile-map loss-priority high protocol any drop-profile high_drop

set drop-profile-map loss-priority medium-high protocol any drop-profile med_drop

set drop-profile-map loss-priority medium-low protocol any srop-profile med-drop

set drop-profile-map loss-priority low protocol any drop-profile low_drop

[edit class-of-service scheduler af]

set transmit-rate percent 50

set buffer-size percent 50

set priority medium-low

set drop-profile-map loss-priority high protocol any drop-profile high_drop

set drop-profile-map loss-priority medium-high protocol any drop-profile med_drop

set drop-profile-map loss-priority medium-low protocol any drop-profile med_drop

set drop-profile-map loss-priority low protocol any drop-profile low_drop

 

My questions will be:

 

1: Interface xe-1/2/5 is the Ingress interface ? What would I place on egress?

2: Is there a way that I can only allow traffic from certain sources and destinations?

 

Thanks

Hi!

 

For your queries

 

1: Interface xe-1/2/5 is the Ingress interface ? What would I place on egress?

 

- You apply classifier on the ingress interface (not the scheduler, because on ingress interface we want to clasisfy the traffic). And on egress interface you will apply the scheduler-map, so that the egress traffic is processed the way they are configured via scheduler.

 

[edit class-of-service interfaces xe-1/2/5]
labroot# set unit 0 classifiers dscp voip

[edit class-of-service interfaces xe-1/2/5]
labroot# show
unit 0 {
classifiers {
dscp voip;
}
}

 

 

2: Is there a way that I can only allow traffic from certain sources and destinations?

 

- Yes you can allow certain traffic, for this you will need to use the firewal-filter on the ingress interface. Match the conditions you need and assign to the forwarding-class, This filter will be applied as input direction on the ingress interface. Below is an example.

 

[edit firewall family inet filter classify]
labroot# show
term 1 {
from {
source-address {
12.12.12.0/24;
}
destination-address {
14.14.14.0/24;
}
}
then {
forwarding-class assured-forwarding;
accept;
}
}
term 2 {
then accept;
}

 

[edit firewall family inet filter classify]
labroot# top edit interfaces xe-1/2/5 unit 0

[edit interfaces xe-1/2/5 unit 0]
labroot# set family inet filter input classify

[edit interfaces xe-1/2/5 unit 0]
labroot# show
family inet {
filter {
input classify;
}
}

 

Hi Amit,

 

Perfect Answer. Thank you for your help. I will close this as resolved as I can work out the rest from these basic configs.

 

Thank you again.

Hi Amit,

 

My apologies, I was a little quick there.... I do have one other question please:

 

If the SIP traffic flows as follows:

 

Customer --> Upstream --> Core1 --> LNS1 --> Downstream LAC --> CPE --> Customer

 

And

 

Customer --> Downstream LAC --> LNS1 --> Core1 --> Upstream --> Customer

 

Obviously between the LAC and the LNS there will be "subscribers".... maybe up to 6,000 or more...... How can I configure any QoS on this LNS interface? I have been trying to work it out but I do not think there is a way of QoS here as we do not know:

 

A: The amount of subscribers or who for that matter, until they fill in the Portal applicaiton details.

B: The ADSL bandwidth from Customer location to the LAC.

 

Would I then place the last part of QoS on the Core1 to LNS1 interface on the LNS? 

 

Would that mean that both interface are actually Ingress and Egress depending on the direction of the traffic?

 

Thanks

Hi adgwytc,

In an L2TP scenario, between LAC and LNS it will be tunneled encapsulated traffic between the loopback of the two (LAC n LNS) as source and destination address.

Yes, if would like to have CoS on bi-directional traffic, then you will need to have interface considered as both ingress and egress and have cos policy in accordance with traffic flow direction you are modulating.

If your requirement is for CoS for individual subscribers, then probably you will need to look at hierarchical-cos for subscribers.

https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-subscriber-access.html


Regards,
Amit

Thanks Amit.... Much appreciated......