I've got a customer with some rather small links. This creates the obvious problems in getting voice packets through congested pipes. Testing with PPP interleaving worked quite well, however the use of multilink interfaces is not feasable for administrative purposes (the router would become a nightmare to maintain).
I looked at this last a few months ago but kept hitting a dead end when trying to raise this with cisco.
Is anything being done to give the equivalent functionality to PPP interleaving directly on the physical interface, thus removing the need to double the number of interfaces on a router?
LFI (Link Fragmentation and Interleaving) is a feature that would only ever apply to a multilink bundle. How many links you have in the bundle (between 1 and N) has no bearing. So you would still need to configure a multilink interface and put the single interface into the bundle.
As they say...never say never.
I was trying to be careful to refer to the technology but not to be absolute in requiring one specific function. There is only one link per peer, so multilink bundles serve no purpose. The problem is that on a fractional T1 I've got voice packets queued behind 1500 byte data packets. Despite giving voice a priority queue under CBWFQ, the delay I get when a large data packet is in the process of being transmitted renders the voice call useless.
Despite having only one link, I created a multilink interface and turned on interleaving in a lab environment. The voice call now worked perfectly since it could preempt large data packets.
I want to be able to achieve this same functionality on the serial interface without having to create the multilink interface because:
1) as you stated, I have only one link
2) doubling the number of interfaces is administratively a large issue
When I last looked at it, Cisco offered only two solutions...multilink with interleave, and lowering the MTU of all interfaces. Neither of those are acceptable, so I'm hoping that something new might be coming or already here.
The only other way to do fragmentation at layer 2 is to use frame relay encapsulation back to back between routers instead of PPP or HDLC. This will work just as well as MLPPP.
You would still use LLQ (aka CBWFQ with priority) however you would apply it to a traffic-shaping map-class and use FRF.12 (frame-relay fragment) command in the map-class also.
The configuration commands required for strict QoS for certain traffic types are equally involved, so I don't really see what kind of administrative difference using MLPPP or FR will make.
The configuration commands for QoS are involved, but do not create an abstraction layer.
I'm trying not to create excessive complications. There's enough going on for the guys supporting this, that by effectively doubling the number of interfaces and on top of that abstracting it by removing most of the configs from being tied to the physical interface directly...well...it's not somewhere I want to go.
As for FR, while I've never actually tried to run FR encapsulation on a channelized T1 interface, I suppose it might work. But on a 64k link, the cost in overhead will have to be explained.
I can honestly say that I think if I told the customer they had to run FR over the circuit to be able to get some form of interleaving to work, they'd have the local Cisco sales rep's head cut off. :)
You see, this is the issue that brought about the post. There are ways to get it done, but the obvious ways are all bulky, employ uneeded technologies/overheads and are far from elegant. That's why I asked the TAC over a year ago to raise the idea with R&D of giving PPP interleaving functionality directly on the physical interface.
I think you are just plain barking up the wrong tree. I understand where you are coming from but I don't see the point. The people supporting this will learn the configuration and how it all works together. And if they don't understand it then they can read the plentiful documentation available on exactly this kind of configuration. And if that doesn't help then maybe TAC can explain it to them if they call in with an issue on it.
If you are satisfied that the bulk of all the commands as a whole needed for QoS are acceptable -- LLQ for example -- then I will not talk about that.
So back to the issue at hand.
You have a low speed serial link, one in which the potential serialization delay for large packets will definitely cause a problem for real time traffic. So you need to fragment the big packets. For a 64k link let's just say that we don't want any packets bigger than 80 bytes due to the long serialization delay. You can't fragment at L3 (e.g. ip mtu command) because that will break some things. So you need to fragment at layer 2.
You also need to rate all the traffic as a whole, and make sure that essential traffic like L2 keepalives, routing updates, real time traffic, etc. get interleaved with the rest of the data with the least possible delay.
The only layer 2 encapsulation protocols that can support fragmentation and interleave priority packets with the fragmented data are: MLPPP and FR.
Not PPP. MLPPP. And MLPPP requires extra software interfaces (or templates, or whatever you want to call them) to be configured.
It's not so much complexity that I'm concerned about, it's the addition of an abstraction layer and the essential doubling of the config.
All typical configuration features that could be used, CBWFQ, LLQ, CAR, crypto, etc are referenced from the physical interface. Therefore, if you're looking into a connectivity problem to a particular site it means that your key configs are split between the physical interface and the multilink interface.
There's other factors involved that I unfortunately can't get into. Suffice to say that multilink interfaces were looked into and rejected by the customer for a number of reasons.
I'm not looking to argue the merits of those decisions. They were correct for this customer, and I still stand by that decision. I was involved in a group that spent considerable effort testing and evaluating the options available last year. By posting I was hoping to find some information about alternatives that I hadn't known about or that were still coming down the pipes.
btw, you mentioned the ip mtu idea. Aside from breaking certain things and the cpu impact of this, we found better performance with PPP interleave.
I was not suggesting that you use ip mtu.
Also, most features that would be used would be applied to the multilink interface. The physical serial interface would have a fairly minimal configuration. Here is an example taken directly from the Cisco IP Telephony QoS Design Guide which can be found at:
ip address 10.1.61.1 255.255.255.0
ip tcp header-compression iphc-format
no ip mroute-cache
service-policy output QoS-Policy
ppp multilink fragment-delay 10
ppp multilink interleave
ip rtp header-compression iphc-format
no ip address
no ip mroute-cache
Have you thought about using a virtual template to implement multilink ppp ? see:
Or you can use ip unnumbered to apply a multilink interface to multiple interfaces with the multilink group command see:
We had tested the virtual template idea as well. However, there are certain config elements that are site-specific. I should have clarified this point in my initial post, and I apologize. As soon as you have things like per-site QoS policies, ipsec, etc, virtual-templates don't work anymore.
You got me thinking when I read your second idea to try to remember if we'd looked at it...and I believe we did. Unfortunately the unnumbered must refer to another interface, physical or logical. As such, I still can't use site-specific configs such as QoS, crypto, etc.
It's a somewhat unique situation, and now perhaps you can see the difficulty of finding a nice solution for it. I'd turned to cisco over a year ago and asked about allowing PPP interleaving directly from the physical interface. That would solve this in a second. Unfortunately from the sound of the responses here, there's still nothing new in this arena since I tested it over a year ago.
That being the case I guess you will need to just hunker down and create a multilink if for each site. Hey if it was easy they wouldn't need us : )
Very true :)
I wish there were a solution that wasn't such a hack. I much prefer clean, elegant solutions.
The truth is that the customer, as they did a year ago, may still decide that they don't want to go ahead with multilink interfaces. Deploying VoIP isn't an absolute requirement for them, but it's something they would have liked to do. Last year they decided the human factor of junior support staff escalating issues only because of the added complexity of having to refer to both the physical and the logical interfaces to get all the config for a site was more important.
Maybe as priorities shift they'll try to exert some pressure on the local cisco office. It's not unheard of for companies to respond to customer demands once in a while...but it is rare :)