Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

changing serial link from Frame-rely to MultilinkPPP

We will be upgrading our branch offices from a Single T1 to x2 T1 connections.

We have VoIP implemented in our branch offices.

I am wondering if I need to be concerned about making this change to the interface.

The current config is shown below, is the Frame-Relay (frame-relay traffic shaping) doing anything significant that I could get burned by changing the config from Frame-relay encap to multilinkPPP encap?

interface Serial0/3/0

bandwidth 1536

no ip address

encapsulation frame-relay IETF

load-interval 30

no fair-queue

frame-relay traffic-shaping

frame-relay lmi-type cisco

max-reserved-bandwidth 100

hold-queue 256 in

hold-queue 256 out

!

interface Serial0/3/0.400 point-to-point

ip address 1.x.x.6 255.255.255.252

ip nbar protocol-discovery

ip flow ingress

ip flow egress

frame-relay interface-dlci 400 IETF

class mycompany-class

crypto map mycompany_Crypt

19 REPLIES
Hall of Fame Super Silver

Re: changing serial link from Frame-rely to MultilinkPPP

Hello Richard,

you may consider to use FR multilink FRF.16 if supported by your IOS code

http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_ml_fr_frf161_ps6441_TSD_Products_Configuration_Guide_Chapter.html

However, modular QoS should allow you to provide the necessary features also using PPP multilink.

Hope to help

Giuseppe

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

". . . is the Frame-Relay (frame-relay traffic shaping) doing anything significant that I could get burned by changing the config from Frame-relay encap to multilinkPPP encap?"

It might, although I'm unsure about the impact of your crupto.

Although you have FQ disabled at the interface, most shapers use FQ, so it's possible your VoIP packets at least don't sit behind other non-VoIP packets as they might within a FIFO queue. (Crypto, though, might make all your traffic appear to be one flow to FQ.)

