Re: MLPPP over MPLS
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 On Tue, Feb 21, 2006 at 02:00:01PM -0600, Hyunseog Ryu wrote: > > 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: > > 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. > > > > > > > > > >
Re: MLPPP over MPLS
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: 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.
Re: MLPPP over MPLS
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: > 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: > >> 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 >> >> > > > > > >
Re: MLPPP over MPLS
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.
RE: MLPPP over MPLS
Title: Message
I've
been told by Juniper that the MTU negotiation problem was fixed in the 7.x
versions. We're upgrading soon, so I hope to find out for
myself.
Diane Turley Sr. Network Engineer Xspedius Communications Co.
636-625-7178
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brent
A O'KeeffeSent: Monday, February 20, 2006 7:57 AMTo: Jon
LewisCc: Jon R. Kibler; [EMAIL PROTECTED]Subject: Re:
MLPPP over MPLSIt 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
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED]
02/17/2006 03:38 PM
To
"Jon R. Kibler"
<[EMAIL PROTECTED]>
cc
[EMAIL PROTECTED]
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_
Re: MLPPP over MPLS
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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 02/17/2006 03:38 PM To "Jon R. Kibler" <[EMAIL PROTECTED]> cc [EMAIL PROTECTED] 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_
Re: MLPPP over MPLS
On 2/17/06, Hyunseog Ryu <[EMAIL PROTECTED]> wrote: > 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? > Hyun -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: MLPPP over MPLS
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: > 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 >
Re: MLPPP over MPLS
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 -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
Re: MLPPP over MPLS
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: > 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 >
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_
RE: MLPPP over MPLS
I've used MLPPP before with T1s...not the hardest thing to do...in fact, MLFR is a little bigt nastier, but still nothing that the average CCNA couldn't wrap their brain around... Erik Amundson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon R. Kibler Sent: Friday, February 17, 2006 1:37 PM To: [EMAIL PROTECTED] Subject: MLPPP over MPLS 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 -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
