cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1026
Views
50
Helpful
19
Replies

changing serial link from Frame-rely to MultilinkPPP

wilson_1234_2
Level 3
Level 3

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 19

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

Joseph W. Doherty
Hall of Fame
Hall of Fame

". . . 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.)

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?

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.)

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?

"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.)

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?

"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.

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.

"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.

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.

"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.

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: