From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Apr 12 2005 - 21:47:51 GMT-3
NO, Sean,
The carrier doesn't know and doesn't care how you configure your routers.
The carrier just gives you whatever pvc's you pay for - that's it.
If you pay for 2 pvc's, you get 2 pvc's.
Now, I've assumed that since you're using 2 separate physical interfaces,
you've arranged with your carrier for each pvc to run over a separate
physical circuit, otherwise there's no point in using multilink to aggregate
the pvc into 1 logical circuit.
So, what you'll have is one interface using one pvc and one dlci. And, then
another interface using another pvc, and another dlci. The same will be true
at the other end.
Just remember multilink is just like etherchannel. If one phy link goes,
all the traffic goes over the other link.
HTH, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Sean
C
Sent: Tuesday, April 12, 2005 7:37 PM
To: ccie2be; 'Mark Lasarko'; ccielab@groupstudy.com
Subject: Re: Realworld use of Multilink Frame Relay
Tim,
You're looking at this from a different level. Sorry if anything is
misleading. Just trying to understand how the carrier handles resiliency if
one of the physical circuits are down - does the carrier provision all PVCs
on each physical circuit (so in case circuit 1 goes down, circuit 2 can
still transmit all PVCs) or does the carrier use a subinterface like Jaffe
suggested.
When you write: "If one of those pvc's isn't available, then the decision of
which pvc to use is easy - it using the remaining pvc." Sure, I understand
what my router will do, never questioned that. But how does the carrier
handle the failure? The only way I see this is by the carrier provisioning
the same DLCIs on each physical circuit.
What would happen if I configured some subints with fake DLCIs on an
interface where the carrier did not provision any PVCs? Answer-not much.
The PVCs would show up as deleted on my router. I could create any number
of fake DLCIs and apply them to my router, but if the carrier hasn't
programmed the same DLCIs in their cloud, nothing is going to happen.
So..., how does the carrier provision the multilink for DLCIs to utilize
what Cisco calls "Resilience When Links Fail". The only way I can think of
this is by the carrier provisioning all DLCIs on each circuit. Otherwise,
how would the circuit 1 know to carry the DLCIs from circuit 2? Jaffe
suggested the carrier uses a subinterface to map up - not sure how this
would work.
Nothing is configured yet - and the Frame will have static, point-to-point
subints utilizing interface-dlci commands (haven't see too much
implementation of inverse arp in the real world).
Hope this makes sense,
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 7:10 PM
Subject: RE: Realworld use of Multilink Frame Relay
> Sorry, Sean,
>
> I have to disagree.
>
> How is your f/r int configured?
>
> Are u mapping or using inv arp?
>
> Either way, when rtr a has a packet to send to send to rtr b, it looks up
> the next hop in the route table and sees it should use the multilink int
> and
> sends it to the multilink for forwarding.
>
> When the multilink interface gets the packet, it has to decide which pvc
> to
> use.
>
> If one of those pvc's isn't available, then the decision of which pvc to
> use
> is easy - it using the remaining pvc.
>
> Although very simplified, I think that's the essence of it.
>
> Keep in mind, from a Layer point of view, it doesn't matter which pvc is
> used since both go to the same next hop.
>
> HTH, Tim
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Sean
> C
> Sent: Tuesday, April 12, 2005 6:19 PM
> To: ccie2be; 'Mark Lasarko'; ccielab@groupstudy.com
> Subject: Re: Realworld use of Multilink Frame Relay
>
> 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
>
> _______________________________________________________________________
> 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