Re: Realworld use of Multilink Frame Relay

From: Sean C (Upp_and_Upp@hotmail.com)
Date: Tue Apr 12 2005 - 19:18:55 GMT-3


Hi Tim,

I think you're answering my question just by the explaining your example.
When you write that "both PVCs are up", then it's answering my question that
each physical circuit has to carry all PVCs. IOW - the carrier has to
provision all DLCIs on each circuit. 1 circuit couldn't carry just some of
the DLCIs and the other circuit carry the rest of the DLCIs. This would go
against what Jalle suggested earlier, the carrier utilizes a layer 3
interface that carries the DLCIs, not any circuit.

I think we're on the same page, thanks,
Sean
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "'Sean C'" <Upp_and_Upp@hotmail.com>; "'Mark Lasarko'"
<mlasarko@co.ba.md.us>; <ccielab@groupstudy.com>
Sent: Tuesday, April 12, 2005 5:27 PM
Subject: RE: Realworld use of Multilink Frame Relay

> Sean,
>
> As I said, I don't think there's a dlci issue if one of the pvc's fails.
>
> This is because with multilink the Layer 3 interface is virtual - the ip
> address is on the multilink interface, not the f/r interface.
>
> Therefore, when the router has packets to send to the other side of the
> multilink, it does the layer 3 to layer 2 resolution and finds one of the
> pvc's and sends the packet. If both pvc's are up, I don't know how the
> router decides which pvc to use but if one of the pvc's goes down, then
> there's no choice and the router will use that one.
>
> Does this make sense?
>
> But, what's an interesting question and one I don't know the answer to is:
>
> When more than one link in the multilink bundle can be used, which link is
> used?
>
> Does the router load balance? If so, how?
>
> Food for thought.
>
> Tim
>
> -----Original Message-----
> From: Sean C [mailto:Upp_and_Upp@hotmail.com]
> Sent: Tuesday, April 12, 2005 5:10 PM
> To: Mark Lasarko; ccielab@groupstudy.com; ccie2be@nyc.rr.com
> Subject: Re: Realworld use of Multilink Frame Relay
>
> Thanks Mark. So it looks like the resiliency is really only if the DLCIs
> are provisioned on both T1s.
>
> I'll let you know how it looks when we install some next week.
> Sean
> ----- Original Message -----
> From: "Mark Lasarko" <mlasarko@co.ba.md.us>
> To: <ccielab@groupstudy.com>; <Upp_and_Upp@hotmail.com>;
> <ccie2be@nyc.rr.com>
> Sent: Tuesday, April 12, 2005 1:02 PM
> Subject: Re: Realworld use of Multilink Frame Relay
>
>
>> Greetings Sean,
>>
>> I share Tim's understanding.
>> I also "confirmed" this from our service provider.
>> I have to leave that in quotes as they often leave me
>> reason to question their advice and guidance at times.
>>
>> I am under the impression that if you lose a link you
>> just lose that portion of your aggregate bandwidth.
>> (So watch your QoS configs) And the down DLCI's don't
>> get moved to another bundle... They're simply unavailable.
>> The MFR Link Integrity Protocol messages handle the part
>> that adds and removes links as they come and go.
>>
>> Have you read the forum doc on this?
>> http://www.mplsforum.org/frame/frfia.shtml
>>
>> I do interpret Cisco's "Service Resilience When Links Fail"
>> statement as being more market-esque than literal though...
>>
>> That said, I still get the blank stare response when I enquire
>> about this more often than not. Seems a lot of well-seasoned
>> engineers don't know too much if anything about this
>>
>> And don't bother asking sales about this unless you like responses
>> like
>> "You want to do what???"... <silence>... "What was that again??"
>>
>>
>> As for me, I guess I better lab it up :)
>>
>> I would be very interested to hear more from others on this.
>> I have been considering bundling links from multiple providers,
>> granted the transit deltas are similar, of course.
>>
>> Best,
>> ~M
>>
>>
>>>>> "Sean C" <Upp_and_Upp@hotmail.com> 4/12/2005 11:36:09 AM >>>
>>
>> Hi Tim,
>>
>> One of the mentioned reasons for Multilink Frame is (per CCO): Greater
>>
>> Service Resilience When Links Fail - Greater service resilience is
>> provided
>> when multiple physical interfaces are provisioned as a single bundle.
>> When a
>> link fails, the bundle continues to support the Frame Relay service by
>>
>> transmitting across the remaining bundle links.
>>
>> So, if using Multilink FR, and using the scenario I mentioned below:
>> unless
>> both T1s are advertising all DLCIs, how will the carrier let a circuit
>> carry
>> non-native DLCIs. IOW, from my example below, if the 2nd T1 fails, how
>> does
>> the carrier allow the 1st T1 to handle DLCIs 4, 5, 6. Won't DLCIs 4, 5
>> and
>> 6 need to be configured on the 1st T1. I can't just hope the carrier
>> knows
>> to allow DLCIs 4, 5 and 6 on the 1st T1. What happens now if I tried
>> to
>> configure DLCIs on a circuit where they are not provisioned - nothing.
>> So,
>> how does the carrier carry all DLCIs. Do both circuits need to carry
>> all 6
>> DLCIs? Or, from what Jaffe mentioned in a different email, the carrier
>> is
>> also responsible for creating a virtual interface on their equipment
>> and all
>> DLCIs ride on the Virtual interface, not on the physical circuits.
>>
>> Hope this makes sense and appreciate your comments,
>> Sean
>> ----- Original Message -----
>> From: "ccie2be" <ccie2be@nyc.rr.com>
>> To: "'Sean C'" <Upp_and_Upp@hotmail.com>; "'Group Study'"
>> <ccielab@groupstudy.com>
>> Sent: Tuesday, April 12, 2005 11:13 AM
>> Subject: RE: Realworld use of Multilink Frame Relay
>>
>>
>>> I'm not sure I completely understand your question, but if I do, it
>> seems
>>> to
>>> me that multilink is independent of how the f/r switches behave.
>>>
>>> The way I think of it, multilink is to serial interfaces what
>> etherchannel
>>> is to ethernet links - it's just a way to aggregate links. I don't
>> think
>>> or
>>> see any reason for the behavior of the f/r switches to do anything
>>> differently just because you decided to aggregate multiple links
>> running
>>> f/r
>>> encap.
>>>
>>> Of course, the routers on each side have to know what's going on so
>> they
>>> can
>>> re-assemble fragmented packets if any, but you're use of multilink
>> should
>>> be
>>> transparent to the carrier, I think.
>>>
>>> Maybe someone knows differently.
>>>
>>> Tim
>>>
>>> -----Original Message-----
>>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>> Of
>>> Sean
>>> C
>>> Sent: Tuesday, April 12, 2005 9:01 AM
>>> To: Group Study
>>> Subject: OT: Realworld use of Multilink Frame Relay
>>>
>>> Hello,
>>>
>>> When implementing Multilink Frame Relay (FRF.16) - I'm trying to
>>> understand
>>> how the carrier advertises PVCs. My question is this: does the
>> carrier
>>> advertise all PVCs on each T1?
>>>
>>> IOW - if an original implementation of FR had 2 T1s with the 1st T1
>>> utilizing
>>> PVCs # 1, 2 & 3 and the 2nd T1 utilizing PVCs # 4, 5 & 6. If wishing
>> to
>>> utilize Multilink FR, does the carrier now need to advertise all PVCs
>> on
>>> both
>>> T1s? IOW - will the 1st T1 now carry PVCs # 1, 2, 3, 4, 5 & 6 and
>> the 2nd
>>> T1
>>> will carry the same PVCs #1, 2, 3, 4, 5, & 6? It's the only way I
>> can see
>>> this happening because I can't figure out if the 2nd T1 fails, how
>> the 1st
>>> T1
>>> will be able to support PVCs 4, 5 & 6.
>>>
>>> I appreciate any answer supplied. I hope my question is stated
>> simply
>>> enough.
>>> I had searched on CCO:
>>>
>>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
>>> t
>>> /122t8/ft_mfr.htm
>>> and Googled some but have not found the appropriate answer.
>>>
>>> Thanks in advance,
>>> Sean
>>>
>>>
>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:57 GMT-3