MLPPP over MPLS

Mailman List Mirror (Read Only)
1

Greetings all,

Would anyone who has every done MLPPP over MPLS care to share their experiences with this type of network?

We have a customer that is implementing an MPLS network that will have 2 to 6 T1 feeds at some locations that will be using MLPPP for channel bonding. This is a telco provided network that will be customer managed.

The routers will be customer managed because the same equipment will have interfaces to another telco's network as a backup to the MPLS network. Needless to say, no telco will support equipment that interfaces competitors networks.

The customer is being told by their router vendor that an MLPPP/MPLS network is 'too complex' to be managed by anyone except for the router vendor's VARs or the telco. They indicated that it would be impossible for the customer's router vendor certified network person to come up to speed on MLPPP/MPLS configurations and manage such a network -- that it takes years to adequately learn how to manage that type of network configuration.

This doesn't sound like rocket science to me -- it should be simple and rather straight forward, I would think: The telco specifies its requirements for the router configuration, the customer implements that configuration on the required router interfaces, the telco monitors line quality, and the customer does basic router monitoring. Am I missing something here, or is the router vendor just blowing a lot of smoke to try to provide business for some of his clients that provide managed services?

Thanks in advance for your feedback!

Jon Kibler

2

We have a customer that is implementing an MPLS network that will have 2 to 6 T1 feeds at some locations that will be using MLPPP for channel bonding. This is a telco provided network that will be customer managed.

It's not clear from your message, but I'm assuming the MLPPP will be from PE to CE and that the MPLS you speak of is MPLS VPN. If that's the case, on the customer end, it's just a MLPPP, and on your end, it's an MLPPP with an "ip vrf forwarding foo" statement. It's probably more than the average CCNA can handle (but so are MLPPP, MPLS, and most day to day IOS config work). Anyone who actually uses IOS on a regular basis (as opposed to someone who crammed for an exam and knows squat) should have no trouble with it.

The customer is being told by their router vendor that an MLPPP/MPLS network is 'too complex' to be managed by anyone except for the router vendor's VARs or the telco. They indicated that it would be impossible for the customer's router vendor certified network person to come up to speed on MLPPP/MPLS configurations and manage such a network -- that it takes years to adequately learn how to manage that type of network configuration.

I think someone may be confusing "providing MPLS service" with "buying MPLS service". A customer buying MPLS VPN service never sees any of the MPLS tags or messes with MPLS/tag-switching commands. There is no added complexity...or at least there doesn't need to be any.

==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

Virus-free, because I say it is...and I run Pine on Linux :slight_smile:

3

What I heard from Cisco is that there may be some issue with MLPPP and
MPLS - maybe QoS? -.
The issue is for general IOS support issue for MLPPP/MPLS combination.
For that reason, Cisco recommended Multi-link Frame Relay(MLFR) to
overcome that issue.

Hyun

Jon R. Kibler wrote:

4

Hyunseog Ryu wrote:

What I heard from Cisco is that there may be some issue with MLPPP and
MPLS - maybe QoS? -.
The issue is for general IOS support issue for MLPPP/MPLS combination.
For that reason, Cisco recommended Multi-link Frame Relay(MLFR) to
overcome that issue.

Hyun

Hyun,

Would you happen to have a source for additional information as to exactly what the problem may be?

THANKS!
Jon Kibler

5

Maybe next monday I can ask for detailed info, but I wasn't on the
meeting to discuss this in detail.
Based on outcome of discussion with Cisco, we decided to go with MLFR
instead of MLPPP.

Hyun

Jon R. Kibler wrote:

6

Maybe next monday I can ask for detailed info, but I wasn't on the
meeting to discuss this in detail.
Based on outcome of discussion with Cisco, we decided to go with MLFR
instead of MLPPP.

Any idea if this issue is just another unfixed bug, or is it something deeper?

7

It may also be worth noting that if the provider is running Juniper and not Cisco, there are fragmentation issues with certain versions of Juniper code. The MLPPP session cannot agree on an MTU and usually stop somewhere around 100 bytes if they do. The workaround is to implement “ppp multilink fragment disable” on the Cisco Multilink interface.