When moving to a MLPPP setup, the multilink interface might default to FIFO. If your FR shaper is indeed providing FQ, then moving to FIFO might cause VoIP issues. The solution would be to override the FIFO, if it is the default. For dual T1s, "fair-queue" might suffice, or you can try CBWFQ. (Once again, there's that crypto to consider.)

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

Thanks for the reply.

The crypto is nothing related to the voice stuff.

There is some sales traffic that is encrypted in the tunnel and that is all.

The circuits will have 756K CAR with Verizon and my understanding is that this will prioritize the Voice traffic.

The main site has MultilinkPPP configured as its link to the MPLS cloud.

Does this sound like it should be ok?

Anything to be concerned about?

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

Oh, well if you're using Verison's MPLS, not only should you insure your VoIP packets obtain the bandwidth they need from the (your?) CE to (Verizon's) PE, but you should also insure they obtain the bandwidth they need from PE to CE. The latter can often be accomplished by marking your VoIP packets so that MPLS PE to CE will prioritize them. (Likely DSCP EF is the marking you'll want to use, assuming you've purchased EF bandwidth. [Believe Verizon charges for EF separately from CAR.] Otherwise, IP Precedence 4, DSCP CS4 or DSCP AF41.)

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

We have a qos policy set up,

Attached is a branch config.

Would it have been better to leave as Frame relay, or not really matter?

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"Would it have been better to leave as Frame relay, or not really matter? "

Since you're only using the access link to get to/from the MPLS cloud, I don't think the FR vs. other technology is too important. However, since the link to/from the MPLS cloud is often the bottleneck, insuring congestion is handled as necessary is what's important. (The latter being handled by your service policy which queues differently outbound and marks for MPLS.)

PS:

On your policy, I normally advise both against WRED and FQ as you're using them. WRED really works best with TCP. FQ, I believe, can take bandwidth from your DATA-Priority class. Also would advise you don't use "max-reserved-bandwidth 100". (However, if you're happy with performance, leave things alone.)

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

Thanks for the reply.

So, using the PPP is no problem as long as I use the QoS policy?

Also, Can you explain this?:

"On your policy, I normally advise both against WRED and FQ as you're using them."

And sorry but, you also said the Qos policy would NOT be used unless there is congestion on the link correct other wise the link is used as first come, first served?

Is this true of any QoS policy?

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"So, using the PPP is no problem as long as I use the QoS policy? "

Correct, I don't believe it should be an issue.

"Also, Can you explain this?:

"On your policy, I normally advise both against WRED and FQ as you're using them.""

I did provide a summary expanation.

WRED drops packets before the queue overflows, the purpose being for the flow from whose packet was dropped slowing its transmission rate. TCP will behave that way, but many other non-TCP flows do not. Also I found on low bandwidth links, those usaully without many concurrent TCP flows, that WRED doesn't signal flows fast enough to keep them overflowing the queue. (You stats will indicate whether there are early drops or tails drops.)

On many platforms, class-default FQ uses bandwidth for each flow, so when you define a minimal class bandwidth for a user defined queue, it may not get it if there are enough class-default queues.

"And sorry but, you also said the Qos policy would NOT be used unless there is congestion on the link correct other wise the link is used as first come, first served?"

Correct. If there no congestion, there's no queuing. However, that's unusual. What does often happen, each interface often has a small FIFO queue (TX ring). When that queue overflows, it overflows into the software queue or queues. It's the software queue that is managed by hold-queue, or fair-queue, or CBWFQ, etc.

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

I really appreciate all of your input on this.

I see that the policy (shown on the config I uploaded) has "dscp" configured.

Would this need to be adjusted since the bandwidth is changing from 1.5 to 3.0M?

We recently had a circuit cut over disaster (unrelated to this) and I am worried to death that something could go wrong on making this change, so I am trying to cover every detail.

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"Would this need to be adjusted since the bandwidth is changing from 1.5 to 3.0M? "

The actual DSCP markings could remain the same, assuming you've purchased EF bandwidth.

Two things you could do is adjust the bandwidth values or take advantage of additional classes the MPLS vendor supports. (For instance, believe Verizon supports a six class model.)

More with regard to bandwidth allocations, if your platform has a new enough IOS, you can use bandwidth percentages rather than absolute values. This is a nice way to maintain the same model when the link bandwidth changes, assuming the bandwidth ratios between classes remain the same.

PS:

When you get your new circuit on-line, if you see any issues, remember there are lots of good people on these forums that are willing to offer advice.

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

I really appreicate you taking the time to answer my questions.

The EF bandwidth is different than the CAR?

On you PS comment Joseph,

This forum has been a great help to me.

All of the guys here are always willing to help and there is no way for me to thank you enough.

All I can do is give you the well deserved points to show how much it is appreciated.

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"The EF bandwidth is different than the CAR?"

I believe is, but I might be mistaken. Believe CAR (commited access rate?) is Verizon's version of something similar to frame-relay's CIR. If your traffic is within CAR it shouldn't be dropped. If your traffic is above CAR it might be dropped. (The latter being unlikely, at least in the US.)

Verizon I believe sells EF provisioning as an extra although you might get 8 Kbps for "free". If you exceed the EF rate, with EF marked traffic, traffic will be dropped since Verizon polices the purchased rate.

Best thing to do is confirm above with your Verizon sales rep.

PS:

If Verizon is providing you their six class model, you can often get decent VoIP placing VoIP (alone) into one of their two "gold" classes. You would still use LLQ on your policy, but mark outbound traffic for that class with, for example, CS4.

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

Joseph,

There were a couple of things I did not understand, even though you provided an explanation here.

You mentioned advising using WRED and FQ as we are using them,

are you talking about:

class class-default

set dscp default

fair-queue

random-detect

If so, how would you advise?

You also mentioned on an MPLS link, to make sure that the QoS is set up from remote side CE to PE router (which is what this policy is doing) and also from PE to CE router (which would be my Hub site router).

My question is, if there is an outbound policy already on the Hub CE router, can I apply an inbound policy to this same interface?

Also, why is the "max-reserved-bandwidth" not advised?

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"You mentioned advising using WRED and FQ as we are using them,

are you talking about:

class class-default

set dscp default

fair-queue

random-detect

If so, how would you advise? "

Yes, I advise against since a) your policy appears to be trying to insure adquate bandwidth for the "DATA-Priority" class, and b) class-default is likely to contain non-TCP traffic.

I would suggest something like:

class class-default

set dscp default

bandwidth 128

"You also mentioned on an MPLS link, to make sure that the QoS is set up from remote side CE to PE router (which is what this policy is doing) and also from PE to CE router (which would be my Hub site router)."

The PE router is likely under the control of the MPLS provider. If it is, you'll need to understand what their QoS policy provides and mark your traffic to take advantage of it. (Likely you'll already doing so with the markings of EF/AF31/BE.)