Brent

Jon Lewis jlewis@lewis.org
Sent by: owner-nanog@merit.edu

02/17/2006 03:38 PM

To
“Jon R. Kibler” Jon.Kibler@aset.com

cc
nanog@merit.net

Subject
Re: MLPPP over MPLS

On Fri, 17 Feb 2006, Jon R. Kibler wrote:

> We have a customer that is implementing an MPLS network that will have 2
> to 6 T1 feeds at some locations that will be using MLPPP for channel
> bonding. This is a telco provided network that will be customer managed.

It's not clear from your message, but I'm assuming the MLPPP will be from
PE to CE and that the MPLS you speak of is MPLS VPN. If that's the case,
on the customer end, it's just a MLPPP, and on your end, it's an MLPPP
with an "ip vrf forwarding foo" statement. It's probably more than the
average CCNA can handle (but so are MLPPP, MPLS, and most day to day IOS
config work). Anyone who actually uses IOS on a regular basis (as opposed
to someone who crammed for an exam and knows squat) should have no trouble
with it.

> The customer is being told by their router vendor that an MLPPP/MPLS
> network is 'too complex' to be managed by anyone except for the router
> vendor's VARs or the telco. They indicated that it would be impossible
> for the customer's router vendor certified network person to come up to
> speed on MLPPP/MPLS configurations and manage such a network -- that it
> takes years to adequately learn how to manage that type of network
> configuration.

I think someone may be confusing "providing MPLS service" with "buying
MPLS service". A customer buying MPLS VPN service never sees any of the
MPLS tags or messes with MPLS/tag-switching commands. There is no added
complexity...or at least there doesn't need to be any.

> ==================================================
> Filtered by: TRUSTEM.COM's Email Filtering Service
> http://www.trustem.com/
> No Spam. No Viruses. Just Good Clean Email.

Virus-free, because I say it is...and I run Pine on Linux :)

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

8

I've also heard a variety of comments about difficulties in getting
Cisco MLPPP working in MPLS environments, mostly in the past year when
our product development people weren't buried in more serious problems
(:--) I've got the vague impression that it was more buggy for N>2
than N=2. There are a number of ways to bond NxT1 together, including
MLFR and IMA, and we've generally used IMA for ATM and MPLS services
and CEF for Internet. IMA has the annoyance of extra ATM overhead,
but doesn't have problems with load-balancing or out-of-order
delivery, and we've used it long enough to be good at dealing with its
other problems.

9

Since PPP doesn't have any way to identify different PVC from physical
circuit,
MLPPP can not be used for sub-interface required field.
For example, if you want to use different VLAN id with dot1q or Frame
Relay DLCI,
you can not use it with MPLS.
Since our customer requires to use multiple VLANs from same physical,
we decided not to use MLPPP and to use MLFR for this issue.
MLFR has DLCI field, so we can identify mutlple source of a sort of PVC.

If you wants to use QoS from MLPPP, you have to disable CEF from the
interface.
That's another consideration.

If you use FlexWan from Cisco 7600 platform, you can not change MTU size
for MLPPP/MPLS
because of bug CSCdj40945. That problem said it is fixed, but you still
need to check your IOS whether it has a fix for this or not.

Hyun

Hyunseog Ryu wrote:

10

Overall, MLPPP may work fine with MPLS as long as you have single virtual circuit from each physical circuit.
Such as T1 channel from Channelized DS3...
But you have to use sub-interface (logical interface) other than sub-channel from channeliezed circuit,
you may have some problem.
If you want to use QoS with MLPPP, some cases you may have to disable CEF because of side effects.

Overall, what I was recommended by Cisco source, is, if possible, to use MLFR instead of MLPPP for MPLS integration.

If you need more information, you can contact your local Cisco System Engineer, and he/she will give more information to you.

Hyun

Bill Stewart wrote:

11

For more specific discussion we can move it over to cisco-nsp
but here is a general document on it.

http://cco/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801f26c8.html#wp1045653

Rodney