"Also, why is the "max-reserved-bandwidth" not advised?"

The default insures some bandwidth for "other" traffic, such as L2 overhead. It can be changed but only if you understand the issues involved in changing the default. Since unused bandwidth is still available to you, you don't want to take away other special taffic bandwidth insurance unless you're sure it won't have an adverse impact.

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

Joseph,

If my policy is the following with the above ajustment:

policy-map PEFCU-QoS

class VOICE

priority 256

set dscp ef

class DATA-Priority

bandwidth 128

set dscp af31

class class-default

set dscp default

bandwidth 128

What happens to the rest of the pipe?

Dont these three different classes cover all of the traffic?

My understanding was:

We have VOICE matching a particular access-list

Data-Priority matching an access-list

And

Default covering everything else

If the pipe is 1.5M, and I apply a bandwidth value to the Default class, doesn't that lock me in to 128K for the default class?

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"If the pipe is 1.5M, and I apply a bandwidth value to the Default class, doesn't that lock me in to 128K for the default class"

No, except for LLQ classes, bandwidth doesn't set a cap it sets a minimum. Both the DATA-Priority class and class-default class can use 100% of the link. If all three classes wanted bandwidth, VOICE would be limited to 256, and DATA-Priority and class-default should split the remaining available bandwidth.

New Member

Re: changing serial link from Frame-rely to MultilinkPPP

Excellent,

Thank you Joseph for helping me understand.

My last question on this I promise:

I have read that you should set the policies to utilize only 75% of the total bandwidth and voice in the priority class to use a max of 33% of the total bandwidth.

If for example I was using the priority class for voice and video conferencing, does it matter if I set the priority class to a full 33% of a 3.0M pipe and leave the other two policies at their current values?

For example:

policy-map PEFCU-QoS

class VOICE

priority 1024

set dscp ef

class DATA-Priority

bandwidth 128

set dscp af31

class class-default

set dscp default

bandwidth 128

Can I set the values to whatever I want, or are there any particular rules to go by other than what I mentioned before?

Something else I noticed was that class af31 was used for voice signaling, but my access list is not related to voice signaling that the class is associated to, it is another application that is related to our customers.

The af31 can be applied in arbitrary ways like this as long as I match an access-list?

Super Bronze

Re: changing serial link from Frame-rely to MultilinkPPP

"I have read that you should set the policies to utilize only 75% of the total bandwidth and voice in the priority class to use a max of 33% of the total bandwidth."

The 75% is likely a reference to leaving 25% for "other" traffic which includes class-default. (I.e. unless you change max-reserved-bandwidth, other class's total bandwidth allocation shouldn't normally be definable to exceed 75%.)

The 33% is a rule-of-thumb suggested by Cisco to leave adquate bandwidth for non-LLQ classes.

"Can I set the values to whatever I want, or are there any particular rules to go by other than what I mentioned before?"

You can set the allocation to whatever you want with the guide that there's adquate bandwidth to support the need of the traffic. For instance, by you defining 128 Kbps for DATA-Priority, we're assuming that traffic will be "happy" with that as a minumum guarantee.

"Something else I noticed was that class af31 was used for voice signaling, but my access list is not related to voice signaling that the class is associated to, it is another application that is related to our customers.

The af31 can be applied in arbitrary ways like this as long as I match an access-list"

There are marking recommedations, that you might want to adhere to; MPLS providers might have a QoS model that behaves a certain way; Cisco WFQ weigth flows different based on IP precedence or DSCP class selector; etc.

The links, below, are some of Cisco "At-A-Glance" that might help you understand this.

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295a9b.pdf

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295abf.pdf

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295ac3.pdf

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295ab5.pdf

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa1.pdf

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aab.pdf

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa8.pdf

265
Views
50
Helpful
19
Replies
CreatePlease to create content